ADRs for AI asks every agent decision for a falsifier. Make it one you can run

ADRs for AI launched on Hacker News on October 25 with a template, a VS Code extension, an MCP server and a plugin submitted to Anthropic's marketplace. Its core idea is a question format for agents, ORRCF: Options, Recommendation, Rationale, Confidence, Falsifier. Our view: the falsifier is the most useful field in it, and it only pays off when the falsifier is something a machine can check. In the project's own public example, three of ten are.

What ADRs for AI does

Architecture decision records are old. Michael Nygard proposed them in 2011 as short documents written after a decision. The author, Jérémie Lumbroso, draws the difference in the thread: "Nygard's records are written by humans after a decision." Here the agent writes the record during the work and raises open questions, and a human approves or overrides each one.

Every question carries the five ORRCF fields. The site's showcase example ends with this:

"Falsifier: If real attribution cases require additional independent times, such as product-availability time distinct from announced and effective time, the temporal model must expand rather than overload either axis."

The author explained the human's role in the thread: "My job as the human is to ensure that the record doesn't contain bullshit."

The objection that matters

The strongest pushback came from varyherb, who had tried something similar "in a professional codebase with dozens of contributors". Their experience: the agent "will cite various flawed or outdated assumptions," and "it's the same old problem of doc rot, but now the docs are blindly obeyed."

That is a verification problem. A human reader treats an old design note as history. An agent reads it as an instruction. So the question for any decision record an agent will obey is: how does anyone find out that it stopped being true?

The falsifier is the answer the format already has. It names the condition under which the decision is wrong. If that condition can be checked automatically, the record can expire on its own, before an agent obeys a stale rule.

What the falsifiers actually say

We read every decision record in frontier-model-observatory, the public project the site quotes. It has 10 ORRCF questions, each with a falsifier. We sorted them by what it would take to check them. This is one reader's classification.

The judgement falsifiers are not bad falsifiers. Licensing and ethics belong to people. This project is a data archive, so many of its decisions are about scope and policy, and a codebase full of library choices and timeouts would likely score higher.

But the three checkable ones show the pattern worth copying. A falsifier about whether "the complete core-provider archive remains small enough that ordinary Git clones are operationally trivial" becomes a CI job that measures clone size against a stated limit. One about whether "the available token UI cannot grant workflow write without materially broader repository access" is answered by trying it once and recording the result. Each turns a sentence into a check that fails.

The middle group is half way there. Whether "calibration shows that the same fact must be edited in multiple canonical streams" is something a script can count, but a person still has to decide when the count means the design is wrong.

What to take from it

If you let agents write decision records, and more teams will, keep the falsifier field and push it towards something executable:

1. Ask for a check, not a sentence. "If p95 latency on /search exceeds 300 ms" can run in CI. "If performance becomes a concern" cannot.
2. Run the checkable falsifiers on a schedule. When one fires, mark the record as superseded so the agent stops obeying it.
3. Leave the judgement falsifiers with a named person. Put an owner on them, not a script.

Three in ten is a reasonable start for a format that asks the agent to name what would prove it wrong. The other seven are the ones that will rot first.