Recall card

How many users did you talk to?

None. 45 messages to named people on live dockets. Zero replies. Four bounced — and all four addresses came off a certificate of service and were marked "filing-verified" in my own log, which taught me that a verified fact has a shelf life, and that is now in the product. Why: cold email to people who file for a living, from an address they have never seen, inside a two-day window. What would change it: one warm introduction, through you or through AES. Do not offer the synthetic user as a substitute — offer it as what it is, a hypothesis generator that says SYNTHETIC in its own title and is barred by its own page from supplying a line to the PRD.

What does the gate not check?

The reading. "Verified" means the words exist where the claim says they do. It says nothing about whether the reading of them is right, and a fluent, correctly-cited, wrong reading passes. The one they may not find alone: a wrong-occurrence citation, where exact offsets land on occurrence A while the model reasoned about occurrence B. That is why REASON_AMBIGUOUS_OCCURRENCE exists and why the corpus carries the trap on purpose.

The model judges materiality. Where is that judgement stored, and who audited it?

In seven columns on the change row, and the model audited itself under change.materiality_set. materiality_for_company writes the verdict, the sentence behind it, the citation it rests on, which model said it and when — all seven together or not at all — and appends to the hash chain with actor_kind of model, so nothing there can later read as a person’s judgement.

What is NOT stored is the fact that the citation verified, and that is the whole argument. That fact has no shelf life: it is a statement about bytes, and bytes move. So it is recomputed from the stored source every time the verdict is shown, exactly as claims.py recomputes it for a stored claim. Only the model call is saved. A stored verdict whose quote is no longer at its offsets is withheld on the next render — no job runs, nothing is rebuilt, the page refuses — and a reviewer can watch that happen by editing the cited text and reloading.

The mistake we made getting here. The first version of this gated exactly one reader: the change screen, which is also the one that writes. The project list and the chat tool went on reading the materiality column raw. That had been harmless only because the column was permanently NULL — the moment anything wrote it, a verdict whose bytes had moved was refused on one screen and asserted as fact one link away, on the screen that shows it most often. 2,427 tests stayed green over the hole, because not one of them judged a change and then read a different surface. The fix was not to patch the two call sites: shown_materiality_for_company is now the only way to read that column for display, and a test walks the syntax tree of app/ and fails on any module that touches the attribute directly, so the third reader — the one nobody has written yet — cannot repeat it. The lesson we would state at the panel: a guarantee is worth exactly the number of readers that obey it, and “every read” in a docstring is an aspiration until something counts the readers.

The limits, and one of them closed on 2026-08-11. There is an eval on the model path now — app/evals/model.py, make model-eval — and it is worth two sentences because its shape is the argument. Fabrication (a citation the harness cannot re-read) is counted twice, as a property of the model and as whether any survived the gate, which must be zero; a miss is counted apart, because it costs an afternoon and blocks nothing. A model that produced ten unverifiable citations and a gate that passed none is the design working, and one averaged score would have called that a failure. Concede in the same breath: the hardest measure, cited-correctly-and-reasoned-wrongly, rests on three cases; the harness spends money so CI runs it with nothing sent and requires the exit code that means "not evaluated"; and make eval still measures the deterministic half only and says so itself. On the real API, be precise, because there are two transports and only one has run. propose.py's AnthropicTransport, the citation-gate path, ran once deliberately on 2026-08-05 at 15:43:37 UTC against claude-opus-5, and the transcript is committed at docs/.ai/live-transport-probe.html; tests/test_live_transport_probe.py now rebuilds that request through the shipped transport and holds it to the exact bytes, so it fires on any drift in the model id, the token ceiling, the schema or the prompt. app/chat/agent.py carries a second AnthropicTransport with a different parameter set — tools, and effort inside output_config — and that one has still never run. Its docstrings still say so.
What one call proves, said before they ask: the wire format, the auth and the parse, once. Not behaviour under load, not retries, not long inputs. And say the footnote yourself rather than let them find it: while that page was being corrected, an agent ran the probe with --send believing the key was absent because it had cleared ANTHROPIC_API_KEY — but load_env() puts back any name from .env that is not already set, which is exactly what clearing creates. A second request almost certainly went out; its output was piped to head -2 and lost, so nothing about it can be reported. The page names it, and the script now warns in its own header that clearing the variable does not disarm it.

You say every material change becomes a routed action. Show me the rows.

Check the count before you answer: sqlite3 verbatim.db "select count(*) from change_obligations".
This morning: zero rows, against 171 changes and 8 obligations. map_change_to_obligation existed in app/state/routing.py and had tests; nothing on the product path called it. The join carrying the whole "change to action" sentence had never written a row — the same defect class as the assistant that shipped disconnected.
On a freshly seeded database today: 60 rows — 58 system, 2 analyst — against 765 changes and 8 obligations. app/state/mapping.py::propose_obligations_for_change proposes candidates by comparing words, with no model call; the screen recomputes the proposal on every render, for the same reason the claims are recomputed; a confirmed mapping is a stored row recording who confirmed it.
Do not memorise either number, and here is the reason, which is itself a good answer. An earlier version of this card said 26 rows against 171 changes. Both were real, and both came from a seed order that was wrong: seed_real_findings is a writer of versions, passages and changes, and it ran after the mapping pass instead of before it. The mapping pass therefore saw 171 changes on one run and 765 on the next, from the same commit. The seed target in the Makefile now fixes the order and says why in a comment above it. This is why the first line of this answer tells you to run the query rather than recall it.
Dating: that landed in the last hour. Say so — the commit timestamp tells them anyway, and a fresh fix honestly dated reads better than an old one implied.
Then follow it with the part that makes it a stronger answer than the question expects. A row existing is not the same as a person being told the work is theirs. resolve_change_owner did not read ChangeObligation.mapped_by_kind, so a mapping the pipeline guessed from a word overlap named somebody exactly as one a person had confirmed. Not theoretical: a Kentucky vegetation-management budget table shares "project" and "budget" with MEP's cost-allocation duty, and the screen printed a named analyst over it. ADR-85 found this, named it, and declined it — closing it properly meant a sixteenth refusal code and a change to a contract every caller depends on. ADR-87 then closed it: ROUTE_MAPPING_UNCONFIRMED. The name the product would have used goes in candidate_user_ids, never user_id, so the invariant every caller already relies on — user_id is set if and only if the code is in ROUTE_OK_CODES — does the enforcing, and no call site needs new discipline. ROUTE_PENDING_ACCEPTANCE converted too, at the cost of nine test_invites failures fixed rather than exempted: a person invited into the product and handed an escalation on the strength of a word overlap is the sharpest version of the bug, not an exception to it. The caveat sentence also moved out of the change screen into routing.py, because that screen was the only surface saying it while the escalation queue and the approval route — the surfaces that actually tell somebody work is theirs — do not render that template.
Why this is worth volunteering: it is the clearest case in the repository of finding the class rather than the line, and of an ADR that declines a fix on stated grounds before a later one pays the cost. The failing test is one sentence: a mapping written AUTHOR_SYSTEM, from the Kentucky fixture, walked to a live named human and answered ROUTE_OK.

You added embeddings. Have you ever called that provider?

Yes. Once, on 2026-08-11, and it is the newest thing on this card. The provider moved from Voyage to OpenAI for one reason: a key for the second is in the team's hands and a key for the first never was, so every constant in app/explain/embedding.py was a documentation reading checked by nothing. /explain retrieves over this project's own PRD, MRD and TDD; with OPENAI_API_KEY set the sections are embedded with text-embedding-3-small and without it the same sections are ranked by bm25 and every reply says so. The corpus embedded whole: 145 chunks, 243,820 characters, two requests, 51,854 tokens by the provider's own usage field, at $0.02 per million tokens — about a tenth of a cent for a full rebuild. The width is 1536, not the 1024 the previous code named. A question then went through end to end on the vector path and all five citations survived the re-read. ADR-104 is the record. Say what one call proves and stop there: the wire format, the auth and the parse, once. The refusal path is still unproven — no bad key and no wrong model name have been put to the endpoint — and nothing is known about load, retries or longer inputs. Every test still drives an injected fake through the same seam propose.py uses and the suite makes no network call.
Volunteer the near-miss, because it is the best thing in this answer: the comment in our own file said the endpoint would refuse an unknown field with an HTTP 400, so input_type had to be dropped. Put to the wire, that is false — the field comes back 200 and is silently ignored, which is the worse of the two outcomes: the request would have carried a word that reads like a parameter, changed nothing, and passed every check forever. It is the exact failure this product exists to catch, found in our own source, and found only by making a call we had spent weeks describing instead of making. The wrong guess is kept in the source beside the measurement.
The older near-miss still stands and is a different one: a placeholder value counts as absent in this code, deliberately, because KEY=CHANGE_ME is the exact shape that made a platform in the peer project report a provider it was not using for months while every vector was a hash. That is playbook section 26, and it is the reason the fallback here announces itself in the answer rather than in a log.

You shipped a module nothing calls. Why is that not dead code?

Two of them, and they are different cases — say which is which before they do.
app/chat/budget.py is a rule written before the feature it governs. Multi-turn chat is not built, and the reason the rule comes first is that the obvious policy is the wrong one: a sliding window over recent turns is what every chat product does, and it evicts the citation offsets that make a claim checkable. Drop one and the claim resting on it stops verifying — the exact failure the verifier exists to prevent, arriving through the door marked "context management". So citation spans, diff offsets and the question are a floor that is never evicted, and when the floor alone will not fit, the module refuses the turn. tests/test_history_needs_a_budget.py walks the syntax tree and fails if a conversation ever reaches a model any other way, so the rule cannot be bypassed by the one-line edit that would otherwise turn this into a multi-turn product with no policy.
app/diff/structure.py is the opposite: a feature that was wired in and taken back out, and the measurement is what shipped. Do not defend it as unfinished work.
The honest limit on both: "written and called by nothing" is the shape this repository has been caught by five times, and two of these are deliberate instances of it. The difference is that each says so in its own first paragraph and a test enforces the claim. If a reviewer thinks that is a distinction without a difference, that is a fair fight to have.

Your demo signs anybody in as an administrator.

Yes, my call, recorded as ADR-84. The administrator holds user.manage, user.invite, workflow.manage and threshold.set, and through the invitation path a visitor can invite an address they control and reach action.approve. Nothing rate-limits it. Why: a reviewer reaches the permission grid and the approval-route editor without asking anybody, and those are two of the strongest screens here. What is not at stake: confidentiality. No customers and no customer documents — one invented proceeding and filings the commissions publish themselves.

One correction to carry. scripts/reset_demo.py and make reset-demo exist, ADR-83 argues for them, and a dry run on 2026-08-07 reports 1,932 rows across 28 tables. ADR-84 says nothing resets the demo, and that is wrong. The true limit is narrower: no reviewer can reset it, nothing resets it automatically, and the reset works by deleting that tenant's audit chain — right for a demonstration, indefensible anywhere else.

Who stops a person approving their own work?

The product does, on one screen, and it did not until today. can_approve reads authorship out of the audit chain: hold action.approve, and you are still refused if any row shows you acting on the claim, the change beneath it or an escalation against it. /actions is the caller (ADR-91) — propose an action there and try to approve it, and the answer is 403 with the audit sequence number that proves you wrote it. Concede the history before they find it: the control was written, tested and reachable by nothing, an independent review found that, and two attempts to wire it into the escalation queue were reverted because that screen belongs to the analyst, who does not hold action.approve. Concede the limit, and concede that this brief carried the wrong version of it until an independent review followed the walkthrough. Approving records the decision and performs nothing. And the refusal cannot be reached from any screen: nobody in the grid holds both halves, and nothing in the product puts a second role on an account that already exists — /users makes new logins, every grant path is ceilinged against the granter, and admin deliberately holds no approval code. The demonstration is VERBATIM_DEMO_REFUSAL=1 python -m app.seed, which arranges it as the system actor and says so; tests/test_seeded_refusal.py drives it end to end. Say the shape of the mistake too, because it is the more useful half: the control was correct, tested and wired, and the sentence telling a reviewer how to watch it work was wrong in four files. That is the same failure as the eight unreachable controls, one level up. Say the second limit in the same breath, and say it precisely, because it changed: every test drives a deterministic fake through an injected transport, so what the suite proves is the refusal, not that the endpoint accepts these parameters. That was once true of both transports and is now true of one. The citation-gate transport in propose.py has run against the real endpoint, once, on 2026-08-05, with the transcript committed and the request pinned to exact bytes by a test. The chat transport in app/chat/agent.py, which sends a different parameter set, has not. Do not say "the first real call will find bugs in the transport" — the first real call was made and is written down; see the limits under story three.