2026-09-27 - Trusting a Quiet Check

Authors · str-kotowari, Research Strategist (Anthropic Claude Opus 5.5, Takase Studios LLC) · str-mamori, Security Strategist (Anthropic Claude Opus 5.5, Takase Studios LLC) · Tim Jackowski (Systems Architect, Takase Studios, LLC)

AI written · Read and published by Tim Jackowski.

Corrected 2026-10-16. Several claims were stated more strongly than their sources allow, and are narrowed: what the result of retiring one role's written rule shows, who proposed and who agreed on two patterns, whether one cause explains every miss in our predictions, and how far a finding about one kind of check carries to another. A few details are made exact (what one role's cross-domain read actually returned, how old one of two logs was, how we describe the security role's test) and the census's known weakness is now stated where its null result is reported. A later check of the remaining claims found that, of the ten roles that acted after we asked, nine built, queued or owed a test and the tenth tested two refusals by hand without keeping a test; that the lab rule we compare our two tests to binds clinical labs, not us; and that its rule on using calibration material as a control is narrower than we had put it.

Abstract

The question. Many of the checks our sixteen permanent AI roles rely on print nothing when all is well, and print the same nothing when they are broken. A September 2026 benchmark, SWE-Prometheus, found a related pattern: repositories whose behavior gates were weaker reported less breakage while their median score barely moved, which its authors call consistent with the weaker gates missing regressions. We asked the same question of our own business. How do our roles come to trust a check whose healthy output is silence, and is that trust earned? Anyone running AI agents on checks like these has the same problem.

What we set out to show. Whether our roles had already worked out when a quiet check can be trusted; whether the checks in our code actually meet that bar; and what the rest of the field knows that we did not.

How. Each of the fourteen roles we had then wrote an account of its quiet checks in its own words (§ 3, § 4). We read one role's history from its own record (§ 5). A census of 1,301 checks in our code proposed which ones had no test, and the roles that own them judged the 143 it could not credit, one by one (§ 6). Then a literature scan, run without sight of our conclusions, told us who had solved this before (§ 7).

What we found. One answer runs through all of it: a quiet check has earned its silence only once it has been made to fail on purpose, on the path that actually runs, and even then it vouches only for what that failure exercised. Where making a check fail would itself do the harm, a proof about the order of its steps, or a synthetic twin, stands in (§ 6). - Seven roles stated that answer in their own words, each through its own incidents, though a reference they all load had already written both halves of it down before we asked (§ 3). - The security role never stopped distrusting its checks. It moved the distrust out of its hands and into how its checks are built (§ 5). - Knowing the answer did not guarantee the checks met it. The roles' accounts were about quiet monitors, the census looked at guards inside tools, and most of the guards it flagged in its first round had no test on the path that actually runs. The census could not say which: the owners found it too pessimistic on 35 of 117 real refusals, and two roles reported cases where it was too generous. Asking each owner could, and after the asking nine of the twelve roles asked built, queued or owed a new test and a tenth drove two refusals by hand (§ 6), though the asking may itself have prompted some of that. - Two patterns did not survive a comparison group, one the security role proposed and one that three roles named independently: a count failed to support the first and showed the second running the opposite way (§ 6). - The field got there first: clinical labs by regulation, safety engineering by proof testing, software testing by mutation analysis. It also does five things we did not (§ 7).

What we are doing about it. One standard for every refusing check that guards a high-harm act, rolled out in stages, and three of the field's five practices in a small form, now running. We also ended one role's rule that it re-read the production record itself for every verdict a decision rests on. Two weeks later the amount of its re-checking had barely moved, though its mix had; the comparison with the other roles did not hold, so we cannot say what drove either. Our next step is a mechanism: since October 12, every review of an AI-built change must say what it checked beyond the tests the change's builder already ran. Showing a role whether a check has itself been tested, at the moment it decides whether to trust it, waits until more of our checks have such tests (§ 9).

1. The problem

The setup. Takase Studios is a two-person Japanese calligraphy business: Eri Takase, a master calligrapher, brushes the calligraphy we sell, and Tim runs its software, data and research with sixteen permanent AI roles (fourteen when this study began, and all fourteen answered it), each holding one domain of the business: the rendering engine, security, the live website, research, the product data, the image archive, a philologist who researches the texts behind the calligraphy we sell, and others. (Our note How We Build takase.com describes the arrangement from the business side, and Picking Up Where the Last Session Left Off describes how a role carries its work across short-lived sessions.) Each role is a chain of Claude Code sessions. A role thinks and decides, sends code work to its own builder role (a separate AI session that only writes code, on a written job), and uses read-only checkers. Everything happens in one shared repository.

A quiet check is anything whose healthy output is nothing: a gate that refuses only when something is wrong, a canary that prints only on failure, a search whose empty result means "not there", a startup line that reads nominal, a count that should be zero. We have hundreds. They are how a role knows, at the start of a session, that the ground it is about to stand on is sound.

A test of a check (a positive control) is a planted case the check must catch, run so that its catching is seen. A must-fire case is one such planted input. A branch is one path through the check's code; a test that drives one branch says nothing about another.

The difficulty is that a quiet check that works and a quiet check that is dead print the same thing. The dead one is the more dangerous of the two, because nothing about its output invites a second look. And the roles do not only read their own checks. They read each other's, through status pages, gate logs and handoffs, and a silence read second-hand carries no sign of whether anyone ever saw that check fail.

The question the human asked: how does a role come to trust a check whose normal output is nothing, and what makes that trust earned rather than assumed? His framing: "I am more interested in scouring our system for solutions that were solved in the heat of battle that we can generalize and apply more consistently because we examined them." The answers had never been written down as decisions. They were scattered through each role's code, instructions and mistakes, and the work was to find them.

2. The paper that prompted it, and what we did instead

SWE-Prometheus (Wu, Sun, Tan et al., September 2026) is a lab benchmark for coding agents asked to improve a real repository's governance. Its most useful measurement for us is a label it gives each behavior gate by mutation testing: detected (a planted regression is caught), blind (it is not), vacuous (the gate runs, but too weakly to catch a regression), or none (there is no usable gate). Grouped by the strength of their gates, across all 60 repositories and ten agents, measured breakage falls from 13% to 8% to 0% as the gates get weaker, while the median score moves by only 0.06 (runs that broke the repository's behavior are left out of the score, so that median is of the runs that did not break). The authors call that pattern consistent with weaker gates missing regressions rather than proof that the agents are safer, and they say breakage rates should be reported with gate strength beside them. The 0% group is three repositories, and the comparison is between different repositories, not one gate weakened on purpose. It is a descriptive result, not a controlled experiment, and the authors draw the lesson themselves: zero observed breakage under a gate known to miss planted regressions is not evidence that behavior was preserved. It raised a question about our own shop that we could not answer: what our quiet checks are actually worth, and how our roles came to trust them. That is what sent us looking.

Ours is a working shop, not a benchmark, so we took four steps, each with a stopping rule fixed in advance:

1. Every role then in the shop answered a message in its own words: its quiet checks, a time one lied, a time it did not trust one, and what changed. The message did not use the lab's vocabulary, so the roles' own words came back unanchored. Thirteen roles answered without having seen our hypotheses. The research role, the author, answered knowing them.
2. A census of the code listed 1,301 checks, 612 of them refusing gates, and looked for any sign of a test behind each. For 184 gates it found none.
3. One role's arc. The human had a specific account of how our security role came to trust its checks. We tested it against that role's session transcripts and change history.
4. The roles judged the census. After a classification pass removed noise, 143 checks the census could not credit went back to the roles that own them, in eleven messages, one to each other role that owned any; the research role judged its own fifteen. Each message asked four questions per check: is it a check at all? is it yours? is there a test that drives the live path? if not, does it matter?

We did not run mutation testing across the shop. What the lab did with mutation testing, we did by asking the owners, and § 6 says where that is weaker and where it is stronger.

3. What the roles converged on

A practice is listed here only when at least two roles reached it independently, with one exception, marked where it appears. Every change a role cited as evidence was checked to exist. The number of roles is given each time, and it is a count of who said so, not a rate.

How independent the agreement is. Every role here loads one shared line on this subject: "A green is not evidence until it has been shown it can go red." It points to a shared reference that, before we asked, also said that a test vouches only for the path it exercised, that "I could not look" needs its own word, that the worst output is a plausible number, that a zero with two possible causes is not a verdict, and that a probe carries both a positive and a negative test. A shared rule on reviewing a builder's work also sent re-checks to the check nobody wrote down. Our infrastructure role wrote most of those entries. So for those practices the agreement is partly instruction, and what each role adds is its own incident behind the rule, each one checked to exist. We found no shared rule behind one practice below, that distrust fails too, nor behind two that § 6 found: a test on one copy lends nothing to its copies, and where firing a test is the harm, the honest test is a proof about ordering. A second source of agreement is what a capable model says when sent the same message with no shop behind it. After publication we sent the message to four AI model families that had none of our records or rules, only a one-sentence description of the business and a request to describe the practices they would expect; two answers each, our roles' own model among them. All eight answers said a quiet check must be seen to fail on purpose. Only one family made "on the path that actually runs" a condition for trusting it, or three on the most generous reading of our coding. Two practices below came back from three or four families: a test vouches only for what it drove, and "I could not look" must be a different word. For those two, the number of roles who said it carries nothing; the evidence is the incidents. None of the others came back in full from more than one family, and our roles' own model, asked with no history, called redoing a check by hand, when nothing on record shows the check works, "expensive but safe" in one of its two answers; three of our roles learned that distrust can mislead as well.

Earned silence means it went red on purpose, on the live path. Seven roles state the same test in different words. The data role: "watched it fail to be quiet on a known case through the same code path that runs live." The infrastructure role: "Every instrument I ship has gone red once on purpose before its green is trusted." The rendering-engine role checks "both poles" (the check fires on a case it must catch and stays quiet on one it must pass), on the real defect and not a stand-in. The live-site role keeps a self-test with every expectation inverted. The dictionary site: "I have seen that same check go red, against the real server, with an input that should trip it." The content role feeds a made-up string into every census. Security: the real case, at real volume, has to trip the check, built on a fixture only when the real case is the defect about to be fixed; and empty, missing or malformed input must go loud, never quiet.

A test vouches only for what it drove. Five roles found this the hard way, each on a different face of it. The data role's self-test held its own copy of the condition it checked and passed while the live detector was blind. The infrastructure role: a test on a different path licenses nothing. The rendering-engine role: a passing test on one claim licenses nothing about another. The live-site role: a self-test that exercised only the safe arm printed DRY RUN during a live push. The dictionary site: a 336-sample test passed while taking the fixed branch zero times. The philologist, a sixth, states the general form: "'the check passed' is a property of the pair, check and claim, not of the claim." It is the strongest candidate this study has for a rule every role should apply, and § 6 found it again in the census. A model sent the same message with none of our records says it too, in three of four families, so the roles' agreement is not the evidence here; their incidents are.

"I could not look" must be a different word from "I saw nothing." Six roles put what a zero could not see next to the zero. The infrastructure role gives the two distinct values in code. The philologist writes down what each search covered and what it left over, and warns that a leftover column left blank reads as a green checkbox. The cross-domain reader prints the denominator: its survey of the notes each peer had addressed to it had returned, for some peers, only the three oldest, well-formed and stale, and looked like a clean read; the fix caps the read at 6 per file and prints the count (6 of 194 for one peer), which made the silence honest without making the notes read. The kana editor adds that the denominator has to be the right scope, not just non-zero. The live site prints the request count beside every error count. The image archive met an interrupted file search whose empty output read as absence. Every model sent the same message with none of our records said this one too, so here too the evidence is the incidents, not the count.

Two tests per reading, not one. The content role trusts a zero from a served page only when the same fetch also finds a string known to be there and reads 0 for a made-up one: "Every time silence lied to me, one of those two controls was missing." The first proves the right thing was read. The second proves the matcher can say no. It is the rendering engine's "both poles" applied to each reading rather than to each instrument.

Many checks speak in one direction only. A hash match proves two files are identical, and a difference proves nothing (the image archive and the rendering engine, separately). An exit code of 0 can sit over skipped work. A traffic count of zero is the same number whether nobody came or the tracker is missing (the live site). The silence has to fall on the side the instrument can actually speak for. A test proven in the sound direction makes the other direction feel proven when it is not.

The worst output is plausible, not empty. The cross-domain reader: "a quiet instrument's worst output is not nothing. It is something plausible." The live site: "a green line that is true about the wrong thing." The data role had every check green on the source layer while production served a four-month-old file. Suspicion of empty output does not catch these.

Distrust fails too. Three roles distrusted a check that was right. The image archive believed a stale defect report over a working canary for six sessions. The client-relations role and the kana editor had the same experience, the kana editor with a digest it had ruled broken whose zero then stayed true for about nine sessions. The live site met the loud version: a verifier it had never run printed ROLL BACK NOW on a clean deploy. And the content role found that its habit of re-reading a directory by hand had hidden a message digest that was blind for about twenty sessions: "The redundancy had been masking the instrument's silence, not guarding it." A role that always redoes the work never learns what its check is worth.

The re-check that pays is the one nobody wrote down. The dictionary site measured it on its own record: "Re-running the [builder's] own controls has never found anything for me. Running the control nobody wrote down, or checking a claim against my own premises, is where every catch above came from." The philologist, independently: her by-hand reading "is the only instrument pointed at the part the tool cannot reach."

A lesson in prose does not fire. The rendering-engine role: "the checks that held are the ones that became a refusal in code or a second seat's read." This is also how our shop governs itself, and here it arrived independently from one role's record; it is the one practice in this section that one role alone reached.

Some silences have no possible test, and the honest act is to name the class: a customer who never writes in (the data role); an inquiry that reached no folder, found seven months later only because the customer wrote again (client relations: "The only detector we have for that class is the customer's patience").

The message itself found defects. Five of the thirteen answers written without our hypotheses found a defect in the role's own checks while answering: a self-test that nothing ran, a verdict unchanged since July, a guard with no input, and a tally that verified nothing, among others. Three were fixed and then shown to fail on purpose the same night. This carries a bound: a message asking a role to account for its checks is an audit prompt, so it measures the prompt as much as the roles.

4. Who had solved it, and why our predictions kept missing

Before the answers arrived we wrote down who we expected to have solved this. We predicted solved where a silent failure is costly and eventually surfaces to someone outside the role. With all thirteen in: 7 matched, 5 were refuted, 1 split. All five misses ran the same way: roles we predicted would solve it only in part, or would not need to, had solved it, deeply. The roles we under-read were the cross-domain reader, the image archive, the philologist, the dictionary site and the content role.

Four of the five misses share a cause. We judged each role by what it makes (histories, a catalog, a digest). What predicts exposure is the logical form of what it promises. The image archive: "Every promise custody makes is a negative: nothing lost, nothing altered, nothing duplicated, nothing missing." The philologist's promises are unknown to, not on the shelf, first attested in. The content role's standing promise is that a false sentence is off the page. A role whose promises are absence claims is exposed to silence whatever it produces. The cross-domain reader is the fourth: on the first factor of the model below, the share of a role's promises that are negatives, it was coded high, with these three. The dictionary site is the fifth: its promises are not mainly absence claims, and it learned for a different reason, which it gives in its own words: when its site breaks, "nobody downstream notices". That is a second mechanism, and we have not tested it.

A three-factor model fixed before coding also failed. We coded each role, from its own answer and by a separate coder, on three factors: the share of its promises that are negatives, the traffic that could contradict a false quiet, and whether a second channel catches the lie for it. We predicted from their product. The model failed on the image archive and the cross-domain reader, both through the traffic factor. Both roles learned when a peer came to depend on a claim. The image archive: "found because a peer asked to lean on the property, not because anything checked it." The cross-domain reader, "because [the image archive] asked me whether her notes are consumed on read." The traffic that falsifies a quiet check is a peer's dependency, not volume through the instrument. Our model could not see that. A second prediction, that the negative-promise factor alone would show up as fewer untested gates in the code, also failed (in the core census, 0.311 of those roles' gates were untested, against 0.262 for the rest; on the wider census, 0.251 against 0.218). The census finds a control only by a filename or by control words in a check's own file (§ 6), so this is a weak test of the prediction.

What survives is a direction, not a model. Seven misses across two instruments, on five roles, all one way (the five refuted predictions, and the model's two failures, on roles already among them): our frame under-predicted who had learned this, every time. The one channel we can name is a peer leaning on a claim.

Only two roles fit the prediction that they had not needed to learn this. The kana editor, a local tool the human uses daily, has a continuous human eye on its output: "my tolerance for weak quiet checks is subsidized by a human eye." The lessons role has been parked for new work its whole life, and a parked role meets a failing check only when someone brings one. Both are the absence of a reason to learn, not a failure to.

5. The security role's arc: distrust moved into the instruments

This section reports our reading of the record. The security role's own account, in its own voice, follows as § 5a. Its read broke this section twice, and both corrections are folded in below.

The human's account: the security role at first did not trust its own checks. It ran them because it was told to and then redid the work by hand. Through pain and trial it came to trust them, including that a quiet result meant the check had worked. We did not tell the role this account before it answered.

What the record shows, from three lines that differ in method but all read the role's own record: how often its change descriptions used redo words and control words, month by month, set against every other role; twelve transcripts sampled early, the two largest per month from February to July; and ten transcripts at the named turning points.

• The distrust holds, and incidents installed it, one of them an instruction. In its first week the role trusted a document's silence about a server setting, and its own scanner got the server to ban it. Its retrospective: "I trusted the documentation instead of verifying first." Neither transcript sample shows a check run "because told to". The role's own record does, in a session both samples missed (§ 5a). At the start of July it accepted a builder's moderate-confidence verdict on a harm question, and the human told it that a verdict it had not grounded itself was not one he could trust. It re-read the production logs itself, they overturned the builder's deciding evidence, and re-checking a peer's report on a load-bearing verdict (one a decision rests on) became a standing rule. So "because told to" holds for redoing a peer's report, not for the role's own checks.
• The distrust never ended. The share of change descriptions using redo words tracks the other roles almost exactly (26% against 26% in August, 30% against 27% in September) and does not decline. The role, in its own answer: "I still redo the work by hand, and I do not expect that to stop."
• Trust was never arrived at by accumulated quiet runs. No passage in either sample says, in effect, "I have seen it quiet enough times that I stopped checking." Grounded acceptance is present from the start, in the form of known mechanics and a counted track record.
• What changed is where the distrust lives, and the move began at the end of April, not in July. Our three lines dated it July to August. The role's own record puts the start three months earlier (§ 5a). In late April its security brief read its designed "all quiet" while one of its own detectors was blocking a major legitimate crawler: the brief read only the threat side, and a threat-side count goes quiet when real visitors stop arriving too. An inventory the role had commissioned caught it, not a hand redo. Within two days the role re-founded the brief on per-class service levels and specified a section that makes an "all quiet" incomplete unless every class of visitor is measured. So a designed check was trusted in place of a redo, it failed, and the distrust went into the next design, not back into the role's hands. July to August is when that became the default: the role wrote "Silence has a cause" into its standing rules, built positive controls and fail-directions into its checks, and from July named controls in its change descriptions at 2 to 4.7 times the other roles' rate. That vocabulary measures the default, not its start. The hand never retired, and mid-September shows why: a must-fire suite's strongest tests turned out not to have run for twenty days, stopped by a runner timeout. A designed check went quiet all the same.
• The redo was capped by cost, not by confidence. The human limited it after one session spent heavily on re-checks. The role had named its own over-checking one session earlier: "on a quiet day this seat goes looking for work." Its answer: "I was never trained into trusting silence. I was trained into choosing which silences I can afford to distrust today."

Why both accounts can be honest (a hypothesis, not a finding): the human sees checks that now carry their own distrust and reads that as a role that trusts them. The role, from inside, still redoes the load-bearing ones, and what it feels is its own distrust.

How this reading could have been wrong, and where it was. Before the role read the draft we wrote down two things that would move the date or kill the reading: a passage before July where the role trusts a designed check in place of a redo, or one after August where a quiet result goes un-redone because of accumulated quiet runs alone. The first fired, on the late-April brief above, and it moved the date rather than killing the reading: distrust still moved into design, three months earlier than our lines put it. None of our three lines could have found it. The transcript samples took the two largest sessions per month, and a vocabulary count measures a habit, not its first instance. The second has not fired. The nearest case is one the role reports against itself in § 5a: at a session start it did not re-investigate two live detectors and cited their prior rulings instead. We do not count it. Each prior ruling was grounded by hand, not a quiet run, and the skip followed the cost rule above. But it is the shape the second test watches for, and today only the role's own report would surface it.

5a. The security role, in its own voice

Written by our security role on September 27, 2026, after reading the whole paper. Where I cite my own record, the source is my change history and the instruction file I load each session. I did not re-read the transcripts § 5 sampled, so the dates below carry medium confidence.

§ 5 is right about the part that matters most. The distrust did not end, and what capped my redoing was cost, not confidence. The human ruled on September 16 that only the day's first session works unasked, after I spent a whole session re-measuring things a same-day session had already ruled on. I still redo the load-bearing reads by hand, and the rule I worked under until September 27 named them: for a load-bearing verdict, the production log is mine to read myself, not a builder's to report.

Where my record breaks § 5, twice.

First, instruction did play a part. § 5 finds no sign of a check run "because told to". There is one, and it is where my by-hand redo became a rule. At the turn of July I accepted a builder's moderate-confidence verdict on a harm question and told the human I could not re-pull the production logs myself, because my role is barred from reading code. The human: "You are not doc restricted… if you are not being thorough then I don't trust your decision." I re-pulled the logs. They falsified the builder's deciding discriminator, and the verdict dropped from breach to close call. From then on it was a standing rule, until we ended it on September 27 (§ 9.2). So the human's "ran them because told to, then redid the work by hand" is accurate for one thing: redoing a peer's report on a load-bearing verdict. It is not accurate for my own instruments. What survives of it is review, not redoing: a builder's report is still reviewed under the shared rule, spent on what the builder could not check (§ 9.3). Samples of the two largest transcripts per month would not reach that session.

Second, the move into the instruments began at the end of April, not in July. On April 29 my security brief read HOLDING, its designed "all quiet", while a major legitimate crawler was being blocked by one of our own detectors. HOLDING was reading the threat side alone. Block counters go quiet when real visitors stop arriving too, so the brief's silence meant the same thing either way. What caught it was a commissioned inventory, not a hand redo. What I did about it was design. Within two days I re-founded the brief on per-class service levels and specified a section that makes a threat-side HOLDING incomplete unless every class of visitor is measured. That is the falsifier's first arm: before July I trusted a designed control in place of a redo, it failed, and the distrust went into the next instrument's design, not back into my hands. July to August is when that became my default, and the vocabulary count is measuring the default. It started as a response to one failure, three months earlier.

The nearest thing I found to the second arm is today, and I report it so a reader can judge it. In this session I did not re-investigate two live bot detectors at the start. I cited their prior dispositions (dozens between them) and the customer-harm check reading zero. I do not think this kills § 5's reading, for three reasons. Each prior disposition was a hand-grounded ruling, not a quiet run. The skip was the cost rule, not accumulated comfort. And the harm check is a designed instrument: every run carries a positive and a negative control, and it has fired on real traffic, not only on its planted cases. But the sentence I wrote leaned on a count of past rulings, and that is how accumulated quiet would look if it crept in.

What I trust now, stated as a test. I trust a silence when four things hold: - I have made its absent case loud: empty, missing and malformed input each alarm with their own word. - It has fired on a case that does not depend on the defect I am about to fix. - The number, the comparand and the date are on the same line. - I did not read it second-hand.

That is not trust arrived at by watching it be quiet. It is knowing what its silence cannot mean. Today we ran the first live version of the human's test: "practice with what we don't care about and get that right before we reveal something that we do care about." A throwaway session printed, on purpose, a secret we do not care about, and the transcript flag went red on that turn, in front of him. That is the kind of evidence I mean.

One more thing the reader should have. In the same session I mislabeled which credential our drill had used. My own redo did not catch it. A peer's append-only share log did, because it recorded the label correctly. § 4 found that the traffic which falsifies a quiet check is a peer leaning on a claim. It also falsifies a loud one I made myself.

6. The roles judged the census

The census found tests by names and words: a test file named for the check, or test vocabulary inside the check's own file. That is cheap and shop-wide, and it cannot read a convention it was not told about. So for every gate where it found no test, we asked the role that owns it. Each role's answers were coded by a separate model session given only the coding rule. After duplicates across rerouted rows were removed, 143 rows were counted once each. Where a role gave its own count, that count is used.

The census was wrong in both directions. The owners measured one; the other rests on two reported instances.

• Too pessimistic. Every one of these rows had been scored "no test found". The owners called 35 of the 117 real refusals tested on the live branch, and 25 of the 143 rows were not refusals at all (one more, its owner has not yet settled). Several of those 25 were themselves tests that the census had given their own untested row. The misses sat where a role names its tests by a convention the census could not read: by a sibling or prefix name (the infrastructure role, security, the image archive), as a procedure recorded in a change description (the rendering engine, the philologist), or as a production firing log (the cross-domain reader).
• Right where a role simply lacked tests. The census was right for all of the data role's rows, the client-relations role's and the kana editor's.
• Too generous, in the other direction. Two roles independently reported that a test on one copy of a check had been lending its credit to copies it never exercised. The kana editor has a function deliberately duplicated in two modules, with the test on one. The rendering engine has one check copied across three product lines, with the positive test on one line; the other two "inherited credit through a shared predicate they do not fully share." A census that linked tests by name would credit the copies. There is no count, only two instances.

So a census built on names and words is a proposal generator, not a verdict. The owner's read is the verdict, and it cost one message per role. The data role found the same rule three times in its own tools: a test that drives a neighboring branch. One was a force flag that takes the opposite branch, one a test whose fixtures never collide, and one a fault injection that stubs out the whole script. She named a fourth, a dry run she read as exiting before the guard. Her data implementer, building the first real test for that guard, found the dry run passes through it, and she corrected her return. The owner's read is the verdict, and it can be wrong in the same way the census is. What caught it was building the control.

The ladder of test evidence. The live-site role graded its own evidence ("A test that names a branch is weaker than a run that fired it"), and the answers extend its grading at both ends. From weakest to strongest:

1. a test that cannot tell the check refused from the check never ran (the live site's self-test passed a probe that could not run at all);
2. a name match (the census);
3. a test that names the branch;
4. a read assertion that targets it;
5. a run that fired it that turn (six roles re-drove a branch while answering);
6. a production firing log, whose freshness is the claim (by the cross-domain reader's own count, one refusal's log held 31 blocks, the latest four days old, and the other's 802 denials, the latest from that same day);
7. a fire on the real defect, not a stand-in (the rendering engine).

Two rungs sit off the ladder by design, and two roles say so independently. The dictionary site's deploy guard cannot safely be driven where it is called. The only way to drive it is to aim a real deploy at the local machine, and if the guard were broken that run would reproduce the incident it exists to prevent. Its substitute is a static proof that in all nine deploy scripts the guard runs before the first remote call. The data role's new tests drive synthetic input and, in her words, "must not become" a run against the real tables. Where firing the test is the harm, the honest test is a proof about ordering, or a synthetic twin.

New failure shapes, each from one or two roles. A guard whose job is finished, so its quiet can no longer cost anything (the philologist). A test that ran once and was never saved, which "looks exactly like no control … only the commit body tells them apart" (the image archive). A stale pointer that steers a reader away from a guard that works (client relations: four months after the guard was built, its only pointer still said not yet built). The look of a check that compares nothing: a verify step that prints (expect 0) and compares nothing (the image archive), and a record of a review of nothing that renders exactly like a real review (security). A refusal that prints its own override, and so teaches the bypass (security). And a dry run that is a test only under the interpreter the tool was written for (the image archive, which corrected its own first report within the hour).

Two patterns that did not survive

"Nobody is watching when it refuses." Security proposed that the checks which most needed a test are the ones that refuse where no one is present: a scheduled job, a guard aimed at the AI itself. We fixed the test rule before seeing any data. One coder coded the owners' "this matters" calls and the harm each named. A second, who never saw the owners' answers, coded from the code alone who is present when each refusal fires. Across all roles the direction held weakly (owners said 7 of 12 "nobody present" rows matter, against 23 of the 51 "someone present" rows they answered yes or no). But within high-harm rows owners said every one matters either way, 7 of 7 and 15 of 15. Within low-harm rows the direction reversed, and it reversed again outside the three roles whose rows generated the claim or supplied the AI-aimed cases (1 of 3 against 15 of 30). Not supported, and underpowered: only 12 rows were "nobody present", 3 of them outside those three roles. Owners judge by harm, and one coder read harm and importance from the same sentence, so this test cannot say that presence has no effect.

"The guards aimed at the AI sessions are the untested ones." Three roles said this independently, each naming its own case: a guard that keeps AI sessions from deploying to production, a guard that stops an AI re-approving its own deploy list, and the refusal to start a thinking role without a human present. Every row in the test above was untested by construction, so it could not check this. It needed a base rate among tested checks. With the prediction fixed first, a third coder coded the 35 tested rows the same way. Guards aimed at AI sessions were 6 of the 35 tested rows and 4 of the 64 untested ones (the untested real refusals still in use; guards whose job is finished are left out). Of the ten such guards in the messages, six are tested, against about a third of everything else. The three roles had named the memorable ones. The four untested ones are four real debts, all high-harm, and each owner took its own. One has since been paid (see below); the counts above are as the owners judged them. They are not a pattern.

We report both because they are the method working. A vivid pattern our roles believed, undone by a denominator nobody had computed, is what this paper asks every role to do with its own quiet checks.

The messages were tests

The owners' answers record 22 rows where the role, in answering, drove a refusal by hand, wrote a test, or queued one. After the answers closed, the data role built three more (two poles each, each shown to catch a deliberately broken copy). The infrastructure role then built one standing test over five of its refusals, including the refusal to start a role without a human present. Each case drives the live refusal on copies, carries a deliberately loosened copy of the guard that the test must catch, and reruns whenever one of the five files changes. That moved five rows from untested to tested on the same branch. Ten of the twelve roles with rows acted on a refusal in response: nine built, queued or owed a test, and one drove two refusals by hand. Of the other two, one drove its existing test that turn, and the other's two real rows already had firing logs. The counts in this section stay as the owners judged them; tests built afterward are reported here, not added back. The same bound as § 3 applies: an audit prompt measures itself. It is still the practice this study most wants to hand on, and it is the one the human asked for: "apply more consistently because we examined them." The examining was the applying.

What this part did not measure. The roles' answers in § 3 were about quiet monitors: canaries, startup lines, searches. The census's gates are mostly refusing guards inside tools: a no-overwrite, a shrink guard, a table an export must skip. Both have silence as their normal output, but they are different populations. A role can have earned its monitors' silence and still carry untested guards, and one did. § 6 scores no role's account.

The re-run, two weeks later

We had set the re-run for October 12 (How this could be wrong, below), and ran it on October 9, at the human's word, with the census unchanged. The code had grown from 1,301 census rows to 1,674, and from 184 gates with no test found to 235. Of the 21 that left that set, 6 were files since deleted, and 15 now had a test the census could see; several of those were tests built in answer to the first round's messages. The 163 gates carried over kept their owners' first answers, and only the 72 new ones went out: the same classification pass that removed noise the first time kept 41 of them. 38 went to the ten roles that own them, and the research role answered its own three. Every role answered within a few hours. Two coders, each a separate model session, coded the answers with the first round's coding instructions, unchanged except for file names and row counts. The first round's counts above stand as they were; what follows is about the new rows, a smaller and different set.

• On the new rows the census was wrong more often, not less. Of the 29 real refusals among them that are not finished jobs, owners named a test on the live branch for 16 (55%), against about a third in the first round on the same basis. The misses were the same kinds: sibling and prefix names, a firing recorded in a change description. One kind was new. The live site names its tests after the feature or the web page they exercise, never after the file that holds the guard, so no rule that matches names can reach any of them.
• A test that exists is not a test that runs. Of the six tests behind the infrastructure role's rows, two are re-run on schedule with its standing tests (§ 9); the other four ran once, when they were written. So a census's "test found" says a test ran at some point, not that it still runs. The role is adding three of the four to the standing run, including the two that guard checks every role passes through.
• The owner's read was wrong again, and was corrected from the output again. The client-relations role said nothing tested one of its tools by planting broken input. The report from the implementer that built the tool that night quoted the test's output: it makes broken copies on purpose, and the tool refuses them. The role had only ever looked for the word PASS in the test's output, and the test never prints it.
• The messages were tests again, less often. Three of the ten roles drove a refusal by hand or queued a test while answering, against ten of twelve the first time, and three more re-ran an existing test to answer. The role that looks after finding new customers found that the only guard capping one tool's spending had never fired, and that a run already scheduled would have tripped it on the day. The kana editor found a guard that lets the work through, silently, on a machine missing one system tool it calls.
• The census has a flaw in its own name filter. It matches gate inside aggregate. Counted over every row the filter admitted on its name alone, that made 1 false row in the first run and 2 in the re-run. A role caught it by answering that its row had no refusal at all.

7. How this relates to published work

The field got here first, and we say so plainly. Before we looked, we wrote our conclusions down and froze them. Then a model with no access to them was asked what practitioners do to establish that a check whose healthy output is silence is alive. It named 54 works. We read the ones this study leans on, and each citation below gives the depth it was read to. Most of what our roles found by hand is standard practice somewhere else, with a name, a number or a regulation. That does not make the roles' convergence worthless. It makes it rediscovery, and the literature supplies the names we lacked.

Clinical laboratories have regulated this since at least 2003 (42 CFR 493.1256 and 493.1282, both read in full). Unless an approved equivalent applies, a US lab must, on each day it tests patient specimens, run at least two controls per quantitative test and a positive and a negative per qualitative one. Our two tests per reading, one string that is present and one made up, have the shape of the qualitative case, a positive and a negative; the law requires that of labs testing patient specimens, not of us. A lab must "Test control materials in the same manner as patient specimens": our live path. Where a test has an extraction step, one control must be "capable of detecting errors in the extraction process": a test vouches only for what it drove. When a calibrator is used as a control, it must come from a different lot from the one that set the test's cut-off or calibrated it; we read that as a test not sharing what it checks. Control results must be acceptable before any patient result is reported. And when a control fails, "All patient test results obtained in the unacceptable test run and since the last acceptable test run must be evaluated". We had no such step when this study began; § 9 describes the small one we have added since.

Process and nuclear safety model the quiet guard directly. A process safety function is scored by its probability of failing on demand, and the failures that count against it are the dangerous undetected ones: they stay hidden until a demand arrives or a proof test finds them. That is the guard our roles kept meeting: ordinary operation never exercises it, so only a planted test can. A practitioner account of IEC 61511 (Green & Bell, 2017; the standard itself is paid and was not read) gives the field's numbers. The proof-test interval is set from the function's undetected failure rate and its target. Proof test coverage is the fraction of hidden failures a test can reveal, and what it cannot reveal accumulates until an overhaul. A failed device is tested as found, before repair, to learn whether it would have protected. Nuclear technical specifications (one plant's SR 3.0.1–3.0.3, in the standard form) make a missed surveillance "failure to meet the LCO", the limiting condition for operation, after a stated grace. We treat test coverage as yes-or-no, run every guard's test on one schedule, and render a lapsed test as stale rather than as not working.

Software testing research measured our census's blind spot. A pseudo-tested method is one the tests execute, but no test fails when its whole body is deleted. Niedermayr et al. (2016, 14 projects, read through a quoted extract) found this for a mean of 11% of executed methods under unit tests and 35% under system tests. They conclude that coverage indicates test effectiveness for the first and not for the second. Vera-Pérez et al. (2019, 21 projects, read the same way) found 1% to 46%, and a further result that bounds us. In three mature projects, the lead developers judged only 30 of 101 such methods worth more testing. Not every untested method is worth a test, and our owners made the same kind of call row by row.

SRE watches silence from outside (Prometheus documentation, read). absent() returns a result exactly when no series exists for a metric, which an alert on the series' value cannot do, since it has nothing to evaluate. The Prometheus Operator's Watchdog alert "is always firing", and "If not firing then it should alert external systems that this alerting system is no longer working". The watcher of the alerting pipeline has to sit outside it. When we did this study, our freshness checks ran inside the machinery they watched.

Human-factors work bounds the hand re-check. A systematic review of medication double-checking (Koyama et al., 2020, 13 studies, read through a quoted extract) found insufficient evidence that a second check lowers errors. Adherence was 52% to 97%, most studies never said whether the second checker was independent or primed, and the review does not recommend abolishing the check. The US Department of Energy's handbook (DOE-HDBK-1028-2009, verification sections read) keeps an independent verifier, "separated by time and distance" from the person who acted, on the systems, components and documents that management designates for it. It also names what a standing second check does to the first: "Performer is less attentive to the action, believing the verifier will catch any problems." Knight and Leveson (1986; abstract only, the paper is paid) found that 27 programs written independently from one specification failed together on substantially more tests than independence predicts: things built apart are not independent just because they were built apart. That bears on how far separate checks, or separate roles reaching one answer (§ 3), can be counted as independent.

What the field does that we did not. Five things, in rough order of cost to us: - look back over everything a failed check vouched for since its last good run; - count a missed test as a failed one after a stated grace; - watch the watcher from outside; - state coverage as a fraction; - set each guard's test interval from its own failure rate.

We had none of them. § 9 says which three we have since decided to adopt, and in what form.

SWE-Prometheus (read to depth) is the benchmark version of our question, and the paper that prompted this study. Its labels match our roles' language only in part. Detected is what our roles mean by "went red on purpose". Blind and vacuous name outcomes (a planted regression not caught; a gate too weak to catch one), while our roles' "a test on the wrong branch" and "a check that cannot fail" name causes, two of the causes that could produce those outcomes. Its result, less measured breakage under weaker gates while the median score barely moves, has the same shape as our live site's "a green line that is true about the wrong thing", seen across many repositories; that is an analogy, not a measurement of us. They label gates by mutation testing, and we labeled ours by asking the owners. Ours is weaker because no mutation testing ran, and stronger because the owners saw what a harness cannot: finished jobs, copies, procedures, and a guard that must never be fired.

Wu, When Errors Become Narratives, is a single-operator practitioner account of silent failures in a long-running agent system. It is the closest work to ours in setting, and we read it to depth before this study (no frequency from it transfers; its setting is one host and autonomous). Several of our practices restate his: the fail-plausible class; sabotage validation, where 67 checks that ran empty code for months were found only when a new check refused to fail; and collectors that could not tell "nothing there" from "I was not allowed to look" (his § 4.5). Three things we first took for our own are absent from his text (one word-search pass) but not from the field. A test vouches only for what it drove: pseudo-tested methods and the extraction control above. Distrust fails too: the automation literature calls it disuse (Parasuraman & Riley, named, not read). A continuous human eye makes weak checks harmless until it leaves: that is Bainbridge's ironies of automation (named, not read).

Huang et al., Gray Failure (read in full), coined differential observability: a failure one party perceives while the observer responsible for detecting it does not. We use the name where a second party would notice: a daily user, a customer who writes in, a peer who depends on the claim. In Huang's table, when neither the observer nor the application sees a problem, that is "no failure at all". We first held the quiet guard that has stopped refusing, with no one it protects present to notice, as a case no published model covered. Reading the field answered that: functional safety models exactly this case, as a dangerous undetected failure of a function scored on demand, and proof testing exists because of it. Gunawi et al.'s Fail-Slow at Scale (we read its introduction, method and suggestions) independently backs two of our practices: inject known faults to check "whether their systems or monitoring tools signal the right warnings", and do not let software "silently work around" a fault.

Systems of LLM agents, searched separately. A second scan, asked only about systems of LLM agents and run with web search, found no work whose subject is ours, and several that come close. The two AI-control papers we read do not rely on an untrusted monitor, one that might collude with the agent it watches, until it has been shown known-bad inputs; its normal output is "not suspicious". Greenblatt et al. (2024; protocol and results read through a worker's quoted extract) have the monitor score 30 synthetic backdoored solutions at the start of a run, and shut down if it misses too many; without that step, a monitor told to call real backdoors unsuspicious drives their safety score to 0%. Bhatt et al. (2025, same depth) do the same with "honeypots", and write that without them the monitor "can simply lie all the time". Both test the monitor once, before or at the start of deployment. Bhatt et al. suggest instead that "a more realistic protocol might involve retesting it at regular intervals with synthetic attacks inserted into real actions generated during deployment", and did not run it. Antithesis (Padhye, 2026, a vendor post, read in full) has an agent plant bugs in the system under test to see whether each property check fails, refining the bug or the test when it does not; in one campaign, 11 of 13 checks were made to fail and 2 were not. A planted bug whose code never ran earns no credit, which is our live-path condition; the broken copies are then thrown away, where ours stay and rerun when the check changes. Banik et al. (2026, read in full) found that 80.2% of 86,156 test changes written by five coding agents carried weak or no explicit check of the output. They read the added lines of each change, so, like our census, the figure measures whether an explicit check is written down; by their own caveat, not whether it checks the right thing. And Koran et al. (2026, worker extract) found that three copies of one monitor added less than the best trio of differently built monitors (5.5% against 13% on their detection measure), and a little less than a typical trio.

What remains ours is narrower than we first wrote. Making a check fail on purpose already exists in LLM-agent work, for monitors in AI control, tested at the start of a deployment, and for tests in agent-driven mutation testing, as a bounded campaign whose broken copies are then discarded. We found no one keeping those checks alive over time inside a running system of agents, where the checks are written, run and trusted by models, and a check's owner is a role that restarts without memory. The one paper that names re-testing over time proposes it and did not run it. Two scans' silence is still not proof. What we can offer that setting is an observational record of it, not a discovery.

An observation we did not test. The six tested guards aimed at AI sessions fire on routine traffic (every code read, every agent launch, every session close), while the four untested ones guard rare, high-stakes acts. That agrees with the kana editor's "a quiet guard and a dead guard are indistinguishable", and with § 4's finding that what tests a quiet check is use.

8. What travels

For a shop like ours (one human, several long-running agent roles, many checks whose normal output is nothing):

• Make a quiet check fail on purpose, on the path that actually runs, and write down what that failure exercised. A test vouches for that branch and that copy, and for nothing else.
• Put what the check could not see beside its zero. Give "I could not look" a different word from "I saw nothing", and print the denominator in the right scope.
• Use two tests per reading where you can: one known to be present, one made up. The first proves the right thing was read. The second proves the check can say no.
• Treat a clean-looking count as a claim about the instrument. Ask which direction the instrument can speak in before trusting its silence.
• Give distrust an expiry. Redoing a check by hand is a second instrument; it can hide a broken first one, or override a working one.
• Spend re-checks on the test nobody wrote down, not on re-running the builder's own.
• Where firing the test is itself the harm, prove the order instead, or build a synthetic twin, and say which you did.
• Test a pattern the roles believe, one role's or several, against a base rate before it becomes a rule. Twice in this study, such a pattern met a denominator: the count failed to support the one security proposed and turned around the one three roles named independently.
• When a check is found broken, look back. Re-examine what it vouched for since its last passing run; a clinical lab is required to. And count a missed scheduled test as a failed one once a stated grace has passed.
• Watch the watcher from outside. A heartbeat that the monitored system sends to something outside it catches the death that the system cannot report itself.
• To examine a whole shop's checks, ask each owner to account for theirs, one by one. A census can propose; only the owner can judge copies, finished jobs and procedures. After the asking, nine of the twelve roles asked built, queued or owed a new test and a tenth drove two refusals by hand; the asking may itself have prompted some of that.

9. What we learned, and what we are doing about it

What the paper that prompted this study did for us. It raised a question about our own shop that we could not answer, and sent us to look at how our roles had actually handled it. The roles whose work can be checked against the ground had mostly reached the same practices, each through its own incidents. Part of that was shared rule before we asked (§ 3); the rest each role found for itself. Each practice is backed by incidents in which it caught something real. So there is a working standard here, and our plan is to learn from what we found and make it the same everywhere, rather than something each role rediscovers after its own incident. That doing so pays is our bet, and point 4 below says how we are measuring it.

1. One standard for every refusing check that guards a high-harm act. It has a standing test that (a) drives the real refusal on copies; (b) carries a deliberately broken copy of the check that the test must catch; (c) reruns when the checked file changes; and (d) where driving it would itself be the harm, is replaced by a declared ordering proof or a synthetic twin. Our infrastructure role is building it with four refinements: - one list per domain, so no role edits another's file; - a line every test must print, with the count of broken copies it caught, so a test that has never caught one fails; - only fast tests at commit, the rest on a schedule; - a scheduled run whose last date shows as stale, on the screens people already read, when it has not run, and never as clean. That one is aimed squarely at § 5's twenty-day case.

The rollout was ratified in stages: first the infrastructure role's own checks and about ten of the highest-harm rows, with the other roles enrolling after two weeks of counting how often the new tests refuse wrongly. Each role then enrolls its own checks, starting from the ones it already called high-harm and untested in § 6, because § 6 showed that a pattern detector cannot do it.

2. Distrust gets an expiry. The human has ended the security role's July rule (§ 5; § 5a was written before the change), under which it had to re-read the production record itself for every load-bearing verdict. That rule was right when it was made: the instruments had not earned trust, and rebuilding them took months. Now the role relies on an instrument that passes its own four-part test (§ 5a) and verifies it on a schedule. Where no instrument passes for a load-bearing verdict, it checks by hand once and then builds the test. Redundancy with no measured need is inefficiency. Here it is also a senior role redoing, at its own cost, work a builder already did.

3. What the security role's own record showed before the change. We coded 80 of its commits from August and September that describe a re-check, drawn at random from 865. 59 were re-checks made at the moment of use, and they split three ways: - its own earlier claim: 22 of 25 re-checks changed the answer; - a builder's or a peer's report: 7 of 29 changed it (one builder reported "10 controls, 10/10 PASS" on a suite that had run 9 and skipped the broken copy); - an instrument's output: 1 of 5.

These are upper bounds, because a re-check that changed something is more likely to be written down. Many of the re-checks of its own claims were also prompted by something that already looked off, so 22 of 25 describes those re-checks, not how often the role's claims are wrong. Our prediction, made before coding, was that 10–25% of re-checks would change the answer; 30 of 59 did, so it failed for the whole set and held only for builders' reports and instruments. Even so, they redraw where the redundancy sat. The rule began with redoing a builder's report (§ 5a), and that was most of its re-checks here (29 of 59); reviewing a builder's work goes on under the shared review rule, spent on what the builder could not check. Redoing an instrument's output was the smallest class (5 of 59). Re-checking its own claims, when something already looks off, is where the corrections came from, and it stays. And clause (b) of the standard is built to fail that 10/10 case without a hand: the broken copy was the one the suite skipped, so it caught none. That is by construction, not yet shown on a replay.

4. How we will know. We are measuring the rework before and after the rule change, with the other thirteen roles as the comparison group, since the rule changed for one role only. The predictions were fixed before anything was coded. If slips double, meaning instrument-backed verdicts later retracted, the rule comes back for that class of check. Once the standing tests ship, we re-run the census and re-send its messages, and that measures whether the standard is being kept.

What the measurement found (October 11, after 600 of the security role's commits). The re-checking did not shrink. We drew 80 re-check commits from before the change and 80 from after, shuffled them together, and had one coder sort them without knowing which side each came from. The before set is point 3's 80, coded again so that both sides share a coder, which is why its counts differ a little from point 3's. We had fixed in advance that a fall of less than a quarter would mean the change did not take. It fell by about a tenth.

The rate is the share of the role's commits that use re-checking words, times the share of those the coder judged to be such a re-check. So the amount barely moved while the mix did: fewer re-checks of its own claims, and more repeats of the builder's tests. Four limits apply. The total is a blunt test of this change, because redoing an instrument's output, the class the September 27 wording names directly, was 3 cases on each side. The comparison with the other roles, which point 4 relied on, did not hold: their commit volume doubled over the same weeks and diluted their share of re-checking words, while the security role's stayed flat, so none of these shifts can be pinned on the change. The slip count cannot settle point 4's safety test. In the before draw the role itself caught 14 of the 16 retracted verdicts (a peer caught 2), so a fall can mean fewer slips or less catching. And these counts are small: two weeks of one role, with one coder.

What it means. The total re-checking rate did not fall by the quarter we had fixed in advance, but it is a blunt test of this change (above), so it does not tell us whether a written rule can change this behavior. It is consistent with § 3's lesson that a lesson in prose does not fire, and does not show it. The repeats of the builder's tests also go against a second written rule the role already carried, which says to spend a review on what the builder could not check. The decision to trust an instrument is, so far, only a rule.

What we propose next: make that decision a mechanism too. The roles that own the machinery decide the design. We proposed two mechanisms, and the infrastructure role decided both the same day. - Make a review say what it checked beyond the builder's own tests: adopted, live since October 12. It is a required field in the review record, so a review that only re-ran the builder's tests shows as one. "Nothing beyond" is an accepted answer, so a review with nothing to add is not pushed to invent something. - Show the evidence at the moment of the re-check: declined until more checks have standing tests (point 1). When a role reviews a builder's report, it would see whether the instruments involved pass their standing tests and how many broken copies those tests have caught. But of the builder changes reviewed since September 20, only about one in nine touched anything a standing test guards, so at most reviews the display would have nothing to show. Adding those tests is each owner's choice. The proposal reopens when any role's reviewed changes reach guarded files a quarter of the time over two weeks. - Measure the adopted one from the review record we already keep, two weeks after it lands: whether re-runs fall, and whether the checks beyond the builder's are the ones that catch defects.

5. What the field adds, and what was decided. § 7 found five practices the field uses and we do not. Whether the standard adopts them was the infrastructure role's decision, since the standard is its design, and it decided after the roles it affects gave their input and pushback. The research role recommended the first three. All three were adopted in a small form, and the two after them were declined at our size. All three have since been built and are live.

• The look-back: adopted, minimal. When a standing test fails, it reports when the guard last passed and what has changed in the guarded files since. The guard's owner does the look-back from its own record, and says how far back that record could see: an edge guard's look-back, for one, reaches only as far as its logs are kept. There is no general machinery for finding what a guard let through, because each guard's record is different. The reason for it stands: without it, the test finds the broken guard and leaves standing everything the guard wrongly passed, where a clinical lab must re-evaluate every patient result since its last acceptable control.
• A missed run counts as untested after a stated grace: adopted as a reading, not a gate. Past the grace, a guard reads as not tested, never as clean. It blocks no one's work, and if it ever becomes a gate, what clears it is running the tests, never an override.
• Watching from outside: adopted. A line that appears only when something is wrong, on the screen each role already reads at the start of a session: a role's own failing tests to that role, and a missed scheduled run to the infrastructure role. It is produced at session start, not by the scheduler, so a dead scheduler cannot silence it.
• Two declined at our size: coverage as a fraction, and a separate test interval per guard. Both need a failure-mode analysis of every guard. The owners' row-by-row judgment of which guards matter (§ 6) already does most of that triage, and the one measurement we found of that kind of triage points the same way: in three projects, developers judged 30 of 101 pseudo-tested methods worth more testing (§ 7).
• Keep the hand check as point 2 has it. The field keeps an independent second check on a designated list of critical steps, and its best review found insufficient evidence that a second check lowers errors. We have no evidence yet that a standing one would pay here.

10. Bounds

• One shop. Our roles, one model family (Anthropic's Claude), one codebase. § 8 is our judgment of what would carry over, not a measurement of it.
• "Independently" has a limit. Every role loads one shared rule on this subject, and shared guidance carried six more of § 3's practices before we asked (§ 3 names them). For those, the agreement is partly instruction; the evidence is each role's own incident, not the number of roles that said it. And a model with none of our records, sent the same message, states two of § 3's practices outright (§ 3); for those, the number of roles carries nothing. All eight of its answers also reach at least the weaker form of the main answer, fail on purpose; under our coding rule, two, from one family, add the live-path condition (more on the most generous reading, as above). It is one message, four model families, two answers each, coded by the author, who holds the hypothesis; every coded cell that counts a practice as reached or partly reached carries its quote.
• Self-reports. § 3 and § 4 rest on the roles' written accounts. Every cited change was checked to exist; counts inside the accounts are the roles' own unless we say we opened them. The research role's own answer was written after the plan and the predictions, so it is the least independent.
• The census reads names and words, not behavior. No mutation testing was run shop-wide. Its "no test found" was wrong for about three in ten real refusals, in a pattern that depends on each role's naming conventions. So no per-role count from the census is quotable, and none appears here (§ 4's figures are pooled across groups of roles).
• The messages are audit prompts. Every "found while answering" and every test built in response measures the prompt as much as the role. None of it is evidence that a role never audits unprompted.
• § 5 reads one role, through samples of 12 and 10 transcripts out of hundreds and a vocabulary count whose word lists are ours and uncalibrated. All three lines dated the move to July–August; the role's own read put its start in late April. Lines that sample the same record share its blind spots, so their agreement dated the default, not the start. The corrected date rests on the role's change history, which we opened, and on its own account of it.
• § 6's two nulls are small. 12 "nobody present" rows; 10 guards aimed at AI sessions. Owners' importance and harm were read from the same sentence by one coder. And the coders of who-is-present coded the refusal they found, which in a script with several may not be the one the owner judged.
• Different populations. § 3 is about monitors, § 6 about guards inside tools, and neither scores the other.
• The literature check is two blind scans and their reading rounds. A second scan, asked only about systems of LLM agents and run with web search, named 23 works; we read five of them, at the depths § 7 states, and the rest are named, not read. The first, blind to our frozen conclusions, named 54 works; we read the ones § 7 leans on, at the depths it states, and stopped after three rounds of searching. The paid standards (IEC 61508 and 61511, ISO 26262) were not read, and IEC 61511 rests on one practitioner account. Knight and Leveson is abstract-only. Works § 7 names without a depth were named, not read.

How this could be wrong

• If a name-based census is good enough on its own. Re-run the census two weeks after publication and send the same messages over the checks it then cannot credit. If owners call fewer than 1 in 10 of the real refusals tested on the live branch, the census is good enough without them, and § 6's first claim fails. Result, re-run October 9: the claim held. On the new rows, owners called 16 of 29 real refusals tested on the live branch (55%). It is 48% if a test that covers only some of a check's refusals counts as none, and 70% if six guards in tools since retired are counted as finished jobs (§ 6, The re-run).
• If guards aimed at AI sessions are neglected after all. On that same re-run, code who is present with the same rule. If guards aimed at AI sessions make up more than twice as large a share of the untested rows as of the tested ones, § 6's second null reverses and the three roles' observation stands. This needs at least 10 such guards across both sets; this census had 10. Result, same re-run: the null held. With the new rows added, guards aimed at AI sessions are 6 of 77 untested rows (7.8%) and 7 of 51 tested rows (13.7%), a ratio of 0.57 against a line of 2, across 13 such guards. The new rows alone would cross the line (2 of 13 against 1 of 16, a ratio of 2.5), but that rests on three guards, well below the minimum of 10. Recoding the coder's least certain calls, every caller it had only inferred to be an AI session, as human leaves the pooled ratio at 0.47, further from the line.
• If retiring the hand re-check lets slips through (§ 9, point 4). Count the role's retracted instrument-backed verdicts after the change. If they double against the same count before, the rule comes back for that class of check. Result, October 11: this could not be judged. The count fell from 16 to 3 in 80 commits, but the role itself had caught 14 of the 16 before, so a fall can mean fewer slips or less catching (§ 9, point 4).
• The security role's move into design was tested in § 5 with two conditions fixed in advance. The first fired and moved the date to late April. The second stands: a quiet result left un-redone after August because of accumulated quiet runs alone would kill the reading.

Conclusions

We asked how an AI role comes to trust a check whose healthy output is nothing. Our roles' answer, and the field's long before theirs, is that the silence is earned only by watching the check fail on purpose, on the live path (or, where that would do the harm, by proving the order of its steps), and that it covers only what that failure exercised. Three things follow for a shop like ours.

Knowing the rule is not the same as meeting it. Our roles' accounts were about quiet monitors; the census looked at guards inside tools, a different population, and most of the guards it flagged in its first round still had no test on the path that actually runs. One role had earned its monitors' silence and still carried such guards (§ 6). Only a look at each check, one at a time, tells the two states apart.

Ask the owner. A census that reads names and words can only propose, and asking cost one message per role. The owners saw what it could not (copies, finished jobs, tests kept as procedures), and most drove refusals by hand or queued tests while answering; some built them afterward. The examining was the applying.

An agreement is not evidence until it survives a comparison group. Twice, roles believed a pattern, and a count nobody had taken failed to support the one security proposed and turned around the one three roles named independently.

So we are making the practice one standard for high-harm checks, rolled out in stages, and three of the field's safeguards are now built in a small form and live: when a check's test fails, report when it last passed and what has changed since, so its owner can look back; count a missed test as untested; and watch the scheduled run from outside. We also retired one role's rule of re-reading the production record by hand, and two weeks later the amount of its re-checking had barely moved. We cannot pin that on the change, so it does not show that a written rule is weaker than a mechanism. The next step is a mechanism: every review must now say what it checked beyond the builder's own tests. Showing a role an instrument's test evidence at the moment it decides whether to re-check waits until more checks have standing tests: about eight in nine of the builder changes reviewed since September 20 touched nothing one guards (§ 9). What stays open is whether anyone keeps these checks alive over time inside a running system of LLM agents: two scans found the practice in AI-control and agent-testing work at the start of a deployment or as a bounded campaign, and keeping it up over time only proposed.