What code checks, and what people check

01 / Valid structure does not establish truth

A model prepares a report: seven events from ten observations. The numbers are within range, the file opens and the source has an identifier. Is the report true? Neither valid JSON nor a green validator result answers that question. The source might not exist and the seven might be invented.

Some checks still belong in code. The purpose is to make repeatable conditions less dependent on another instruction to the model. First establish what can be checked unambiguously and what that check excludes. This extends the agent authority card method.

02 / What the research actually shows

FollowBench, ACL 2024 examines compliance with detailed instruction constraints and identifies weaknesses in the models tested. It motivates checking compliance; it is not a ready-made reliability measurement for today's tool.

Lost in the Middle, TACL 2024 shows that performance on the studied tasks depends on where relevant information appears in long contexts. This does not mean every instruction in the middle of a document is always ignored. It motivates testing representative inputs yourself.

Kalai and Vempala, Calibrated Language Models Must Hallucinate derive a bound for particular facts under a statistical calibration assumption. It does not prove that every system must fail at every task or that checking calculations is pointless. This public adaptation narrows an overbroad conclusion in the working bibliography.

Research helps frame a design question. Testing a specific implementation establishes whether its check works. A bibliography cannot replace product acceptance.

03 / Three scopes of checking

The first is structure and consistency: required fields, types, allowed values and relationships between numbers. If a count describes a subset, it cannot exceed the total. An unknown result should not become zero. These conditions can be checked without asking the model again.

The second is authority to act: whether this process may perform this operation on this object. Enforcement must sit on the actual execution path. A valid file does not grant permission to send it externally. This edition neither builds nor tests an authorisation system.

The third is meaning and sources: whether the number covers the right period, a quotation preserves its meaning and the source supports the claim. Tools can assist, but a simple field validator cannot settle these questions. Identify who reviews the content and on what evidence.

04 / A small runnable example

Download the Python demonstration. Run python validator-demo.py. It uses only the standard library, with no model, network or production data, and writes no files. The example is fictional.

A record has four fields: status, count, total and source_id. Status is either measured or unknown. An unknown count must be null; a measured count must be a non-negative integer no larger than the total. The total must also be a non-negative integer. The source identifier must be non-empty text. Additional or missing fields are errors.

{"status":"measured","count":7,"total":10,"source_id":"invented-source"}

This record passes structural validation. That is deliberately the demonstration's central case: a non-empty identifier does not prove that the source exists, and an in-range number is not measurement evidence. The label measured remains the data author's assertion until linked to evidence.

05 / Results of seven trials

Seven local demonstration tests ran on 25 September 2026. All passed, meaning behaviour matched the stated expectations:

• A measured zero out of ten was accepted.
• An unknown result with null was accepted.
• An unknown result replaced with zero was rejected.
• Eleven events in a set of ten were rejected.
• Boolean true in place of a number was rejected.
• An empty source identifier was rejected.
• A plausible-looking record with an invented source passed, consistent with the validator's limited scope.

These are not seven tests of report truthfulness. They are seven trials of a function checking selected rules. We did not test server deployment, whole-system resilience or a particular model. The result is not a percentage score of product safety.

06 / Code needs acceptance too

A badly specified rule can consistently reject good data or accept bad data. Test valid cases, boundaries and deliberately damaged inputs. Check types: Python booleans can behave like integers, so the demonstration deliberately checks the count's exact type.

Also ask whether the rule matches the question. “Count no greater than total” suits counting members of a subset. It may not suit counting repeated occurrences within the same documents. Clarify the unit and denominator before changing code.

A check before an operation does not guarantee the data stays unchanged until use. Bind acceptance to an input version and verify the operation's actual result. Avoid alternative paths that bypass the check. Validator failure should produce an explicit lack of acceptance, not an automatic “all clear”.

07 / What to show the human reviewer

Instead of a green mark alone, show what was checked, under which rule, on which data version and what remains unchecked. Attach measurement evidence, the time scope and counting method to a numerical record. A quotation needs a link to its source passage, not merely format compliance.

Another model can find discrepancies and assist review. Its agreement does not become independent proof of truth or human approval. A reviewer needs the ability to inspect the material, reject it and record a reason. Simply placing a person at the end of a process does not establish the quality of oversight.

To apply this method, start with one report and three conditions you currently check manually. In a conversation, we can separate rules to encode from questions needing sources and judgement. A neutral example is enough to begin; private data is not necessary.

08 / Sources, provenance and corrections

The starting point was the complete internal bibliography dated 21 June 2026. Descriptions of the three linked papers were rechecked with author and publisher sources on 25 September 2026. We do not present an earlier claim of independent verification as work performed for this edition. Legal claims and a historical assertion about a specific safeguard are not carried over as claims about current production.

Codex prepared the PL/EN text, original diagram and demonstration code. Author review and the seven described tests were completed, without an independent second-model review. No third-party illustrations or private data were used. Changed field semantics, a validator bug or a material correction to a cited paper triggers reassessment. The edition can be withdrawn after publication.