Data Rules49 rulesdeviations: 2

re-verify the laws live → Verify

Transparency as a mechanism: this is the LIVE registry of every transformation between the raw Jira/ADO/BambooHR data and a number on screen — every rule, filter and fix; nothing happens silently. Each rule shows what controls it (fixed in code / a calculation policy / a tunable value / an owner tool) and its current per-project state. A deviation from the document standard glows red here, badges Metrics & Rules, and Verify recomputes the conservation laws on every load. If a number “doesn't eyeball-match Jira”, the cause is almost certainly one of these rows.

DOCa requirement of the source document/meeting — the spec says soFIXa correctness fix — without it the numbers would simply be technically wrongHONESTYan honesty rule — it discloses a gap instead of papering over itOWNERan owner tool — manual, reversible, always disclosedⓘ — hover the icon on any rule: a plain-words explanation + an example

Ingest (what changes during sync)

What happens at the moment data is downloaded from Jira / Azure DevOps / BambooHR into the local database. These rules fix the raw material (locales, API paging, stuck records) — before any math.

FIX	Accept-Language: en on every Jira request — status/type names don't depend on the account locale (the “Chinese statuses” incident).iIn plain words Jira translates status names into the language of the account that asks. Our rules match statuses by name (“Done”, “In Progress”), so a sync made under a different language would silently break every match. We force English on every request.Example Real incident: the account's locale flipped and Jira returned “已完成” (Done in Chinese). It didn't match the done-status list — completed tickets vanished from Throughput until the fix + re-sync.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
FIX	Status category is resolved by status ID from the changelog (name is only a fallback): Jira names are not unique.iIn plain words Every Jira status belongs to a category (To Do / In Progress / Done) — the metrics depend on it. Two different statuses in different workflows can share one NAME, so we resolve the category by the status's unique ID, not by its name.Example “Ready” can be an intake status (To Do) in one workflow and a pre-release status (In Progress) in another. By name they'd get mixed up; by ID they never are.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
FIX	Ticket upsert heals issueType, key and projectKey — moves/renames/locale poisoning don't freeze in.iIn plain words When a ticket is re-synced, its type, key and project are UPDATED to the current truth instead of keeping whatever was saved first. Otherwise a moved or renamed ticket (or one saved during the locale incident) would stay wrong forever.Example ADS-1342 was stored with type “长篇故事” (Epic in Chinese) during the locale incident. The healing re-sync corrected it back to “Epic”, so the Epic-exclusion rule applied again.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
DOC	PR↔ticket link: jira_keys extracted by regex from PR title + source branch, uppercased.iIn plain words Azure DevOps pull requests don't know anything about Jira. We build the link ourselves: if the PR title or its branch name mentions a ticket key (like ADS-123), the PR is associated with that ticket. Time To First PR depends on this link.Example Branch “feature/ads-123-fix-banner” → the PR links to ADS-123 (case doesn't matter, “ads-123” is uppercased).Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
FIX	PR commits are fetched in a continuation loop ($top=500 per page, until exhausted) — the earliest commit survives for a PR of ANY size.iIn plain words The API returns commits in pages (~100 by default). Lead Time for Changes starts at the EARLIEST commit — if only the first page were taken, a big PR's oldest commit would get lost and the metric would start too late, flattering the number. We keep following the continuation token until the API says there are no more pages.Example A PR with 150 commits: a single default page would make the “first” commit the 101st — days of real work silently gone from LtC. The loop walks all pages (live-verified: page 1 emits x-ms-continuationtoken, page 2 continues with no overlap).Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
FIX	Builds and release deployments are fetched in continuation loops (builds used to be cut at 200).iIn plain words Same paging problem for the deployments list: one page used to bring at most 200 builds, older deployments fell off, and Deployment Frequency / CFR were computed from an incomplete history. Now we keep requesting pages until the API says there are no more.Example A 365-day window with 311 deployments: a single page of 200 would lose the oldest 111 — DF would look ~36% lower than reality.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
HONESTY	A deployment without completedOn/status is skipped — an unfinished run is not an event.iIn plain words A deployment that is still running has no finish time and no final result. Counting it would mean guessing — it might still fail a minute later. Only finished runs become events; an in-flight one is simply not data yet.Example A release started at 14:00 and still deploying at 14:05 (sync time) is skipped; tonight's sync will pick it up with its real result.Rule type HONESTY — an honesty rule — it discloses a gap instead of papering over itHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
HONESTY	Deployments upsert with onConflictDoNothing — a re-sync can never wipe manual failure flags.iIn plain words The owner can manually mark a deployment as a failure (e.g. it was rolled back after an incident). A nightly re-sync re-downloads the same rows — this rule guarantees the re-download never overwrites those manual marks.Example You flag yesterday's “succeeded” release as a failure today; tomorrow's 07:30 auto-sync runs — the flag survives, CFR keeps counting it as a failure.Rule type HONESTY — an honesty rule — it discloses a gap instead of papering over itHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
FIX	Disabled (isDisabled) ADO repos are skipped — their PR API errors out.iIn plain words Azure DevOps lets a repository be disabled (archived). Its pull-request API then returns an error instead of data. We skip such repos so one dead repo can't crash the whole sync.Example An old archived prototype repo in the team's project errors on /pullrequests — it is skipped and the other repos sync normally.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
FIX	Employee country: full name → ISO-2 via dictionary; a holiday's country comes from its name prefix (“US …”).iIn plain words Active Work Time subtracts public holidays of the EMPLOYEE'S country. BambooHR stores countries as full names (“United States”), while holidays are named like “US Independence Day” — both are normalized to one two-letter code so they can actually match.Example “United States” → US; holiday “US Thanksgiving” → US. Now an NY-office engineer's Active time correctly skips Thanksgiving.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
FIX	sync_runs rows stuck “running” for >2h are closed as error “interrupted”.iIn plain words Every sync writes a journal row “running → finished”. If the process is killed mid-way (laptop closed, power loss), the row would say “running” forever and the UI would think a sync is still in progress. After 2 hours such a row is honestly closed as “interrupted”.Example A sync started at 10:00, the laptop slept at 10:03. At 12:05 the stuck row is auto-closed as an error — the Sync page shows a real failure instead of an eternal spinner.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code

Cohort (THE single entry for ticket metrics)

The cohort = which tickets count as “done in the window” at all. Every ticket metric (Throughput, Lead, Cycle, TTFP…) reads exactly this one list — that's why the counts always reconcile across pages.

DOC	done_at = the LAST entry into a done status inside the window; the current status must still be done (re-opened tickets drop out).iIn plain words “When was the ticket done?” = the moment of its LAST transition into a done status (Done/Resolved/Closed), and the ticket must still be done right now. A ticket that was closed and then re-opened is not finished work — it leaves the cohort until it's closed again. This one definition feeds EVERY ticket metric (one home).Example A ticket closed June 5, re-opened June 10, closed again June 20 → its done date is June 20 and it counts ONCE in Throughput, not twice.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	doneStatusesADS: Done, Resolved, ClosedEVO: Done, Resolved, Closed
DOC	All windows are half-open [from, to) — no double counting on boundaries.iIn plain words Every time window includes its start moment and EXCLUDES its end moment. That way two adjacent windows (e.g. two halves of a quarter) share a boundary but never share an event — each event lands in exactly one window. The Verify page re-checks this by cutting a window in half and re-adding the parts.Example A deploy at exactly 00:00 June 1: the May window [May 1, Jun 1) does NOT count it, the June window [Jun 1, Jul 1) does. Counted once, lost never.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
DOC	Excluded issue types (Epics) never enter any metric.iIn plain words An Epic is a container for other tickets, not a unit of work. If Epics counted, the same work would be counted twice — once as the Epic, once as its tickets — and a closed Epic with a year-long life would wreck the Lead median. The document explicitly requires excluding them.Example Epic “Q2 Player Improvements” lived 9 months and closed in June. Without this rule June's Lead median would jump from ~5 days to ~20.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	excludedIssueTypesADS: EpicEVO: Epic
OWNER	Manual exclusions — ONE shared mask: a ticket, an epic/feature WITH all descendants, an ADO repo (its PRs leave PR/TTFP/LtC) or a pipeline (its runs leave DF/CFR); disclosed by the “✕ N” chip and in Data quality.iIn plain words The owner can exclude broken data from every metric through one reversible mask with four kinds: a single ticket; an epic/feature together with EVERY descendant (parent links walked transitively); an ADO repository (its pull requests leave the PR metrics, Time To First PR and Lead Time for Changes); a pipeline (its runs leave Deployment Frequency and CFR). Nothing is deleted — the rows stay in the database and in the source systems; every consumer reads the SAME mask, so an exclusion applies everywhere at once.Example A 2023 ticket bulk-closed in 2026 shows Lead = 700+ days — exclude the ticket. A migration epic with 40 auto-closed children skews a whole quarter — exclude the epic, all 40 leave with it. An archived repo full of bot PRs inflates PR Throughput — exclude the repo.Rule type OWNER — an owner tool — manual, reversible, always disclosedHow it's controlled A manual owner action, not automation. Always reversible and always disclosed in the UI (nothing disappears silently).	owner toolcurrently excluded: 0
DOC	who-filter: assignee ∈ AI-agent roster / not; deployments, PRs, bugs and IMC incidents are who-blind.iIn plain words The agents/humans filter splits tickets by ASSIGNEE: there is an explicit roster of AI-agent accounts; a ticket assigned to one of them counts as agent work. Deployments, PRs, bugs and IMC incidents don't have an “assignee” in this sense, so the filter doesn't apply to them — they show the same numbers under any who-filter.Example A ticket assigned to agent Oliver counts under “agents”; the deploy that shipped it appears in DF regardless of the filter.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code

Lead / Cycle / Active

The time metrics: how long a ticket lived (Lead — created→done), how long the work took (Cycle — started→done), and how much of it was hands-on work (Active — minus waiting, weekends, vacations).

DOC	Lead = created → done_at in calendar days (weekends included — the document standard).iIn plain words Lead Time = how long from “ticket created” to “ticket done”, in CALENDAR days. Weekends, holidays and waiting are INCLUDED on purpose — the document says waiting must not be excluded: the customer experiences the full elapsed time, not just the working part.Example Created Friday 18:00, done Monday 18:00 → Lead = 3 days, not 1. The weekend counts because the requester waited through it.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	includeNonWorkingDaysADS: ONEVO: ON
DOC	Cycle start = the FIRST transition into the In-Progress category (≤ done_at); never started → cycle = null, not 0. Empty list = the canonical category rule.iIn plain words Cycle Time = from “work actually started” to “done”. The start is the FIRST time the ticket entered any In-Progress-category status. If a ticket never entered one (created and closed directly), Cycle is honestly “no data” rather than a fake 0. By default the rule uses the Jira category (works for every team's status names); a team can override with an explicit status list.Example A duplicate closed straight from the backlog has Lead (created→closed) but no Cycle — it never was “in progress”. With 0 instead of null the Cycle median would be dragged toward zero by non-work.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	cycleStartStatusesADS: —EVO: —
DOC	Time after a bounce back into a “new”-category status is SUBTRACTED from Cycle (the meeting's own “bug to fix”).iIn plain words If a started ticket is thrown back into the queue (In Progress → New) and sits there, that sitting time is NOT work — the document explicitly says time back in New must not be counted. We subtract every such interval from Cycle (and from Time To First PR, which follows the same rules).Example 2 days in progress → bounced to New for 10 days → 1 more day in progress → done. Cycle = 3 days, not 13.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	subtractBounceBackADS: ONEVO: ON
FIX	Cycle/TTFP are clamped at Math.max(0, …).iIn plain words A safety net against messy status histories: after all subtractions a duration can mathematically go slightly negative (e.g. transitions recorded out of order). Negative time doesn't exist — the floor is 0.Example A ticket bounced to New for 5 days inside a 4.9-day cycle window (clock skew in history) would compute to −0.1 d → clamped to 0.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
DOC	Active: non-passive statuses only, weekdays only, minus vacations (BambooHR) and country holidays, capped per day; SHOWN in a selectable unit (calendar ÷24 · working days ÷8/9 · hours), chart always calendar.iIn plain words Active Work Time answers “how much of the cycle was actual hands-on work?”. The MATH is one number: per workday, hours in non-passive statuses (waiting statuses like On Hold/Blocked/Ready To Test thrown away), weekends, the assignee's approved BambooHR vacations and their country's holidays contribute nothing, and each day is capped at the standard working day (the document: “8 or 9 hours”). The UNIT it is shown in is selectable (the page toggle and the admin default): calendar days (÷24 — same axis as Lead/Cycle, so active ≤ cycle always holds and the gap IS the waiting), working days (÷8/9 — the document-literal “days of effective work”; NOT comparable with calendar Cycle, so the chart never uses it), or raw hours (zero ambiguity). The big chart always draws Active in calendar scale — the document wants Active as the lowest of the three lines.Example A ticket “in progress” 7 calendar days, 2 of them Blocked plus a weekend → ≈ 3 workdays × 8h = 24h of active work. The SAME 24h shown per unit: 1.0 d (calendar, ÷24) · 3.0 wd (working days, ÷8) · 24h (hours).Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	passiveStatusesADS: On Hold, Blocked, Failed on QA, Ready To Test, Ready To MergeEVO: On Hold, Blocked, Failed on QA, Ready To Test, Ready To MergeworkingHoursPerDayADS: 8EVO: 8
HONESTY	Active for people not linked to BambooHR is computed without vacations (a “no HR” badge discloses it).iIn plain words Linking a Jira person to BambooHR happens by work e-mail. If someone didn't match (a contractor, an AI agent, a different e-mail), their vacations are unknown — Active is then computed without the vacation subtraction and the UI says so with a badge instead of silently pretending the data was there.Example An AI agent has no BambooHR record at all — its Active rows carry the “no HR” badge, so nobody mistakes the number for vacation-adjusted.Rule type HONESTY — an honesty rule — it discloses a gap instead of papering over itHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code

TTFP / LtC / PR

The code-side metrics: how fast the first pull request appears (TTFP), how long code travels to production (Lead Time for Changes), and PR throughput/acceptance.

DOC	TTFP = the first PR opened AT/AFTER work start (spec M5); bounce-back time is subtracted (“same rules as Cycle”).iIn plain words Time To First PR = how long after starting work the first pull request appeared. Among the ticket's linked PRs we take the first one opened AT or AFTER the work start (an older PR from before the start is a different story — see the next rule). Time bounced back into the queue is subtracted, same as Cycle.Example Work started June 1, the linked PR opened June 3 → TTFP = 2 days. A fast TTFP is the document's own signal of AI-assisted speed.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
DOC	Tickets whose ONLY PRs predate the start → a separate disclosed prBeforeStart bucket (not 0 and not “no PR”); bucket sums = cohort (a law).iIn plain words Sometimes the PR exists BEFORE the ticket is moved to In Progress (a PR-first flow: code written, then the ticket is formally started). What is “time to first PR” then? The standard answer: such tickets go into a separate, visible “PR before start” bucket and don't distort the median. The alternative (policy OFF): count them as 0 days — the PR was already there at start. Either way every cohort ticket lands in exactly one bucket; Verify checks that sum as a law.Example An agent opens a PR at 10:00; a human moves the ticket to In Progress at 11:00. Standard: the ticket is disclosed as an anomaly. Policy OFF: it enters the median as 0 days.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A calculation policy: can be switched ON/OFF per project (the default = the document behavior). OFF is a deviation — it glows red here and in the admin, the affected formula gets a DEVIATES badge, and the Verify page computes the number BOTH ways so the difference is visible as numbers. ON (standard, spec M5/T007): tickets whose only PRs predate work start sit in a disclosed anomaly bucket, excluded from the median. OFF: they enter the median as 0 days (the PR already existed at start).	ttfpAnomalyBucketADS: ONEVO: ON
DOC	LtC = first commit → the FIRST successful prod deploy AFTER merge; changes not yet in prod are honestly not counted.iIn plain words Lead Time for Changes (a DORA metric) = from the first line of code (the PR's earliest commit) to that code actually reaching production (the first successful prod deployment after the merge). A merged change that hasn't been deployed yet is NOT counted — it hasn't reached users, there is nothing to measure yet.Example First commit June 1, merged June 3, the next successful prod release June 5 → LtC = 4 days.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
DOC	PR metrics: only terminal (completed/abandoned) PRs closed in the window; acceptance = merged/(merged+abandoned).iIn plain words PR Throughput and PR Acceptance only count pull requests whose fate is decided — merged (completed) or closed without merging (abandoned) — within the window. Still-open PRs are not counted: their outcome is unknown. Acceptance = the share of decided PRs that were merged.Example In a window: 9 merged, 1 abandoned, 4 still open → throughput counts 9, acceptance = 9/(9+1) = 90%; the 4 open ones wait for their fate.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
DOC	Agent PR authorship: author_id ∈ the roster (adoUserId).iIn plain words “This PR was authored by an AI agent” is decided strictly by the author's Azure DevOps account being in the explicit agent roster — no guessing from text, branch names or commit messages.Example PRs by the “Oliver” service account count as agent PRs; a human's PR that merely mentions “AI” in the description does not.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code

Deployments (DF / CFR)

The DORA deployment metrics: how often we ship to production (Deployment Frequency) and what share of those shipments breaks (Change Failure Rate).

FIX	Environment tier by name: LOWER tokens are checked FIRST (substring guard: “pre-production” is not prod); unrecognized → unknown, kept out of prod and disclosed as a count.iIn plain words Which deployment counts as PRODUCTION? We classify by the environment's name. The trick: lower-environment words (staging, pre-production, qa…) are checked BEFORE prod words (production, prod, live) — otherwise “Pre-Production” would match “production” and pollute prod numbers. A name matching nothing → “unknown”: kept out of prod and shown as a count instead of being silently dropped or guessed.Example “Pre-Production EU” → lower (even though it contains “production”); “Prod-West” → prod; “Blue环境” → unknown, disclosed as “1 deploy with unrecognized environment”.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	preProdEnvNamesADS: pre-prod, preprod, pre-production, staging, stage, canary, alpha, beta, qa, test, dev, sandbox, uat, featureEVO: pre-prod, preprod, pre-production, staging, stage, canary, alpha, beta, qa, test, dev, sandbox, uat, featureprodEnvNamesADS: production, prod, prd, live, stableEVO: production, prod, prd, live, stable
FIX	Build pipelines marked as deploying: tier by the DEFINITION NAME; unrecognizable name = PROD (the mark itself means “this deploys”).iIn plain words YAML build pipelines don't expose an environment name, so name-based classification used to leave every team-marked deploy pipeline in the “unknown” tier — silently keeping it OUT of DF, CFR and LtC. The fixed rule: a build-deploy's tier comes from its definition name when a token is recognizable (“TEST-deploy…” → lower), otherwise it counts as PROD — the owner explicitly marked the pipeline as deploying, that's exactly what the mark means.Example “aks-deploy” and “Deploy cluster-defaults chart” → prod (counted in DF/CFR); “TEST-deploy-pipeline-to AKS” → lower, honestly out of prod.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
DOC	CFR denominator = ELIGIBLE runs (success ∪ failure); canceled/notDeployed are excluded and disclosed (ineligibleProd).iIn plain words Change Failure Rate = the share of production deployments that failed. The standard denominator counts only runs that actually CONCLUDED as success or failure. A canceled or never-started run didn't change production — counting it would water the percentage down. The excluded count is always shown. Policy OFF = the deviation where every completed prod run counts.Example 10 prod runs: 6 succeeded, 2 failed, 2 canceled. Standard CFR = 2/8 = 25%. With the policy OFF: 2/10 = 20% — looks better, means less.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A calculation policy: can be switched ON/OFF per project (the default = the document behavior). OFF is a deviation — it glows red here and in the admin, the affected formula gets a DEVIATES badge, and the Verify page computes the number BOTH ways so the difference is visible as numbers. ON (standard): the CFR denominator counts only runs that succeeded or failed; canceled/notDeployed never reached prod and stay out. OFF: every completed prod run counts — the percentage gets diluted.	cfrEligibleOnlyADS: ONEVO: ON
FIX	The manual flag OVERRIDES the result: a flagged succeeded run is a failure and NOT a success (succeeded+failed=total — a law).iIn plain words The pipeline can finish green while the release actually failed (rolled back an hour later, hotfixed after an incident). Until Incident Management is integrated, the document's bridge is a manual failure mark. Standard: the mark OVERRIDES the pipeline result — the run is a failure only, so succeeded + failed = total stays a law. Policy OFF: the mark only ADDS a failure while the green result still counts as a success — the same run counted twice (the double count is disclosed).Example A release went green at 14:00 and was rolled back at 15:00. The owner flags it: DF loses one “success”, CFR's numerator gains one failure. This very rule caught a real bug when succeeded+failed exceeded total.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled A calculation policy: can be switched ON/OFF per project (the default = the document behavior). OFF is a deviation — it glows red here and in the admin, the affected formula gets a DEVIATES badge, and the Verify page computes the number BOTH ways so the difference is visible as numbers. ON (standard): a run flagged as a failure counts as a failure ONLY — succeeded + failed = total stays a law. OFF: the flag only adds a failure; a flagged succeeded run still also counts as a success (double-counted, disclosed).	manualFlagOverridesResultADS: ONEVO: ON
DOC	DF = successful prod deploys; rates per day / week / month (month = monthDays).iIn plain words Deployment Frequency = how many SUCCESSFUL production deployments happened, plus the document's three rates: per day, per week, per month. Which pipeline results count as “successful” is a configurable list; the “month” length for the monthly rate is a number (30 by default).Example 32 successful prod deploys over 90 days → 0.4/day, 2.5/week, 10.7/month (with a 30-day month).Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	successResultsADS: succeededEVO: succeededmonthDaysADS: 30EVO: 30
DOC	IMC candidates NEVER change CFR automatically; a human flags the specific deploy run (C5: rollback/hotfix for a P0/P1 from shipped code).iIn plain words PDF p6 says a failure is a rollback OR hotfix for a P0/P1 major incident — only if caused by shipped code. The transcript says to start with high confidence; a candidate is P0/P1 OR User blocked OR All users affected. Confirming a candidate as a real failure is the existing per-run manual flag: a human finds that date’s run in the CFR drill, verifies it was caused by shipped code, and flags that run. Zero new write paths exist — the panel is read-only enrichment that makes candidates visible for review, and CFR stays at its formula-computed value until a run is explicitly flagged.Example IMC-66 (P2, User blocked, no deploy link) → review candidate, NOT a failure; CFR stays 0/24 until a human flags a run.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code

Bugs (Quality)

Quality: how many bugs appear and how severe they are; split into production / pre-production when the tickets carry environment labels.

DOC	A bug = Bug/Incident CREATED in the window.iIn plain words Bug Rate counts tickets of bug types (Bug, Incident) by their CREATION date — when the problem became known — not by when they were fixed. That answers “how many problems did this period produce?” rather than “how many did we get around to closing?”.Example A bug created May 30 and fixed June 5 belongs to MAY's bug count. June's count only gets bugs discovered in June.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	unplannedIssueTypesADS: Bug, IncidentEVO: Bug, Incident
HONESTY	severity NULL → “Unspecified” (never dropped); first matching severity field wins.iIn plain words Bug severity lives in custom Jira fields, and different projects use different ones — we check a configurable list of real field ids and take the first that has a value. A bug with NO severity at all isn't thrown away: it lands in an explicit “Unspecified” bucket, so the severity split always sums back to the total.Example 20 bugs: 3 Critical, 9 High, 5 Medium, 3 with an empty field → the chart shows 3+9+5+3 (“Unspecified”), never 17 with 3 missing.Rule type HONESTY — an honesty rule — it discloses a gap instead of papering over itHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	severityFieldsADS: customfield_10050, customfield_10511, customfield_10093EVO: customfield_10050, customfield_10511, customfield_10093
DOC	Partial env labeling: prod + preProd + unknown = all (a law); headline = prod once ANY label exists, but the unlabeled remainder is always disclosed.iIn plain words Bug tickets may be labeled with an environment (production, staging, ...) or not at all. The engine always keeps three separate buckets — prod, preProd, and unknown — and the identity prod+preProd+unknown=all is a hard law (Verify checks it). Once even a single bug carries an env label, the headline switches to the prod count. But switching the headline NEVER hides the unlabeled bugs: the tile and preview always disclose the unknown count and the coverage percentage. A team that labels half its bugs will see the split for those half — and an explicit warning that the other half is unaccounted for.Example 20 bugs, 1 labeled production — headline Prod Bug Rate: 1, note: 19 env unknown · labeled 5%. Removing the bucket would silently shrink 20 to 1.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
HONESTY	Environment comes from ticket labels; no labels → the prod/pre-prod split is honestly “unavailable”, ALL bugs still shown + which labels are needed.iIn plain words The document wants bugs split into “found on production” vs “found before production”. The only signal on a Jira ticket is its labels (production / staging / qa…). If the team doesn't put such labels, the split is shown as honestly UNAVAILABLE — with the total bug count still visible and a hint listing which labels would enable the split. We never guess an environment.Example 0 of 20 bugs carry an env label → the tile says “environment unknown (no env labels)” instead of inventing a 50/50 split.Rule type HONESTY — an honesty rule — it discloses a gap instead of papering over itHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	prodEnvLabelsADS: production, prodEVO: production, prodpreProdEnvLabelsADS: pre-prod, preprod, pre-production, staging, qaEVO: pre-prod, preprod, pre-production, staging, qa
DOC	IMC incidents map to teams by the Engineering Teams field (exact array-element match), computed at read time — never stored.iIn plain words IMC incident tickets carry an Engineering Teams field whose value is an array of strings — one element per owning team. Text-search and stored mapping tables were rejected: text-search fails when a token is a substring of another team name, and a stored mapping goes stale the moment the config changes. Instead, mapping is computed fresh on every read by checking whether any array element exactly matches a token in imcTeamTokens. Two important disclosures: IMC incidents are who-blind (no assignee dimension — the agents/humans filter does not slice them); the manual exclusions mask does NOT apply to incident enrichment (badges attach to drill rows that already passed the mask, but linked counts include links to any issue regardless of exclusions).Example "Ad Tech, Core Tech" arrives as ["Ad Tech","Core Tech"] → token "Ad Tech" → ADS.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled A tunable value (a list or a number) editable per project on the Metrics & Rules page (owner key required). Any difference from the document default is highlighted red, so a customized rule can never look like the standard one.	imcTeamTokensADS: Ad TechEVO: EVO

Status breakdown / Bottlenecks / CFD

Where the time actually goes: per-status time totals, what is stuck in work right now (Aging WIP) and where queues grow week over week (the Cumulative Flow Diagram).

DOC	Status Breakdown: intervals from start to done; done statuses excluded; the “new” category is shown but marked “excluded from Cycle”.iIn plain words The status breakdown answers “where did the time go?”: for every completed ticket we slice its life from work start to done into per-status intervals and sum them up. Time INSIDE a done status doesn't count (the ticket is already finished there). Queue statuses (the “new” category) are shown for honesty but marked as not being part of Cycle.Example A ticket spent 1 d In Progress, 3 d Ready To Test, 1 d In Testing → the breakdown shows Ready To Test as the biggest bucket — the bottleneck is the QA queue, not coding.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
HONESTY	Law: Σ of non-new buckets ≤ Σ cycle; the gap = re-opened tickets' time inside done (measured and disclosed on Verify).iIn plain words A self-check identity between two independent computations: the sum of all working-status buckets can never exceed the sum of all Cycle times (the buckets are pieces of those cycles). The small remaining gap has an exact meaning — time that RE-OPENED tickets spent sitting in a done status mid-flow — and Verify measures it live instead of hand-waving.Example Σ buckets = 120 d, Σ cycle = 124 d → the 4-day gap is exactly the done-time of tickets that were closed, re-opened and closed again.Rule type HONESTY — an honesty rule — it discloses a gap instead of papering over itHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
FIX	Workflow strip: one pill per status NAME (dominant category by transition count).iIn plain words The workflow strip shows the team's real statuses as pills. Over the years a status NAME can exist in two categories (workflows get rebuilt, tickets move between projects) — history then contains e.g. “Ready” as To Do AND “Ready” as In Progress. Standard: show ONE pill per name, colored by the category that dominates its history. Policy OFF: show every (name, category) pair — duplicates become visible.Example “Ready” logged 480 transitions as To Do and 20 as In Progress (after a workflow rebuild) → one To Do pill. Policy OFF would show two “Ready” pills.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled A calculation policy: can be switched ON/OFF per project (the default = the document behavior). OFF is a deviation — it glows red here and in the admin, the affected formula gets a DEVIATES badge, and the Verify page computes the number BOTH ways so the difference is visible as numbers. ON (standard): history can carry two categories for one status name (recategorized workflows) — the strip shows the dominant category instead of duplicate pills. OFF: one pill per (name, category) pair, duplicates visible.	breakdownMergeSameNamePillsADS: ONEVO: ON
HONESTY	Aging WIP: only the In-Progress category (backlog rot like “Removed, 777 d” is not WIP).iIn plain words Aging WIP lists what is hanging IN WORK right now and for how many days nothing moved. Standard: only tickets in In-Progress-category statuses — that's what “work in progress” means. A ticket rotting in the backlog for two years is a real fact but a different problem; letting it in would drown the chart in 777-day rows and hide the actually stuck work. Policy OFF: every non-done ticket counts, backlog included.Example “In Testing, 14 d silent” is a stuck-work signal worth acting on; “Removed, 777 d” is backlog archaeology. The standard shows the first and not the second.Rule type HONESTY — an honesty rule — it discloses a gap instead of papering over itHow it's controlled A calculation policy: can be switched ON/OFF per project (the default = the document behavior). OFF is a deviation — it glows red here and in the admin, the affected formula gets a DEVIATES badge, and the Verify page computes the number BOTH ways so the difference is visible as numbers. ON (standard): only tickets in an In-Progress-category status count as work in progress — backlog rot is real but it is not WIP. OFF: every non-done ticket counts (backlog included).	agingWipOnlyInProgressADS: ONEVO: ON
HONESTY	CFD: work stages only, top-8 by peak (the backlog and done bands drowned the queues that matter).iIn plain words The Cumulative Flow Diagram shows, week by week, how many tickets sat in each stage — widening bands reveal growing queues. Standard: only working stages (statuses whose history is dominated by the In-Progress category), capped at the 8 most populated, because a 1200-ticket backlog band squashes every meaningful queue into invisibility. Policy OFF: any non-done status competes for those 8 bands.Example With the backlog band on, “Ready To Test” growing from 5 to 20 tickets is a flat line at the bottom; without it the growth is plainly visible.Rule type HONESTY — an honesty rule — it discloses a gap instead of papering over itHow it's controlled A calculation policy: can be switched ON/OFF per project (the default = the document behavior). OFF is a deviation — it glows red here and in the admin, the affected formula gets a DEVIATES badge, and the Verify page computes the number BOTH ways so the difference is visible as numbers. ON (standard): CFD bands are statuses whose dominant category is In Progress (top 8 by peak) — a 1000-ticket backlog band drowns every queue that matters. OFF: any non-done status competes for the top 8.	cfdWorkStagesOnlyADS: ONEVO: ON
OWNER	Suspect thresholds (180/365/730/custom) are view-level — they never change data.iIn plain words The Exclusions tool has a “suspects” list — candidates for cleanup (tickets with absurdly long lives). The threshold pills (180/365/730 days or a custom number) only change WHICH candidates are LISTED on screen. They change no metric and no stored data; only an explicit exclusion by the owner does.Example Switching the threshold from 365 to 180 days makes the suspects list longer — every chart on every page stays exactly the same.Rule type OWNER — an owner tool — manual, reversible, always disclosedHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code

Display level (stored data untouched)

How numbers LOOK on screen — rounding, medians, one abbreviation. Nothing here changes the stored data.

DOC	round1 for display; MEDIANS for “averages” (robust to outliers — a spec decision).iIn plain words Two display conventions: numbers are rounded to one decimal only AT display time (the math underneath is exact), and wherever the document says “average”, we show the MEDIAN — the middle value. One ancient 400-day ticket would drag a mean far from what the team actually experiences; the median barely moves.Example Lead times [2, 3, 4, 400]: the mean is 102 days (nonsense for planning), the median is 3.5 — what a typical ticket really takes.Rule type DOC — a requirement of the source document/meeting — the spec says soHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
FIX	“Product Backlog Item” → “PBI” (full name kept in the title attribute).iIn plain words Pure cosmetics: the issue-type name “Product Backlog Item” is too long for table cells and chips, so it is shortened to “PBI” on screen. Hovering shows the full name; the stored data is untouched.Example A drill-down table shows “PBI” in the type column; the tooltip on hover reads “Product Backlog Item”.Rule type FIX — a correctness fix — without it the numbers would simply be technically wrongHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code
HONESTY	Names/categories/keys are NEVER rewritten for display — the PBI shortening is the only one.iIn plain words A promise about everything else: status names, ticket keys, categories and labels appear on screen exactly as they are in Jira/ADO. No “beautification”, no renaming, no merging of similar-looking names. What you see is what the source systems contain — so you can always cross-check by opening the ticket.Example If a team's status is literally called “Failed on QA ”, with a trailing space — that's how it renders. Fixing it belongs in Jira, not in the dashboard.Rule type HONESTY — an honesty rule — it discloses a gap instead of papering over itHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code

Owner / admin (visibility, not data)

What the owner can switch on/off by hand — and the honesty boundary that no switch can cross.

OWNER	Admin flags hide pages/elements for everyone; the owner key reveals all; rule and exclusion writes are key-gated.iIn plain words There is a hidden admin with on/off switches for every page, section and element — what every visitor sees. Flipping a switch applies instantly for everyone. The owner's key reveals everything regardless of the switches, and any WRITE (editing rules, excluding tickets, these very policies) requires that key. Important: this controls VISIBILITY of interface parts, never the data or the math.Example Hiding the Team page before a demo: visitors don't see it in the nav and its URL gives 404 — while the numbers on every other page stay byte-identical.Rule type OWNER — an owner tool — manual, reversible, always disclosedHow it's controlled A manual owner action, not automation. Always reversible and always disclosed in the UI (nothing disappears silently).	owner tool
HONESTY	Hiding never touches the honesty disclosures: the “✕ N excluded” chip and Data quality stay visible always.iIn plain words The boundary of the previous rule: disclosures that keep the numbers honest can NOT be hidden by any switch. If tickets are excluded, the “✕ N” chip shows for everyone; data-quality warnings (unrecognized environments, bugs without severity, tickets without PRs) always render. Hiding UI must never become falsifying data.Example Even with every optional element switched off, a visitor still sees “✕ 2 excluded” on the Overview if two tickets are excluded.Rule type HONESTY — an honesty rule — it discloses a gap instead of papering over itHow it's controlled Baked into the code and always on. It is not a setting — it is a property of the engine: either the rule holds, or the metric would simply be wrong.	always · in code