One entity, two readers
Every Evidence row is read by two different audiences after it's written. The user, scanning a UI to understand why a claim was assessed a certain way. And the integrator itself, returning on a later cycle to re-evaluate.
The fields are split deliberately. Some are narrative, for humans. Others are structured, for the integrator. Mixing them is how integrators drift.
What humans read
When a user opens this Evidence in Elevator, this is the part they engage with: rationale and concern_text. Prose. Reasoning. The explanation of why the integrator said what it said.
These fields exist to explain. They are written for one audience: the human. They are never re-consumed.
What the integrator reads
The machine-state fields are different. source_claim is the atomic claim, stated plainly. fragment_snapshot is a verbatim quote from the source document. confidence, status, and source_verified_at are calibration flags.
These fields are written with care and updated only from authoritative triggers. They're structured because they must remain machine-readable a month from now.
The next cycle
A month later, the integrator returns to this Evidence because the source document changed, the edge became stale, or a user disputed the interpretation. It re-reads the source document and the machine-state fields.
It deliberately ignores its own previous rationale.
Why
Your own previous narrative is a hypothesis about what the source says. The source itself is the authority. If you re-read your own narrative on the next cycle, errors compound — a slightly generous initial assessment becomes the baseline for the next one, and drift accelerates.
The same split applies elsewhere. Question has findings,
recommendations, proposed_answer for users — and source_extracts,
source_responses, tagged_users for the integrator. Requirement has
interpretive_context: append-only, citing every trigger. Different entity, same discipline.
The Deliverable is not substrate
The same boundary applies at a larger scale. A Draft or compiled Deliverable is an output produced from regulator clauses, user documents, and human answers. Its polished prose cannot be fed back in as proof that its own claims are true.
Generated content may explain the source. It may never replace the source.