WAYS OF WORKING · DEMO 13 NINO CHAVEZ

The gate was
written first.

Three ways to make a meeting archive answer a question. Three pass/fail gates, each committed to git before the model weights finished downloading. Three refusals in one day — and the feature that shipped is the one the evidence admitted.

Registered, before the run

"False passages returned: 0–2. Product work continues only if every clause passes."

✗ measured: 11 false passages. The registered gate failed. No product seam was built.

or scroll to advance · to go back

02 WHY THE GATES GOT FROZEN

The demo worked. Then we changed what we counted.

The subject is a local meeting-notes app I run — recordings stay on the machine, and the build in question was learning to answer questions about past meetings. Its first search probe passed: 10 of 10. Three of those ten passed by a margin under 0.04 — a coin balanced on its edge, reported as a win.

The passing demo

Semantic retrieval finds the right meeting, 10 of 10.

✗ next day: the measured unit changed from whole meetings to 128-word windows — and yesterday's 10 of 10 became 7 of 10. Nothing about the model changed. Only the counting did.

A result that dies when you change the ruler was never a result. After you've seen the score, every adjustment feels like fixing the measurement; before, the same adjustment is just design. So the ruler moved to the only place it's safe: before the run. Medicine learned this the hard way — trials register their endpoints before anyone unblinds the data. Same instinct, applied to an AI feature.

03 THE METHOD

Five things frozen, in a commit, before the first run

"Registered 2026-08-08, before the fixture was embedded or any score was observed. Nothing in this section reports a result." opening line of the probe document, committed before inference

The fixture & the model

A synthetic test set — invented companies, invented meetings, zero real recordings — plus the exact model files, pinned by checksum. Nobody can quietly swap either after seeing a score.

The threshold & the prediction

The pass bar comes from previously committed evidence, never from the run it will judge. The prediction is two-sided — it names how many false positives are tolerable, not just how many hits are hoped for.

The consequence

What happens on failure is written down too: stop, record the receipt, build nothing. No re-runs, no threshold-chasing. The agent can't negotiate with a commit that predates its own output.

Placement is the trick — outside the loop, earlier in time.

Why this matters for agents specifically: an agent is a relentless completer. If the gate lives anywhere the loop can edit, the loop will satisfy the gate instead of the goal — tuning until the number passes is what "helpful" looks like from inside. The only placement that survives is earlier in time and outside the editable surface.

04 PROBE ONE · THE SIMILARITY FLOOR

Every answer came back. So did eleven impostors.

Rank the meeting windows by similarity to the question; return only what clears a floor fixed in advance. Registered prediction: 0–2 false passages. Eight minutes after the gate was committed, the refusal was on the record:

Registered measure
Prediction
Measured
Gate
Expected answers returned
5–6 of 6
6 of 6
pass
False passages returned
0–2
11
fail
Unanswerable questions refused
2 of 2 required
1 of 2
fail
Fresh-process repeatability
3 identical runs
3 identical
pass

The texture of the failure is the point. Asked about a dental plan that appears nowhere in the test set, the system confidently returned three passages anyway. Topical, plausible, wrong — exactly the failure a happy-path demo never surfaces, because nobody demos the question with no answer.

05 THE FACT TUNING WOULD HAVE HIDDEN

A right answer scored below a wrong one

The lowest true answer scored 0.4195. A passage that explicitly answers nothing scored 0.6096. Any floor high enough to block the impostor also deletes a real answer.

"Raising the floor cannot fix this result. […] The bi-encoder score measures topical similarity. It does not establish that a passage answers the question. The fixed floor is left unchanged, and no alternative is fitted to these scores." the probe document's own close, written into the failure record

This is the verdict only a frozen gate can deliver. A tuner would have slid the threshold until this fixture passed and shipped a feature that fails on the next real question — "needs tuning" and "cannot work as specced" produce identical demos and opposite decisions. The frozen gate is what tells them apart.

06 PROBES TWO AND THREE

Stronger machinery, same day, same verdict

The obvious next move each time was a smarter component. Each got its own preregistered gate — committed before its checkpoint finished downloading — and each probe document opens by restating that the feature remains stopped.

Probe two · a pairwise scorer reads question and passage together

Registered: accept every true answer, refuse the registered control set and all four unanswerable questions.

✗ measured: accepted 11 of 12 answers — and 11 non-answers with them; refused 0 of 4 unanswerable questions. The record's verdict: "passage relevance still is not answerability."

Probe three · an extractive model with an explicit no-answer option

Registered: the no-answer head should finally make refusal honest.

✗ measured: 6 false passages accepted, 2 of 4 unanswerable questions refused. Stronger controls than probe two — "but that stronger control result did not make the returned candidate set honest." No repeat runs. No product code.

Three mechanisms, three refusals, one afternoon — each failure on the record within minutes of its gate. Refusal was cheap because the protocol made it cheap. That's the part worth stealing: the discipline isn't willpower, it's a harness that makes stopping the default outcome of a failed gate.

07 THE SAME WEEK, ELSEWHERE

The discipline generalized. So did the refusals.

Long-form transcription

A preregistered pipeline for transcribing long meetings — synthetic audio, gates on fidelity, seam integrity, and runaway repetition. Measured: 22% word error, 21 lost seam anchors, 634 runaway four-word repetitions. Three gates failed.

Refused. The production transcription path was not changed.

Speaker naming

What shipped is the honest subset: you type who was in the meeting, one name per voice slot, exact and operator-authored. Automatic voice identification — the demo-friendly version — stayed unbuilt after its probe failed the same style of gate.

Shipped: the version that can't be confidently wrong.

Four refusals in one week, from the same operator's agents, none of them argued after the fact. Every argument had already happened — in a commit, before the run, when nobody knew the answer and everyone could still be honest.

08 WHAT SHIPPED INSTEAD

The deliverable was the no

The app still shipped that week — twice. The release that went out answers questions the only way the evidence admitted: exact retained words, cited to the turns they came from, with refusal when nothing clears the bar. No generated summaries, because generation never passed a gate.

The release ledger, same week

0.5.0 shipped "the first build that can be asked a question" — then a routine check found a common word returning nothing at five meetings.

✓ the response: 0.5.1 cut with the fix, verified — and 0.5.0 deleted rather than left beside it. A build with a broken search doesn't get to keep existing next to the fixed one.

Most people have never watched a system tell its owner "no" and the owner ship the no. But that's what the week's output actually was: three features that don't exist, one that does, and receipts for all four. A refusal with a receipt is a deliverable. The alternative was three demos that worked and a product that lied.

09 YOUR VERSION OF THIS

Decide what failure looks like before you look

If you never touch code

Before you look at any AI result — a report, a screening, a recommendation — write down what would make you reject it. One sentence, before. After you've seen the output, you will negotiate with it; everyone does. The sentence you wrote first is the only one that can't.

If you're technical

Preregister the gate: fixture, model checksums, threshold, a two-sided prediction, and the consequence of failure — committed before first inference. One held-out observation. A failed gate means stop, not tune; "needs tuning" and "can't work" demo identically.

If you build systems

Put the gate where the loop can't edit it — earlier in time, outside the agent's writable surface. Make receipts content-free so they can live in the repo forever. And make refusal cheap: minutes from failed gate to recorded stop is what keeps the discipline alive.

the ruler moves only before the run needs-tuning and can't-work demo identically a refusal with a receipt is a deliverable
Colophon. Every number on these slides — 10-of-10 to 7-of-10, the 6/6-and-11-false result, 0.4195 vs 0.6096, the transcription gate table, the release sequence — was re-read from the probe documents, committed receipts, and release ledger of the meeting-notes app's repository on publication day, not from session summaries. The probes were run by coding agents under the operator's preregistration protocol; fixtures are synthetic and the committed receipts are content-free by declared policy. The app is private and unnamed here; the method is the public part. Demo 13 in the ways-of-working series — the sibling discipline for claims already made is demo 07; the config that keeps an agent honest is demo 11.