The answer record should not silently change

I opened an old K81R answer and found that its citation now pointed to different text.

The document had been revised. The source route opened the current revision because the citation stored only a document ID and heading slug. The answer still displayed its original prose, now beside evidence it had never seen.

Nothing in the database said the answer changed. Its meaning had.

I replaced the chat-message record with an immutable answer record whose dependencies could evolve only through new revisions.

An answer was more than text

The durable object included:

• Answer intent and revision ID.
• Exact question and task type.
• Requester scope and purpose.
• Source corpus and index generation.
• Evidence-set revision and ordered units.
• Answerability decision and gaps.
• Model adapter, model identity, parameters, and prompt revision.
• Generation attempts and accepted claim records.
• Citation-integrity and support-verification results.
• Review, acceptance, destination, and supersession state.
• Created, committed, and viewed-under-current-policy times.

The rendered paragraph was one view of this graph.

Every citation named source document, immutable revision, exact spans, heading context, and the evidence representation supplied during generation.

Opening it rendered that revision when authorized. The page showed if a newer revision existed and linked a comparison. It never redirected silently to current content.

If retention or policy made the source unavailable, the answer displayed an unavailable-evidence state. It did not attach a nearby revision as substitute support.

Historical provenance remained accurate even when current guidance moved on.

When corpus revision 45 superseded a selected policy, K81R marked the old answer potentially stale for current-state use. The original record stayed intact.

A reviewer could:

• Compare evidence revisions.
• Rerun retrieval under the new index.
• Create a new evidence set.
• Reassess answerability.
• Generate or author a new answer.
• Mark the old answer superseded.

The relationship linked both records and explained what changed.

“Refresh answer” became a workflow producing history, not an in-place overwrite.

The question itself had identity

Editing a question after receiving an answer would make the output appear to address wording it had never seen.

K81R stored exact submitted text and normalized retrieval interpretation separately. A correction or narrower question created a new intent linked as a refinement. Display could group them conversationally while records remained distinct.

The task classification—archive fact, comparison, summary, brainstorming, or current decision—also belonged to the revision. Changing it altered allowed claims and evidence requirements.

Conversation continuity did not erase request boundaries.

Two sets containing the same passages in different order could produce different emphasis. A set with a known missing adapter contract should not appear identical to one considered complete.

The answer linked the exact ordered set revision, structural context, token-budget decisions, contradiction labels, and gaps. The serialized model input had a content digest and inspectable diagnostic representation.

Removing a passage later created another set revision. The old answer remained supported—or unsupported—by the version it actually consumed.

Context became data with lineage.

Model identity needed more than a friendly name

Provider model names could be aliases or later point to changed implementations. The record stored the identifier returned or configured at request time, adapter version, endpoint class, parameters, context limits, and any dated provider revision available.

I did not claim this enabled perfect reproduction. External services could change. It established what K81R had requested and observed.

Generation attempts stored timing, usage, status, response schema, and content digest. An accepted answer linked the exact attempt or claim attempts that produced it.

Model provenance bounded uncertainty instead of inventing determinism.

Prompt revisions were immutable artifacts

The system prompt, task template, evidence serialization, and output schema collectively shaped generation. A version label with mutable template content was insufficient.

I stored content-addressed prompt artifacts with authored change notes and evaluation results. The answer record referenced the exact combination. Sensitive runtime values were represented by safe field digests or manifests, not copied indiscriminately into long-term storage.

A later prompt improvement produced a new answer. It did not retroactively claim the old prose had followed the better instruction.

Prompts became release artifacts, not hidden strings.

Claims had independent identities

The answer was composed from claim records containing text, type, evidence links, qualifiers, validation state, and generation attempt. Editorial smoothing could reorder or combine claims only through a new answer revision that preserved mapping.

A reviewer could challenge one claim as unsupported without rejecting unrelated supported claims. The correction attached evidence and rationale. A replacement claim received a new ID and superseded relation.

This made partial review and incremental streaming possible while keeping the final document coherent.

Text edits no longer erased which assertion had changed.

Verification was a dated result

A citation-support verifier could improve, source parsing could change, or a human reviewer could disagree. Verification records stored claim revision, evidence revision, verifier configuration, label, rationale, time, and reviewer where applicable.

Rerunning created another result. The answer displayed the review basis used at acceptance and whether newer verification existed.

A green state was not a timeless property painted onto the claim. It was a decision made under named evidence and rules.

An answer could remain a draft, be accepted into an architecture decision, contribute claims to a case study, or close as an insufficient result.

Acceptance named the destination document and revision, reviewer action, scope, and policy state. The maintained document became authoritative through its own workflow. The generated answer remained provenance, not automatic authority.

If the destination later changed, it did not rewrite the answer. Relationships showed lineage in both directions.

It also suggested a stricter boundary for future writing tools: generated proposals should enter maintained documents only through explicit, typed acceptance.

Permissions changed viewability, not history

An answer generated under broader scope could become partially or wholly unavailable to a requester after policy changed.

Opening the record revalidated sources and answer output scope. Restricted claims or evidence did not render. The system preserved the immutable record under appropriate authority and could show a disclosure-safe placeholder.

Sharing required every visible claim to be supported by evidence within the target scope. Removing citations did not downgrade derived information automatically.

Policy governed current access; it did not falsify the historical fact that generation occurred.

Deletion and retention followed each artifact

Raw provider streams, prompts containing copied evidence, vector indexes, answer records, source documents, and accepted maintained content had different purposes and retention.

K81R minimized durable copies. The answer stored structured claims, bounded source references or excerpts where justified, configuration manifests, and review. Raw token events expired unless a reviewed synthetic fixture preserved a failure. Source deletion could redact dependent evidence according to policy while maintaining a non-sensitive tombstone for lineage.

Provenance did not justify keeping every intermediate byte forever.

Corrections were visible

The old interface let me edit generated prose in place. A later reader could not tell what the model said, what I corrected, or why.

The revised workflow offered:

• Reviewer annotation.
• Claim replacement.
• Answer revision.
• Source correction.
• Evidence-set revision.
• Superseding maintained document.

Each action produced a diff and rationale. The public reading view could show the accepted latest revision while the provenance view retained history.

Correction improved trust by preserving the existence of the mistake.

The chat-like interface remained useful for navigation. It grouped question refinements, searches, evidence sets, refusals, and answers in time.

The transcript was derived from durable objects. Deleting a transient assistant message did not delete an accepted evidence set. Revising an answer did not mutate its original question. A source permission change could redact one item without corrupting sequence.

This reversed the first prototype, where the transcript was the database and every other state hid inside message payloads.

Conversation became presentation, not authority.

State transitions were explicit

An answer moved through:

requested
  → evidence-ready
  → answerable | refused
  → generating
  → partial | draft
  → verifying
  → review-required | reviewed
  → accepted | rejected | superseded

Failures and unknown external attempt outcomes lived beside these states. A page reload or worker restart resumed from durable records. No boolean isComplete attempted to describe the whole lifecycle.

Allowed actions came from state and policy. Retry was not universal.

A browser could submit the same answer request twice after a timeout. The request carried stable intent ID, question digest, evidence-set revision, and task. Reuse with the same digest returned the existing answer intent; reuse with different content failed.

Provider attempts had their own IDs and adapter idempotency capabilities. An unknown model-request outcome did not automatically create another billable attempt.

Z29C's external-effect model reached the generative system directly.

A Markdown or PDF-like export of the answer was useful and could lose interactive provenance.

Exports included a human-readable source list and a machine-readable manifest with answer revision, evidence, source revisions, model and prompt configuration, verification, and content digest. The artifact displayed its generation date and currentness boundary.

Import or later inspection could verify the text against the manifest and report unavailable sources. The export was a snapshot, not a live answer silently refreshing under the same file.

The UI made revision status legible

Readers first saw the accepted answer, evidence links, review state, and whether newer source or answer revisions existed. A detailed provenance view exposed every manifest and attempt.

Historical answers used clear labels: Generated from corpus revision 44; superseded by answer 7; one source no longer current. They remained readable without looking like present guidance.

The page did not drown ordinary reading in infrastructure metadata. It also never hid staleness behind a small timestamp.

The wrong retry answer now showed:

• Its exact question.
• Semantic-only index generation and fixed chunk parser.
• Superseded retry note in the evidence set.
• Missing adapter capability.
• Model and prompt used.
• Unsupported claim and later reviewer annotation.
• Corrected answer and current decision links.

The old citation still opened the source revision it had actually used. The record could teach the failure without pretending the answer remained valid.

That was more valuable than correcting the text in place.

Immutability did not forbid improvement

K81R could refresh retrieval, revise evidence, regenerate prose, rerun verification, accept corrections, and present a current answer. It simply represented each change as a new object or revision with relationships.

The cost was more state modelling and storage discipline. The benefit was that “What did the system know and do at this time?” remained answerable.

Generated language feels disposable during a chat and becomes consequential when cited, accepted, exported, or revisited. The transition deserves durable identity.

The answer record should not silently change because every improvement is also a claim about history. New knowledge can supersede the old answer without making it say something it never said.

Diffing prose highlighted word edits and could not explain why they changed. The revision comparison aligned claims by identity or declared replacement, showed added and removed evidence, changed authority, new gaps, verifier decisions, and destination state.

For the retry correction, it showed that “three retries” was removed, the current no-query adapter policy entered the evidence set, outcome-unknown became a supported claim, and the old answer moved to superseded. The prose diff became the surface of an evidence diff.

This made review faster and prevented stylistic rewriting from hiding a changed technical conclusion.

The schema separated intent, attempt, and artifact

One table called answers initially mixed the user's request, provider attempt, generated text, and review status. A retry overwrote provider fields and made the original outcome disappear.

I split durable identities:

• Answer intent: the requested task and evidence revision.
• Generation attempt: one external model request and outcome.
• Claim candidate: parsed output from one attempt.
• Answer revision: an ordered accepted set of claims and rendering.
• Review decision: judgment about one revision.

Several attempts could serve one intent. One answer revision could combine accepted claims only through explicit provenance. Unknown attempt outcome remained distinct from an invalid answer.

Source excerpts, evidence manifests, prompt artifacts, raw accepted claim text, and rendered answer revisions received canonical content digests. Loading an immutable record recomputed or verified the digest at trust boundaries.

The digest was not presented as a digital signature or proof of authorship. It detected accidental overwrite, mismatched export, and a citation opening content different from the stored source revision.

Canonicalization rules were versioned. A rendering-style change could produce a new display without changing claim content identity.

Concurrent review used expected revisions

Two tabs could annotate or accept the same answer. Review commands included the expected answer and review-state revision. A stale acceptance failed with the newer decisions and local annotation preserved.

Independent comments could be merged as separate records. Conflicting claim replacements required deliberate resolution. Last-write-wins was not acceptable for the state determining whether generated content entered a maintained document.

The answer lifecycle reused D4U7's durable decision model in a new context.

One answer could have a concise revision for the site and a detailed revision for technical review, both derived from the same evidence. I represented them as branches with a common parent rather than one overwriting the other.

Each branch carried task and destination scope. Claims reused only through explicit reference and retained support. Merging created a new revision with a diff and review.

Conversation interfaces tend to suggest one linear latest message. Maintained knowledge sometimes needs several intentional descendants.

Migrations preserved old semantics

As the answer schema gained claim objects and answerability records, early chat messages lacked those fields. A migration could not invent evidence links the old prototype never stored.

Legacy records remained labelled with their actual limits: opaque text, approximate source list, unknown prompt revision. Derived fields were added only when source logs established them. The UI did not show modern verification badges on migrated text.

Schema uniformity was less important than historical honesty.

Deleting a temporary answer draft could remove its unaccepted claims and short-lived attempt diagnostics. An answer accepted into a maintained decision had a different retention and lineage obligation. Source erasure could redact excerpts while preserving non-sensitive references and review history where policy allowed.

Database foreign keys alone could not express every lifecycle. A deletion planner enumerated dependent evidence sets, answers, exports, caches, and evaluation fixtures and produced a report.

The record graph made copies visible enough to govern.

A current-answer view was a projection

For convenience, K81R showed the latest accepted answer for one normalized question and scope. That view was derived from answer intent, supersession, current source state, access policy, and review.

It could disappear or point to a new revision without altering any underlying answer. Cache keys included scope and projection revision. Historical URLs always opened a specific immutable record.

This preserved a friendly interface while keeping “current” out of mutable answer rows.

I could ask:

• Which accepted answers depend on source revision 12?
• Which claims used prompt revision 7?
• Which answers were generated under index 18 and later superseded?
• Which review decisions referenced an automated support check now known to regress?
• Which exports contain a redacted source?

These queries made correction and impact analysis possible without scanning prose. They also revealed why stable IDs and relationships mattered more than a transcript blob.

The record could prove less than it contained

An exhaustive manifest might tempt a reader to conclude the answer was reproducible, correct, or authorized forever.

The provenance page stated its limits: external model behavior may not replay, automated support is fallible, current permissions may differ, source authority may have changed, and review applies to a named destination and time.

More metadata improved inspection. It did not upgrade the epistemic status of the content automatically.