The tracker as a simulation team's data model: issue types, workflows and status categories, versions, sprints and Kanban, JQL with worked queries and its traps, Git and Jenkins integration, traceability from requirement to build, the metrics worth reporting, flow metrics and Little's law from a workflow history, and evidence for sign-off.
Concepts used here, and where they are explained. Each links to a glossary entry: this series glossary, or the glossaries of LLM Inference Simulators and FHE Accelerator Simulators for concepts those series already explain.
A simulator is a product with customers: architects asking "what if", verification engineers comparing it with RTL, management asking whether the next chip meets its targets. The work arrives as model features, validation tasks, bugs found by comparison with silicon or RTL, and requests for studies. A tracker such as Jira turns that into a queryable record: what is being done, by whom, for which release, what is blocked, and what evidence closed it.
No Jira site was used. The JQL is checked against Atlassian's documentation, and there are no screenshots of the Jira interface. The worked queries and metrics run on an example issue log for a fictional simulator team, generated from a fixed seed and labelled as such, through a small evaluator for the subset of JQL used here (snippets/t08, with its tests).
Jira changes quickly, and Atlassian is renaming things: its documentation now says work item for issue and space for project, and notes that "there are no changes to existing JQL queries". This deck uses the established terms, which is what JQL still accepts.
parent field, which replaced the older "Epic Link" field in Jira Cloud.validation or regression).WAS and CHANGED operators possible.statusCategory keep working when a team renames or adds statuses.resolution IS EMPTY is the conventional test for "still open". Atlassian notes that service team-managed spaces have no resolution field, and recommends statusCategory = Done there.| Scrum (sprints) | Kanban | |
|---|---|---|
| Cadence | Fixed time boxes (often two weeks), planned at the start, reviewed at the end | Continuous flow; items are pulled when capacity frees up |
| Limits | What is committed to the sprint | Explicit work-in-progress (WIP) limits per column |
| Main charts | Burndown or burn-up, velocity | Cumulative flow diagram, cycle time |
| Suits | Planned feature work: a new model component per release | Interrupt-driven work: studies, bug reports, validation requests |
A JQL query is clauses of the form field operator value, joined by AND, OR and NOT with parentheses, optionally followed by ORDER BY. Everything below is taken from Atlassian's reference pages for fields, operators, functions and keywords.
| Part | Examples | Watch out for |
|---|---|---|
| Comparison | = != > >= < <= IN NOT IN | != does not return items where the field is empty: write (assignee != currentUser() OR assignee IS EMPTY) |
| Empty | IS EMPTY, IS NOT EMPTY (NULL is a synonym) | Only for fields that support IS |
| Text | summary ~ "ONNX", text ~ "flaky" | Matches words and simple derivatives, not substrings |
| History | status WAS "In Review", status CHANGED FROM "In Review" TO "In Progress" | Only assignee, fix version, priority, reporter, resolution and status. Predicates: AFTER, BEFORE, BY, DURING, ON (and FROM, TO for CHANGED) |
| Functions | currentUser(), openSprints(), earliestUnreleasedVersion(SIM), releasedVersions(SIM), startOfWeek() | Each supports particular fields and operators (openSprints() only with IN and NOT IN) |
| Dates | created >= "-30d", updated < "-2w", "2026/08/01" | Relative dates are measured from now |
| Order | ORDER BY priority DESC, created ASC | Applies to the whole query, at the end |
Precedence matters: AND binds tighter than OR, so type = Bug AND status = Done OR priority = High returns every high-priority item, bug or not. When in doubt, add parentheses. These rules are also the test cases of the deck's evaluator.
Eleven questions a simulation team asks, as JQL, run against the example issue log (38 items, "now" is 28 September 2026, the current user is ). Choose a query to see its matches highlighted, and why.
Matches computed by snippets/t08/jql.py on example data; recorded in snippets/RESULTS.md.
Development work links itself to the tracker when the item's key appears in it. According to Atlassian's documentation, the key must be in the branch name, in the commit message, or in a pull request's title or source branch. The item's development panel then shows its branches, commits, pull requests, builds and deployments.
| Smart commit | Effect |
|---|---|
SIM-38 #comment fixed tFAW across ranks | Adds a comment to SIM-38 |
SIM-38 #time 1d 4h checked against DRAMsim3 | Logs work (w, d, h, m; decimals allowed), with the rest as its comment |
SIM-38 #resolve #comment validated on the nightly sweep | Runs the workflow transition whose name starts with "resolve", then comments |
Syntax from Process work items with smart commits.
#start is ambiguous between "Start Progress" and "Start Review"; write #start-review. A transition fails silently if it needs a field the commit cannot set. The committer's email must match a single Jira user with permission.jiraSendBuildInfo and jiraSendDeploymentInfo steps report builds and deployments for the keys found in the commits and branch names being built (Atlassian's set-up guide). Check the current versions before relying on either.| Area | Metric | From | Why it matters |
|---|---|---|---|
| Flow | Cycle time (50th and 85th percentile), throughput, WIP, ageing items | Workflow history | Predictability: "when will my study be done?" |
| Accuracy | Error against references: RTL cycle counts, silicon, trusted models | Validation suite in CI | The simulator's reason to exist (InfSim 06) |
| Coverage | Requirements verified; operators and workloads supported | Traceability matrix; operator coverage (deck 10) | What the answers can be trusted for |
| Quality | Open bugs per release, escaped defects, regressions, flaky tests | JQL (queries 3, 7, 10); CI | Release readiness |
| Performance | Simulated events per second, wall time of the standard sweep | The CI performance gate (deck 07) | Users wait for it; slow simulators get bypassed |
Computed here, in the browser, from the example issue log's history: when each item entered each status. The cumulative flow diagram counts items in each status category on each day; the scatter shows each finished item's cycle time (first "In Progress" to "Done"). Little's law (LLM Inference Simulators glossary) says average WIP = throughput × average cycle time, for items that finished.
Sign-off on a simulator release, or on a simulation study that feeds a chip decision, is a judgement made from evidence. The tracker's job is to make the evidence complete and easy to check:
| Question at sign-off | Evidence |
|---|---|
| Is everything planned for 1.6 done? | fixVersion = 1.6 AND statusCategory != Done is empty, or each remaining item is explicitly deferred |
| Are the requirements verified? | The traceability matrix from the release build: no gaps (deck 09) |
| Does the simulator still agree with its references? | The validation suite's errors, against the agreed tolerances, from CI |
| Is it as fast as before? | The performance gate's report (deck 07) |
| What is known to be wrong? | Open bugs against the release (query 3), each with a stated impact |
!= skips empty fields, AND binds tighter than OR, and WAS/CHANGED only work on six fields.