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 are written once, with care, and re-consumed by future integrator cycles. They're structured because they have to be machine-readable a month from now.
The next cycle
A month later, the integrator returns to this Evidence — maybe because the source document changed, or because low confidence triggered a re-check. 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.