A Question is born
Some Requirements have no support in any Document the team has uploaded. Rather than guess, the integrator creates a Question — a specific, scoped ask, tagged to the people likely to know.
Status: open. responses[] is empty. The Requirement this Question
is anchored to is marked blocked until the gap is filled.
The user responds
The CEO opens Elevator, sees their inbox, types a reply. Their words land in
responses[] verbatim — never re-authored as the integrator's own
proposal.
Status flips to answered. The Requirement transitions from blocked
to ready. Drafting can begin.
A change in basis
A month later, the regulator publishes an amendment to GIBFIN 12.4. The new clause — 12.4(b) — demands more detail than the original Question asked for. The CEO's answer is still true, but it's no longer sufficient.
The integrator notices on the next round. The framing of q_a8f3b no longer
matches what the application needs.
Retire and replace
Pattern B: don't edit the original Question. Mark q_a8f3b as
retired with a status_context explaining what triggered the
change. Create q_a8f3c with the updated framing. Relink the Requirements
from the old Question to the new one.
The original answer is preserved. The audit trail stands. The active question is fresh.
Why
Editing the original Question silently rewrites history. Users wouldn't see why a follow-up was asked — only that one suddenly appeared. The integrator wouldn't be able to trace its own past reasoning on a later cycle.
Retire-and-replace makes the discontinuity legible. A user can read the chain: "this is what we asked → this is what you said → this is why we're asking again." That legibility is what an audit trail is for.