Every check below re-derives the numbers LIVE, at request time, on the real database: independent raw-SQL recounts (no engine code), conservation laws between metrics, and window-additivity proofs. Green = the figure is confirmed by a second, independent path.
Independent recount (raw SQL vs engine)
iThe same figures recounted by a SECOND, independent path: raw SQL over the database, bypassing all engine code. If engine logic ever breaks, these two columns stop matching. The throughput recount appears for who=all only — the raw query deliberately knows nothing about the agent roster.| Check | Independent value | Engine value | |
|---|---|---|---|
| Throughput: raw-SQL recount of done-in-windowiWhat it checks Counts issues whose LAST transition into a done status lies inside the window and whose current status is still done (Epics excluded) — the cohort definition from the document, rewritten as one SQL query.How it's found / what is compared Found by re-counting from the raw tables with plain SQL on a second read-only connection — none of the dashboard's engine code is involved. The two columns are the independent recount and the engine's figure.Affects Throughput, Lead, Cycle, Active, TTFP, Planned/Unplanned, AI Participation — every cohort metric.If red — how to fix If red: the engine and raw SQL disagree — a CODE regression, not bad data (both read the same DB). 1) Refresh: a sync running mid-request can skew one side. 2) Still red → the engine rule changed or broke; check the latest config change on Metrics & Rules (a deviation badge there changes the rule on purpose) and the matching test in tests/requirements/. | 0 | 0 | ✓ |
| Bug Rate: raw-SQL recount of created-in-windowiWhat it checks Counts Bug/Incident issues CREATED inside the window — one SELECT over issues, nothing else.How it's found / what is compared Found by re-counting from the raw tables with plain SQL on a second read-only connection — none of the dashboard's engine code is involved. The two columns are the independent recount and the engine's figure.Affects Bug Rate tiles (prod / pre-prod / all) and the severity split.If red — how to fix If red: the engine and raw SQL disagree — a CODE regression, not bad data (both read the same DB). 1) Refresh: a sync running mid-request can skew one side. 2) Still red → the engine rule changed or broke; check the latest config change on Metrics & Rules (a deviation badge there changes the rule on purpose) and the matching test in tests/requirements/. | 0 | 0 | ✓ |
| PR Throughput: merged recountediWhat it checks Counts completed PRs of the team's repos closed inside the window — one JOIN, one COUNT.How it's found / what is compared Found by re-counting from the raw tables with plain SQL on a second read-only connection — none of the dashboard's engine code is involved. The two columns are the independent recount and the engine's figure.Affects PR Throughput and PR Acceptance.If red — how to fix If red: the engine and raw SQL disagree — a CODE regression, not bad data (both read the same DB). 1) Refresh: a sync running mid-request can skew one side. 2) Still red → the engine rule changed or broke; check the latest config change on Metrics & Rules (a deviation badge there changes the rule on purpose) and the matching test in tests/requirements/. | 0 | 0 | ✓ |
Conservation laws (one metric derived from another)
iMetrics derived FROM EACH OTHER must agree: the same cohort feeds Throughput, Lead/Cycle and Participation, so agents+humans must equal the total, severity buckets must sum to the bug count, weekly chart points must sum to the headline, and so on. A mismatch = two places silently counting differently.| Check | Independent value | Engine value | |
|---|---|---|---|
| agents + humans = throughput totaliWhat it checks The agents/humans split must partition the cohort: every done ticket is exactly one of the two (assignee in the AI roster or not).How it's found / what is compared Found by deriving one metric FROM another: both sides come from the same cohort/rows, so the identity must hold exactly. The columns show the derived value and the metric's own value.Affects The Throughput split, AI Participation, the AI Impact page.If red — how to fix If red: two modules count the same thing differently. 1) Refresh after any running sync finishes. 2) Still red → a recent code/config change broke one side; revert the latest rule change in Metrics & Rules or fix the engine (the check name says which two figures to debug). | 0 | 0 | ✓ |
| Throughput total = Lead/Cycle cohort sizeiWhat it checks Throughput and the Lead/Cycle distributions must be built from the SAME tickets — one cohort home, so the counts must match.How it's found / what is compared Found by deriving one metric FROM another: both sides come from the same cohort/rows, so the identity must hold exactly. The columns show the derived value and the metric's own value.Affects Lead, Cycle, the chart, every drill-down count.If red — how to fix If red: two modules count the same thing differently. 1) Refresh after any running sync finishes. 2) Still red → a recent code/config change broke one side; revert the latest rule change in Metrics & Rules or fix the engine (the check name says which two figures to debug). | 0 | 0 | ✓ |
| Participation = agents / totaliWhat it checks The AI Participation percent must be literally derivable from the throughput split — no separate counting path. (Only meaningful at who=all: D9 defines participation over ALL done tickets, so the check hides under a who-filter.)How it's found / what is compared Found by deriving one metric FROM another: both sides come from the same cohort/rows, so the identity must hold exactly. The columns show the derived value and the metric's own value.Affects The AI Participation tile and the AI Impact takeaway.If red — how to fix If red: two modules count the same thing differently. 1) Refresh after any running sync finishes. 2) Still red → a recent code/config change broke one side; revert the latest rule change in Metrics & Rules or fix the engine (the check name says which two figures to debug). | — | — | ✓ |
| Σ severity buckets = bug totaliWhat it checks Every bug lands in exactly one severity bucket (missing severity → 'Unspecified'), so the buckets must sum back to the total.How it's found / what is compared Found by deriving one metric FROM another: both sides come from the same cohort/rows, so the identity must hold exactly. The columns show the derived value and the metric's own value.Affects The severity split on the bug tiles.If red — how to fix If red: two modules count the same thing differently. 1) Refresh after any running sync finishes. 2) Still red → a recent code/config change broke one side; revert the latest rule change in Metrics & Rules or fix the engine (the check name says which two figures to debug). | 0 | 0 | ✓ |
| Σ weekly bug points = bug totaliWhat it checks The weekly series is the same data bucketed by ISO week — the points must add back up.How it's found / what is compared Found by deriving one metric FROM another: both sides come from the same cohort/rows, so the identity must hold exactly. The columns show the derived value and the metric's own value.Affects The bug trend series.If red — how to fix If red: two modules count the same thing differently. 1) Refresh after any running sync finishes. 2) Still red → a recent code/config change broke one side; revert the latest rule change in Metrics & Rules or fix the engine (the check name says which two figures to debug). | 0 | 0 | ✓ |
| Σ weekly PR points = mergediWhat it checks Same conservation for the PR trend series.How it's found / what is compared Found by deriving one metric FROM another: both sides come from the same cohort/rows, so the identity must hold exactly. The columns show the derived value and the metric's own value.Affects The PR weekly series.If red — how to fix If red: two modules count the same thing differently. 1) Refresh after any running sync finishes. 2) Still red → a recent code/config change broke one side; revert the latest rule change in Metrics & Rules or fix the engine (the check name says which two figures to debug). | 0 | 0 | ✓ |
| planned + unplanned = throughput totaliWhat it checks Planned-vs-unplanned classifies the SAME cohort — every done ticket is exactly one of the two.How it's found / what is compared Found by deriving one metric FROM another: both sides come from the same cohort/rows, so the identity must hold exactly. The columns show the derived value and the metric's own value.Affects The Planned vs Unplanned tile.If red — how to fix If red: two modules count the same thing differently. 1) Refresh after any running sync finishes. 2) Still red → a recent code/config change broke one side; revert the latest rule change in Metrics & Rules or fix the engine (the check name says which two figures to debug). | 0 | 0 | ✓ |
| TTFP buckets: measured + no-PR + PR-before-start = totaliWhat it checks Every cohort ticket lands in exactly one TTFP bucket — measured, no linked PR, or the PR-before-start anomaly. Nothing dropped silently.How it's found / what is compared Found by deriving one metric FROM another: both sides come from the same cohort/rows, so the identity must hold exactly. The columns show the derived value and the metric's own value.Affects Time to First PR and its disclosed buckets.If red — how to fix If red: two modules count the same thing differently. 1) Refresh after any running sync finishes. 2) Still red → a recent code/config change broke one side; revert the latest rule change in Metrics & Rules or fix the engine (the check name says which two figures to debug). | 0 | 0 | ✓ |
| Σ non-new buckets ≤ Σ cycle (gap 0d = re-opened tickets' time inside done)iWhat it checks Status-breakdown buckets exclude done-status time; Cycle keeps mid-flow done visits of RE-OPENED tickets. So buckets can never exceed cycle, and the gap measures exactly that re-opened time.How it's found / what is compared Found by deriving one metric FROM another: both sides come from the same cohort/rows, so the identity must hold exactly. The columns show the derived value and the metric's own value.Affects Status Breakdown vs Cycle consistency; the Bottlenecks pipeline.If red — how to fix If red: two modules count the same thing differently. 1) Refresh after any running sync finishes. 2) Still red → a recent code/config change broke one side; revert the latest rule change in Metrics & Rules or fix the engine (the check name says which two figures to debug). | ≤ 0 | 0 | ✓ |
Window additivity (half-open boundaries)
iCut the window in half: the two halves must add up EXACTLY to the whole. That is only true when boundaries are half-open [from, to) — no event is counted twice on the cut and none is lost. This proves the boundary rule live, on today's data.| Check | Independent value | Engine value | |
|---|---|---|---|
| Throughput: [from,mid) + [mid,to) − re-done-in-both (0) = whole windowiWhat it checks Cohort counting is EXISTS-based, so a ticket re-done in BOTH halves appears once in each — subtracting that overlap must reassemble the whole exactly.How it's found / what is compared Found by cutting the window in half and recounting both halves with the same raw SQL: with half-open [from, to) boundaries the parts must reassemble exactly (re-done tickets across the cut are counted and shown explicitly).Affects Trust in every windowed cohort count.If red — how to fix If red: an event is double-counted or lost on a boundary — some query uses BETWEEN/≤ instead of [from, to). Find the metric named in the check and fix its window comparison (and the matching test oracle). | 0 | 0 | ✓ |
| Bugs: [from,mid) + [mid,to) = whole windowiWhat it checks A bug is created exactly once, so the halves must sum exactly — any drift means a boundary bug.How it's found / what is compared Found by cutting the window in half and recounting both halves with the same raw SQL: with half-open [from, to) boundaries the parts must reassemble exactly (re-done tickets across the cut are counted and shown explicitly).Affects Bug Rate windows.If red — how to fix If red: an event is double-counted or lost on a boundary — some query uses BETWEEN/≤ instead of [from, to). Find the metric named in the check and fix its window comparison (and the matching test oracle). | 0 | 0 | ✓ |
| DF: [from,mid) + [mid,to) = whole windowiWhat it checks A deploy finishes exactly once — same exact-sum law.How it's found / what is compared Found by cutting the window in half and recounting both halves with the same raw SQL: with half-open [from, to) boundaries the parts must reassemble exactly (re-done tickets across the cut are counted and shown explicitly).Affects DF windows and rates.If red — how to fix If red: an event is double-counted or lost on a boundary — some query uses BETWEEN/≤ instead of [from, to). Find the metric named in the check and fix its window comparison (and the matching test oracle). | 0 | 0 | ✓ |
| PR merged: [from,mid) + [mid,to) = whole windowiWhat it checks A PR closes exactly once — same exact-sum law.How it's found / what is compared Found by cutting the window in half and recounting both halves with the same raw SQL: with half-open [from, to) boundaries the parts must reassemble exactly (re-done tickets across the cut are counted and shown explicitly).Affects PR Throughput windows.If red — how to fix If red: an event is double-counted or lost on a boundary — some query uses BETWEEN/≤ instead of [from, to). Find the metric named in the check and fix its window comparison (and the matching test oracle). | 0 | 0 | ✓ |
Per-ticket sanity (inequalities that must always hold)
iInequalities that hold for every single ticket by construction: work can't take longer than the whole life (cycle ≤ lead), hands-on time can't exceed the work span (active ≤ cycle), the first PR can't precede the work start, a deploy can't precede its first commit. The number shown is the count of VIOLATIONS — it must be 0.| Check | Independent value | Engine value | |
|---|---|---|---|
| cycle ≤ lead on every ticket (violations)iWhat it checks Work can't take longer than the ticket's whole life: cycle starts at/after creation and both end at done.How it's found / what is compared Found by walking EVERY ticket/change in the cohort and testing an inequality that is true by construction. The number shown is the count of violating tickets — anything above 0 is a defect.Affects Lead & Cycle credibility.If red — how to fix If red: open the offending tickets (Data quality below usually names the pattern) and look at their status history in Jira — out-of-order transitions or a wrong status mapping; re-sync jira after fixing the workflow, or fix the engine if the data is actually clean. | 0 | 0 | ✓ |
| active ≤ cycle on every ticket (violations)iWhat it checks Hands-on time is a capped subset of the work span — it can never exceed it.How it's found / what is compared Found by walking EVERY ticket/change in the cohort and testing an inequality that is true by construction. The number shown is the count of violating tickets — anything above 0 is a defect.Affects Active Work Time and Flow efficiency on Bottlenecks.If red — how to fix If red: open the offending tickets (Data quality below usually names the pattern) and look at their status history in Jira — out-of-order transitions or a wrong status mapping; re-sync jira after fixing the workflow, or fix the engine if the data is actually clean. | 0 | 0 | ✓ |
| TTFP: first PR is at/after work start (violations)iWhat it checks The measured PR is by definition the first one opened at/after the start — earlier-only tickets must sit in the anomaly bucket instead.How it's found / what is compared Found by walking EVERY ticket/change in the cohort and testing an inequality that is true by construction. The number shown is the count of violating tickets — anything above 0 is a defect.Affects Time to First PR.If red — how to fix If red: open the offending tickets (Data quality below usually names the pattern) and look at their status history in Jira — out-of-order transitions or a wrong status mapping; re-sync jira after fixing the workflow, or fix the engine if the data is actually clean. | 0 | 0 | ✓ |
| LtC: deploy is after the first commit (violations)iWhat it checks A change can't reach production before it was written.How it's found / what is compared Found by walking EVERY ticket/change in the cohort and testing an inequality that is true by construction. The number shown is the count of violating tickets — anything above 0 is a defect.Affects Lead Time for Changes.If red — how to fix If red: open the offending tickets (Data quality below usually names the pattern) and look at their status history in Jira — out-of-order transitions or a wrong status mapping; re-sync jira after fixing the workflow, or fix the engine if the data is actually clean. | 0 | 0 | ✓ |
Calculation policies — the number both ways
iSix calculation rules are toggleable per project (the registry lives on the Data Rules page). Each defaults to the document behavior. When a rule deviates, this section recomputes the affected metric BOTH ways — standard and current — so the difference shows as numbers, not words. The engines are pure functions of (data, filters, config), so the recompute is honest: only the rule changes.✓ All calculation policies = the document standard; no deviations, nothing to recompute.