Development record

A failed fidelity verdict becomes work somebody can see

intentdraftsminoritd-165

Press Release

Seeded from a quoted-text intent capture. Expand into the full press-release narrative before planning.

Why This Matters

When an audit judges an acceptance criterion not met, the ingest counts it into a rollup, renders it into the shipped intent's audit notes, and stops. No record is created, no exit code changes, and no gate reads it. An intent can ship with every criterion failed and the only consequence is prose nobody queries.

The verdict's consumer is the facilitator, which is a machine by default, so turning a failure into a tracked item is the loop's own bookkeeping rather than an automation somebody has to be persuaded to accept. Each not-met criterion becomes one ledger record stamped with the receipt identifier and deduplicated on it, so a re-ingest cannot mint a second record for the same failure, and the record identifier is written back into the audit notes so the edge is two-sided like every other link in the record.

An inconclusive verdict deliberately does not create a record. It means the auditor was under-fed, which is an input fault rather than a product defect, and minting records for it at volume would fill the ledger with noise and teach a reader to ignore it. It must still leave the receipt visibly outstanding, or a verdict that decided nothing becomes indistinguishable from one that passed.

What blocks depends on the facilitator's mode (adr-2609151528057260): a machine facilitator works the queue, and an activated human facilitator is what the queue waits for. The ratchet that would make a new failure fail a gate is deliberately not part of this: it is sequenced behind a corpus of real verdicts, because there are none yet and a ratchet baselines whatever number it finds.

Acceptance Criteria

Required (the itd-1 discipline): add at least one Given-When-Then bullet describing the verifiable bar for "shipped" before this draft can be planned.

SOTA

Surveyed on 2026-10-23; sources, evidence tiers and the local fit risks are in the verification-assurance SOTA note.

A finding's identity is a fingerprint built to survive edits. SARIF 2.1.0: a fingerprint "SHALL be a string that provides a stable identifier for the result", "resistant to changes that do not affect the logical identity of the result, such as ... the line number where a result appears"; baselineState marks each result new, unchanged, updated or absent against a baseline run (SARIF 2.1.0 specification).
The forge dedups on the fingerprint and closes on disappearance. Code scanning matches results across runs "so they only appear once"; ruleId must be stable; a changed path creates a new alert and closes the old; an upload without fingerprints yields duplicate alerts (forge documentation, SARIF support for code scanning).
A bot filing one record per recurring failure states its rules in the record: "The bots will update this with information from each new failure", "will re-open if the flake re-occurs", and will "follow the duplicate chain" if a person closes it as a duplicate (a WebKit flaky-test bug filed by the review bot).
Test formats keep "could not judge" apart from "failed", and still count it. JUnit XML separates failure (an assertion failed) from error (unexpected problem running the test) and skipped, each with its own suite count; TAP 14 says a harness "must not treat failing SKIP test points as a test failure" yet counts them and may report a passing TODO so it can be promoted. The intent's inconclusive-mints-nothing rule matches; the counted, listed, visibly-outstanding rendering is what keeps it from reading as a pass.
Where research touches the intent's mechanism: deduplicating on the receipt identifier alone stops a re-ingest minting twice, but a later verdict on the same still-unmet criterion carries a new receipt and would mint a second record. SARIF's shape keys on what the finding is (here: intent and criterion id) and records each run that found it.
Locally, the verdict already carries receipt_id, criterion_id, verifier and per-criterion NOT_MET / INCONCLUSIVE; findingkey.Derive is the repository's existing fingerprint for consistency findings; the capture duplicate check matches prose.

Path 2: native records keyed by a fingerprint shaped to SARIF, not by the receipt alone. One record per (intent, criterion id) found NOT_MET, carrying the receipt that minted it and every later receipt that found it again; a re-ingest marks it unchanged; a later receipt that no longer finds it marks it absent and leaves it for the facilitator to resolve with that receipt as grounds, never an automatic close or reopen. INCONCLUSIVE mints nothing and renders as a counted, named outstanding set on the receipt. The key's name is versioned, as SARIF versions its fingerprint keys, so a later change to its inputs does not orphan existing records. The record id is written back into the audit notes, as the intent requires. No dependency. The independent fit-challenge runs at plan time.

Open Questions

Decided 2026-08-29 (product thinker). An unmet criterion goes on the facilitator's list. The product thinker hears about it only when the shortfall changes what they asked for.

(SOTA 2026-10-23) Dedup key: the receipt identifier as written, or a fingerprint of (intent, criterion id) with the receipts recorded on the record, so a second verdict on the same unmet criterion extends one record rather than minting another?
(SOTA 2026-10-23) Is the fingerprint a second use of findingkey.Derive or a sibling with the same versioning convention, so the repository does not hold two unrelated key schemes?

Audit Notes

Empty. Populated by intent-auditor when intent moves to shipped/.

Frontmatter

id	itd-165
type	intent
lifecycle	drafts
severity	minor

.abcd/development/intents/drafts/itd-165-an-intent-that-fails-its-own-fidelity.md
open on GitHub ↗ · commit history ↗

Referenced by1

iss-2610262034042710draft itd-165 promises that a failed fidelity verdict becomes visible work; the intent surface's audit ingest already files an issue for every failed or undecided checkrelated

mentions9

adr-2609151528057260Three roles, who each artefact addresses, and when the loop stops
dcn-26091500000000092026-09-15 — The roles and loopback design workstream lands on main, executing the 2026-09-01 ruling that the branch waits for the mint verb and takes its ids at the merge. `abcd decide` now exists, so the two decisions the branch numbered 0055 and 0056 are re-minted as adr-2609151528057260 (three roles, who each artefact addresses, and when the loop stops) and adr-2609151528057131 (abcd owns the product thinker's surface), content, status and date unchanged; every citation that meant the roles decisions is re-pointed (rfc-3, the phase-8 page, the roles page, the out-of-scope list, three intent drafts, and iss-168, whose 29 August extension cited them by the colliding numbers), and main's own 0055 and 0056 keep their ids. The branch's twelve hand-numbered intent drafts (itd-165 to itd-176) collide with nothing and keep their ids, as adr-45's grandfathering allows. Occasion: itd-200 shipped today refining the two roles decisions, so their citations on main pointed at the wrong records until this landed.
dcn-26093000000000272026-09-30 — An after-merge fidelity audit that fails or comes back undecided leaves the intent shipped and flagged, and the ingest captures one issue carrying the owed check (ruling DQ1c of the product thinker, 2026-09-30, relayed by the orchestrator of autonomous run A; applied by lane dq1cFlag). DQ1c, verbatim: "(a) STAYS SHIPPED, FLAGGED: the intent stays in shipped/, its changelog entry stands, and a 'check still owed' flag names the unmet/undecided criteria until it is fixed and re-checked." The product thinker's note, verbatim: "can it auto-capture an issue with the remaining check? Either fix it or check again etc.?" It defines what "reopen" means for a shipped intent under DQ1a ("an UNDECIDED audit REOPENS the work") and DQ1b ("until the loop is ready it stays after the merge (reopen on undecided/fail)"): nothing un-ships. As built: a verdict judging any criterion NOT_MET or INCONCLUSIVE writes an audit-owed flag in its Audit Notes block naming each such criterion, the receipt, the remedy ("fix, then re-run the audit" when a criterion failed, "re-run the audit" when every owed one is undecided) and the issue carrying it; that issue is captured through capture.Capture, the one filer, as a major bug for a failure and a minor inconsistency for an undecided verdict (both in the drain's fixable set, so the drain's field rules decide as for any issue; the remedy is real, so H12's automatic-filer value does not apply), related to the intent, with the filing-time match, and a later failed or undecided audit of the same receipt links to it while it is open. A re-emit of a flagged receipt rewrites its request (`check_owed`); a re-run judging no criterion NOT_MET or INCONCLUSIVE replaces the block without the flag, leaves a dated clearance line below it, and resolves the issue with impact fix. This supersedes itd-165's draft reading that an inconclusive verdict creates no record: DQ1c is the later ruling and names the undecided case.
iss-2608290820473197An INCONCLUSIVE fidelity verdict is terminal, so an audit that could not decide anything is indistinguishable from one that passed. The ingest does not branch on the verdict value: it rolls the per-criterion verdicts into counts and replaces the parked OWED marker with INGESTED whatever they say, so a verdict of all-INCONCLUSIVE closes the receipt exactly as a verdict of all-MET does. The re-emit verb then refuses to reopen it, reporting already_ingested and leaving the Audit Notes untouched, which is correct for a decided audit and wrong for an undecided one. The consequence is that there is no way to ensure the re-run that an INCONCLUSIVE calls for. The only lever that produces a fresh receipt is editing the acceptance-criteria section, because the receipt digest is taken over that section alone, which conflates two unrelated acts: clarifying a promise, and retrying an audit that was merely under-fed. This is a loud-staging violation in the precise sense the principle names, since a stage that degraded presents as a completed one. The narrow fix is for the ingest to branch: an INCONCLUSIVE leaves the receipt OWED, or moves it to a distinct re-run state, so the outstanding work stays visible without minting a ledger issue for what is an input fault rather than a product defect.
iss-2608290822140563The fidelity audit runs after the merge, so its verdict arrives when the cheap remedies are already gone, and the code refuses any other ordering: the ingest rejects an intent that is not in the shipped bucket, and the emit fires from the ship move itself, so an intent cannot be audited against the candidate diff on a branch. The stated reason is sound as far as it goes, that a report-only review must never un-ship what has already shipped, but it answers a question that only arises because the audit was placed after the merge in the first place. Audited before the merge, a failing criterion has three cheap answers: fix the branch, revise the promise before making it, or decline to merge. Audited after, it has none, because there is no un-ship path and the code is on the trunk. The counter-argument is real and should not be waved away: a branch is not the tree that lands, since the merge queue lands merge commits and a semantic conflict with a concurrently merging change can alter the delivered reality after the verdict was formed, so the post-merge audit judges what is actually true while a pre-merge one judges a candidate. The shape that gets both is to gate on the pre-merge verdict and bind it to a content hash of the tree it judged, then check deterministically after the merge that the landed content still matches, reopening the receipt only on a mismatch, which costs one hash comparison rather than a second audit and reuses the content-addressing the transcript store already relies on. Whatever the ordering, the model's verdict must stay a proposal and a human acknowledgement must remain the gate, because a non-deterministic verdict that can block a merge on its own is a trust step this repository has not taken and would train people to route around the gate.
iss-2610241549164432Draft itd-165 still says an inconclusive verdict deliberately creates no record and that no audit verdicts exist yet (.abcd/development/intents/drafts/itd-165-an-intent-that-fails-its-own-fidelity.md:24, :26), while ruling DQ1c superseded the first reading (dcn-2609300000000027), commit b68b3d402 built an issue filed for every failed or undecided after-merge audit, and 119 shipped intents now carry acceptance rollups. The draft reads as the plan for behaviour that already ships differently.
itd-1Every Intent Has Acceptance Criteria; Every Audit Verifies Them
itd-50The Audit Loop Drives An Intent To Acceptance — Or Calls For A Replan
itd-170What the product thinker reports after using the product finds its way back to the promise that predicted it