The green light appears just before the next decision.

Imagine a validation service has checked Tuesday's release. Its source record is sound. The result is stored with the rule version that was applied, the evidence that was observed, the time of the check and a warning that remains unresolved.

An operator sees a green circle on a dashboard. An AI agent asks an API and receives { "passed": true }.

Both outputs are accurate. Neither is enough.

The operator cannot see whether the light belongs to the release in front of them. The agent cannot tell whether the result is current, which rules produced it or whether the open warning changes what should happen next. A complicated check has been compressed into a reassuring signal, and the meaning needed for action has fallen away.

The interesting failure is not that the system stored the wrong result. It is that the route from the result to its readers was treated as presentation rather than part of the system.

The green light is telling the truth

I have spent a lot of time strengthening the way information enters a system. Inputs are checked. Changes are recorded. One place is declared authoritative for a particular decision or fact. History is preserved so that a later reader can see what changed.

That work matters. A weak write path can corrupt a system before anyone tries to use it. But I have increasingly found that a strong write path can produce a system that is correct at rest and still weak in use.

When I return after some time away, can I find what governs now? Can I tell why it governs and what remains unresolved? Can an AI agent retrieve the same state without treating a convenient summary as the decision itself?

If those answers depend on what I happen to remember, the system has stored the information without finishing the route by which it becomes useful.

One result, two incomplete readings

Source recordValidation passedRelease scope · rule version · evidence · checked at · open warning

Represented as

Human view PassedScope and limits are not visible
AI route{ "passed": true }Relationships and status are not explicit
Next decisionWhat does “passed” permit now?

A challenge or correction returns to the validated source record, not to either derived view.

The stored result can be correct while both representations omit the context their readers need. The failure occurs between authoritative state and responsible use.

What a usable result carries

The same underlying state can be presented differently to a person and an agent. A person may need a clear explanation and an obvious route to question the result. An agent may need scope and relationships expressed explicitly rather than implied by page position or team convention.

The representation can differ. Four questions should remain answerable when the consequence warrants it:

Authority
What decision does this result govern, and for whom?
Currency
When was it checked, and is it still the current result?
Provenance
Which rules and evidence produced the signal?
Uncertainty
What remains incomplete, disputed or outside the check?

The W3C's PROV model defines provenance in terms of the entities, activities and people involved in producing data or another thing. That information can support judgements about quality, reliability and trustworthiness ( W3C PROV overview). A full provenance standard would be excessive for many ordinary systems. The smaller lesson is that a consequential output should preserve enough of its origin and transformation for its reader to judge what it is.

Humans follow cues; agents follow structure

People do not inspect every available record before acting. We follow cues that suggest where useful information is likely to be and weigh the expected value of looking again against the effort involved.

Peter Pirolli and Stuart Card's information-foraging theory models this more carefully. They argued that people adapt their information-seeking strategies—and sometimes the environment itself—to improve the rate at which they gain valuable information ( Pirolli and Card, 1999). The theory is broader than workplace software. It does help explain why placing the right answer somewhere is not enough: labels, routes and context influence whether anyone reaches and recognises it.

When the intended route is obscure, keeping a shorter summary or relying on the colleague who remembers where the answer lives can be a reasonable response. It can also allow a convenient representation to gather more authority than it was designed to carry.

AI systems have a different route to the same problem. They can search more material than a person, but retrieval does not by itself identify which record governs a question. A result may be current, stale, proposed or merely adjacent. If those relationships do not survive retrieval, the model has to infer them from whatever text it received.

The HoH benchmark offers a useful, narrow example. In tests involving changing public facts, outdated information reduced the accuracy of retrieval-augmented systems and could mislead them even when current information was also available ( Ouyang and colleagues, 2025). That benchmark is not an internal validation system. It does demonstrate the narrower mechanism: having the current answer available does not ensure that a model will distinguish it from a plausible older one.

Human and AI readers therefore need overlapping properties made accessible in different ways. Both need a route towards the governing state. Both need to recognise its scope and age. Both need important uncertainty to remain visible after a result has been compressed.

Take one result through the whole loop

Read paths should influence system design, but it is difficult to predict every representation a future reader will need. I do not think the answer is to specify them all upfront. A more useful starting point is one thin, governed loop.

Thin means narrow in scope, not careless about consequence. For the validation result, I would:

  1. Write one representative result through the intended validation path.
  2. Show it through one human-facing view and one AI-readable route.
  3. Ask each reader to make the real, bounded decision that the result is meant to support.
  4. Check whether each can identify its authority, currency, provenance and uncertainty.
  5. Challenge or correct the result through the intended source path, then run the loop again.

This can expose a deeper modelling gap. A reader cannot identify the current result because supersession was never represented. An agent cannot explain the signal because the evidence relationship exists only in prose. A reviewer cannot challenge it because the system records conclusions but not their status.

Not every failure requires a new abstraction, field or workflow. Sometimes a clearer label or a better-placed link is enough. The purpose of the loop is contact with actual use, not permanent expansion.

Not every green light needs a dossier

A temporary check for a reversible local task may need little more than its result and a short lifetime. A financial decision, production change or safety constraint deserves a more durable connection to scope, evidence and unresolved risk.

The principle is not that every system needs more metadata or another dashboard. The read path should be proportionate to the cost of misunderstanding the result and the difficulty of reversing the next action.

The green light was not wrong. It simply carried less meaning than the next decision required.

For consequential systems, I now treat the read path as part of the architecture. The path includes the representation a reader encounters, the context needed to interpret it and the route back when the result needs to be questioned.

A result becomes useful when its reader can tell what it means, what it applies to and how to question it.

Further reading

These books offer related lenses rather than direct proof of the argument. They are included as a reading list to examine, not as endorsements of every claim they contain.