The Four Checks

ESSA, the Process-to-AI Pyramid, and the Process Maturity Model all govern the same side of the problem: the condition of a process before technology is allowed near it. They are gates on the input. The Four Checks are the counterpart on the other side. Once a system is running and producing output, something has to decide whether that output deserves to be acted on. Four gates for the process, four checks for the output. That symmetry is the reason this sits next to the other three rather than somewhere else.

Each check comes out of a specific finding we have published, and each one names a failure that is invisible in the output itself. A confident wrong answer. An addition the source never made. A coin flip called without anyone being told there was a coin. A real theme deleted by a row limit. You cannot catch any of these by reading the output more carefully, because none of them read wrong. You catch them by checking something the output does not contain.

Put the human gate at the point where a wrong-but-confident output would cause harm before anyone catches it. Trace the output downstream and find the first place a bad answer becomes an action that is hard to reverse. Money moves, a customer hears it, a record changes. The gate goes at or before that point.

The working test is detection latency: how long until a mistake surfaces on its own, and what it costs while it is still out there. Errors that surface fast and cost little do not need a reviewer standing over them. Errors that surface slowly, or only after someone downstream has already relied on them, need one before the output leaves the system. Both extremes fail, and they fail differently. A gate on every routine output buries reviewers in volume and kills the efficiency case for the whole deployment, which is how review theater ends up quietly abandoned. No gate where the harm lands lets a hedged non-answer get read as approval. Gate placement, not gate existence, is the design variable.

Ask what the task actually is. A cued lookup points the model at something the source already says. Composition hands it a blank space and asks it to decide what belongs there. Those are different jobs with different failure rates. In a controlled three-run test on a synthetic operations log, retrieval never failed: confusable unit numbers, a door code that changed and then reverted, two amounts written as digit-transposes of each other, all handled cleanly. Every verified error showed up in open drafting instead, and every one was an addition, a statement the source never made.

So the gate belongs on the task type rather than spread evenly across the workflow. Pointed lookups can run with a lighter touch. Anything that composes needs claim-level citation: every operational claim, a code, a time, an amount, a pronoun, has to trace back to a source line, which turns the human review into a walk of the citation trail instead of a re-read of the whole source. One more consequence follows, and it is the one teams skip. Evaluate the composing task directly. If you test an AI writing system by asking it questions, you are measuring the part it is good at and shipping the part it is not.

Running a prompt twice and getting the same answer settles reliability and nothing else. A stopped clock passes that test forever. Validity needs a reference you trust, and the reference has one non-negotiable property: it has to exist before the model sees anything. A key written afterward drifts toward whatever the model said, and so does a key that lives in somebody's memory of the right answer.

Our measurement test showed both halves of that at once. Three fresh runs sorted ten synthetic guest messages into the same categories, and every label matched a key locked in advance: thirty for thirty, deliberate borderline cases included. The open half of the same output, a ranked list of recurring themes, flipped order between runs, and by the model's own counts the top two themes were tied at three messages each. Not one run mentioned a tie. Steady is not the same as right, and it is not the same as settled either. Had the key been wrong, three agreeing runs would have marched off the same cliff together.

This check has two parts, and the first one decides where effort goes. Bounded tasks have fixed evaluation criteria and an answer somebody can check. Unbounded ones do not. Jahani and colleagues ran two preregistered tasks across 3,750 participants and nearly 37,000 prompts in 2026, and the split runs along exactly that axis: on the task with a checkable right answer, prompt adaptation was worth roughly half the gain of upgrading the model outright, while on the open-ended creative task its role was limited and the gains came from model capability. The instruction is short. Where there is a right answer to check, prompt work is among the cheapest gains an operation can buy. Where there is not, buy the better model and keep the human.

The second part is what the constraint costs you. Every capped output discards, and it discards without saying so. A three-theme limit in one of our tests deleted a real recurring theme, air conditioning raised by two separate guests with summer coming, and nothing in the output noted that anything had been cut. A table with three filled rows always looks complete. The fix is small and we treat it as mandatory now: a named overflow slot on every capped output, holding whatever cleared the mention threshold and missed the ranking, each entry carrying the condition that would promote it. The cap stays. The loss does not.

Take the brief a shift lead reads before the day starts: overnight incidents, arrivals and departures, supply issues, anything the previous shift left open. Inside our own rental operation this is the kind of work RebornOS agents are built for, and it is the highest-risk item on the list precisely because it looks like the safest.

Start with placement. A brief that drops an item is not visibly wrong. It is just short. If an open maintenance issue never makes the brief, nobody in the room knows it was omitted, and the mistake surfaces when a guest walks into it days later. Long detection latency, real cost while it runs. So the gate goes before the brief is read in the meeting, not after somebody complains.

Then the task type. A brief composes; it does not retrieve. Nobody asks it a question, so nothing anchors its choices about what belongs. That is the exact shape where additions appear: supplies that were ordered turning into supplies on hand, a silence in the log turning into a decision the log never made. Every operational claim in the brief cites its source line, and the shift lead walks the trail rather than re-reading the night's log.

Next the key. Someone has to write down what counts as a reportable incident, what outranks what, and how a tie between two equally urgent items gets resolved, before the model has seen a single week of logs. Skip that and three identical briefs prove only that the assembly is steady, which is the property a stopped clock has.

Finally the shape. The brief is bounded, so the prompt is worth real investment: fixed inputs, a severity policy the operator wrote, an output checkable against the log. It is also a capped output by definition. Somebody decided how long a brief should be before anyone knew what it would have to say. A brief that drops the one thing that mattered reads exactly like a brief that had nothing to report, and no one in the meeting can tell those two apart. That is where the overflow slot earns its place more than anywhere else we run.

Run them in whatever order the workload suggests. What matters is that all four run, because the output will never tell you which one it failed. It reads fine either way.