The system is in the handover

Where every part is correct and the result still fails

A decision rarely lives in one system. It can start in a document, draw context from a store, pass through a retrieval step, be interpreted by a model, become a proposed action through an agent, and continue into an operational workflow.

Every one of those components can behave correctly on its own. The harder problem is what happens between them.

Information moves while its operating context degrades. A document is copied without its lineage. A model receives a relevant passage without knowing which version is still authoritative. An agent is capable of invoking a tool without being the source of the authority to use it. A reviewer later sees an outcome and cannot reconstruct the evidence, the identity, the state and the approval that produced it.

The failure lives in the transitions, which is what makes it an operating problem rather than a technical one.

Four things that are usually treated as one

When a system proposes and then performs an action, four distinct facts are in play, and they collapse into one unless something holds them apart:

• what a component can do;
• what it is permitted to do;
• what requires approval;
• what is actually executed.

Capability is not permission. Permission is not approval. Approval is not execution. Each is answered by a different part of the system, and each can be correct while another is missing.

Stated as an order rather than a list:

Identity precedes authority. Authority precedes consequential action.

This is not new with machine reasoning. Zero-trust architecture already treats access as an explicit policy decision rather than as trust inherited from a location or a component. What changes when probabilistic reasoning participates in consequential work is that the proposing component is now very good at producing something that looks authorised.

Retrieval answers a narrower question than it appears to

Retrieval solves a real problem: finding what is relevant to a task. Combining retrieval with generation makes external knowledge available at the moment of use, rather than only what a model absorbed during training.

That is valuable, and it answers one question:

What appears relevant now?

A handover has to answer several more:

• Where did this come from?
• Which version is valid?
• What changed?
• Who produced it?
• Under whose authority was it used?
• What later action depended on it?
• What was valid at the time, and what is valid now?

Those are provenance questions, and the vocabulary already exists: the W3C PROV model describes entities, activities, agents, derivation, attribution and use precisely so that this chain can be stated rather than remembered.

A system can retrieve exactly the right material and still lose the relationships needed to say which source was authoritative or what depended on it afterwards.

What this shares with a passing check

I have described elsewhere a defect family whose signature is wrong input, well-formed output, and nothing raised - a result that arrives on time, in the right shape, with the right fields populated, and is wrong.

A degraded handover produces exactly that. The workflow completes. The output is well-formed. Every component reports success. What was lost is the context that would have let anyone tell whether the result was legitimate, and its absence raises nothing, because absence is not an error condition anywhere in the chain.

That is why the check has to be structural rather than behavioural. Nothing in the run will tell you.

What can be checked

Take one consequential action the system performs and follow it backwards:

source -> identity -> authority -> approval -> decision -> execution -> evidence

Three questions at the point where it crosses a boundary:

1. What arrives, and what is dropped? Not what is passed - what the receiving side no longer has and cannot request.
2. Which identity is responsible here, and does the next stage know it? Authority that is not carried forward is authority that was assumed.
3. Could this be reconstructed six months from now? If reconstruction depends on someone remembering, the evidence is in a person rather than in the system.

The third is the one that fails most often, and it fails silently, because nobody reconstructs anything until something has already gone wrong.

The boundary of the claim

This is a claim about where to look, not a claim that any particular architecture is required. A vector store can carry metadata. A retrieval system can be built with provenance. A document system can version properly. The point is that these are separate responsibilities that are frequently assumed to come with the component.

It is also not a claim that the components are unreliable. The argument depends on them being reliable: it is precisely because each part works that the gap between them attracts no attention.

And nothing here is a measurement. No figure is offered for how often context is lost in a handover, because I have none that would survive being asked for its method.

What becomes possible

When the chain is stated, a system gains something it cannot otherwise have: an action can be wrong in a useful way. When the output disagrees with the world, there is somewhere to look - which source was relied on, which identity held authority, what evidence supported the step.

A system that computes without declaring what it assumed cannot be wrong usefully. It can only be wrong, and then argued about.

That is the difference between a result and a claim, and it is decided in the handover rather than in any of the parts.