A model output is not product state

V0M3's earliest prototype had one important database field: generated_text.

I selected source material, described the intended section, called a model, and put the response in an editor. From there I could revise or export it. The demonstration proved that text generation worked.

The application could not answer whether a claim had evidence, which source revision had been used, whether I had approved the current wording, whether a later run had overwritten an edit, or whether the paragraph belonged to the document at all.

I had stored output and omitted state.

Text did not describe its own status

The same paragraph could be:

• An unreviewed model proposal.
• A proposal whose source IDs were valid.
• A proposal with claim support still under review.
• A human-edited alternative.
• Text accepted into a canonical document revision.
• Accepted text whose evidence later became stale.
• Rejected text retained as an evaluation fixture.

Putting each in one editor made them visually identical. A badge called Approved would remain ambiguous: which wording, evidence, task, policy, and revision did it approve?

Status had to bind to exact artifacts.

The document and proposal were separate state machines

The canonical document moved through authored revisions. A proposal moved through:

requested
  → generating
  → structurally-invalid | proposal-ready
  → evidence-review
  → review-ready
  → accepted | rejected | stale | cancelled

Acceptance created a document revision and closed the proposal's write opportunity. It did not turn the proposal row into the document.

The document could continue changing while generation ran. A stale proposal remained inspectable and non-actionable until reviewed rebase.

Two state machines expressed two authorities.

A task defined target document revision, write scope, read context, evidence set, operation constraints, and output policy. That was the generation intent.

Calling a provider created an attempt. A timeout, malformed response, or adapter failure could lead to another attempt under policy. All attempts belonged to the same intent and never expanded it.

The first schema had overwritten generated_text on retry. V0M3 instead recorded every attempt outcome and selected accepted candidate claims through explicit proposal revisions.

Z29C's intent-versus-attempt distinction protected generative work from transport history.

Model output was untrusted input

Structured generation reduced parsing ambiguity and did not create trust. A valid operation object could contain:

• An evidence ID outside the selected set.
• A target block the task could not modify.
• Unsafe markup or URL.
• A duplicated or contradictory claim.
• Text beyond size and review budgets.
• A request to invoke a capability not granted.
• A well-formed patch against a stale revision.

The proposal compiler validated schema, scope, target, source membership, rendering, limits, and dependency graph before creating reviewable product state.

The model could propose a transition and could never authorize one.

The first system retried malformed output invisibly until something parsed. This hid failure frequency and spent resources without improving the task evidence.

V0M3 recorded the failed attempt, violated constraints, safe diagnostic excerpt, provider and prompt revision, and whether bounded repair was allowed. A repair request used the same immutable task and named the structural failure. It could not add sources or change targets.

After the repair budget, the task returned to the author with its evidence intact. Manual writing remained available.

Failure improved evaluation instead of disappearing behind a successful retry.

Claims were product objects

A proposal operation could contain prose and claim candidates. Claims stored:

claim_id
text
entity_and_qualifiers
evidence_edges
claim_type
support_state
proposal_revision
target_span

The prose renderer remained natural. Selecting a claim opened exact sources, contradictions, inference, and review state. Compound claims could split; reworded claims could preserve lineage only through explicit mapping.

A bibliography attached to the section was no longer mistaken for sentence-level support.

The application checked that every source reference belonged to the authorized evidence-set revision and opened the exact immutable passage. This prevented invented citations.

A real passage could still fail to support the claim. Automated and human verification labelled supports, contradicts, contextualizes, mentions, or insufficient. Numerical and identity checks ran deterministically where possible.

The proposal could become structurally valid while support remained under review.

One green parse result did not collapse these stages.

Answerability happened before drafting

V0M3 reused K81R's evidence coverage model. The task mapped required entities, conditions, authority, time, and scope to selected sources.

If a current technical rewrite lacked current policy or needed an inaccessible source, generation could stop with a useful gap instead of producing attractive language. For an explicitly creative transition task, evidence requirements were smaller.

The task type determined allowed claims and refusal. The model did not decide its own evidentiary burden.

Generation became optional after the product knew what the evidence could support.

Every task referenced an immutable document revision and exact blocks or ranges it could change. Read-only surrounding context could be broader.

If the current document changed, the proposal became stale. Exact unchanged targets could be rebased under review; overlapping edits required a three-way comparison. Deleting the target disabled acceptance instead of letting a late proposal recreate it.

The model output never floated above the document waiting for the nearest similar paragraph.

Revision binding made asynchronous assistance safe enough to coexist with writing.

Whole-section replacement hid many decisions. V0M3 used insert, replace, delete, move, heading, and comment operations with targets, before digests, reasons, evidence, and dependencies.

The author could accept a definition edit, reject an unsupported causal claim, keep a paragraph the model considered repetitive, and edit a transition. The normalized selected plan committed atomically as one document revision.

Review granularity made human ownership concrete without requiring token-level attribution.

Review was state, not a disclaimer

“AI can make mistakes” below the editor said nothing about this proposal. V0M3 stored distinct receipts:

• Structural validation.
• Evidence-set integrity.
• Claim-support assessment.
• Accessibility or document-structure checks.
• Authenticated author review.
• Exact patch acceptance.

Each receipt named artifact revisions and policy. Changing proposal text, evidence, target, or selected operations invalidated relevant receipts.

Review status followed the thing reviewed.

The acceptance command covered document revision, proposal revision, normalized selected patch, evidence revision, policy revision, review receipts, and stable request ID.

The server recomputed digests, loaded current authority, and rejected changed preconditions. A confirmation from yesterday did not approve a rebased patch today.

If the response was lost after commit, retry returned the existing receipt. Acceptance could not apply twice.

Approval became a durable decision under exact world state, not a button click detached from its arguments.

React Actions and optimistic UI could present submission cleanly. Their pending flag described one invocation. It did not prove document acceptance, evidence freshness, provider completion, or external export.

The client displayed a provisional state and then rendered durable command outcome. Reloading reconstructed from server records.

This distinction let frontend ergonomics improve without moving authority into a component lifecycle.

Human edits were not overwritten context

The early Regenerate button sent the current document to the model and replaced it with the response. Omitted human changes were difficult to detect.

V0M3 treated human edits as canonical revisions. A later task could propose bounded operations against them. It never received permission to restate the entire document unless a deliberate full-review workflow granted that scope.

Accepted model text became ordinary document text and could evolve through future human edits. Provenance followed descendants without freezing them.

The model collaborated through patches, not silent ownership.

A proposal could be factually supported and editorially wrong for the document. It might flatten voice, repeat an earlier section, overexplain, or solve the wrong problem.

The author could reject with “prefer original” and no machine-verifiable defect. Rejection closed the proposal's acceptance path, preserved bounded history, and did not train or punish a provider automatically.

The system protected the right to make a craft decision beyond its metrics.

An accepted document revision remained historically approved after a source became superseded. It no longer counted as current guidance automatically.

The evidence graph found dependent claims and marked currentness Needs review. A refresh task could select replacement evidence, narrow a claim, preserve the historical statement, or reveal real change.

V0M3 never rewrote approved prose because the index updated. Freshness and approval were independent axes.

The document could tell the truth about what was accepted then and what is supported now.

Access flowed into output scope

A model proposal derived from restricted evidence could not be accepted into a public destination by hiding the citation. Claims inherited their evidence's output-scope ceiling.

Acceptance and export validated destination scope. A public version needed independently public evidence or different prose. Current source authorization was checked again at review and viewing.

The generation worker saw only the evidence manifest and held no broad corpus credential.

Information flow remained a system policy, not a prompt request.

V0M3's 2024 work began to evaluate tool-connected providers, but the core drafter needed no document write tool. Retrieval occurred through K81R before generation. Proposal creation used a typed output channel.

If a task gained a source lookup or formatter capability, the orchestrator supplied one scoped adapter and validated every call under current policy. A tool schema did not grant permission; server authority did.

Roles named operations—finder, drafter, critic, formatter—without pretending personalities created security boundaries.

A provider timeout might happen after it accepted or completed a generation. Adapter capability declared idempotency, status lookup, cancellation, streaming, and usage evidence.

V0M3 recorded stable generation intent, provider attempt ID, request digest, response digest, and outcome. Unknown outcomes did not trigger blind repeat. A new attempt required policy and linked to the same task.

Generation was not magically side-effect-free because its result was text. It consumed resources and could produce duplicate candidates.

Z29C's protocol reappeared at a more demanding boundary.

Provider adapters preserved differences

V0M3 normalized only the needs its product actually shared: bounded evidence input, structured proposal output, attempt state, usage, and safe diagnostics.

Providers could differ in context limits, output guarantees, streaming, tool interfaces, retention settings, cancellation, and resume support. The adapter contract exposed those capabilities rather than flattening them into one imaginary model.

Task policy selected a compatible adapter. A provider with more features did not gain more document authority.

V0M3 buffered complete operation and claim records, validated them, and revealed stable review units. Source links and status arrived with the text they described.

The evidence set was visible while generation ran, so delaying prose did not leave an empty page. A reader could inspect early operations without chasing a moving sentence.

Time to first valid operation mattered more than time to first token.

The stream delivered product state; it did not define it.

Undo created another revision

Accepting a patch was reversible in document history. Undo produced an inverse proposal against current state, showed overlap with later edits, and committed another revision when approved.

It did not erase the original proposal, acceptance, or external exports. If the document had already been shared, correction required a new artifact.

Reversibility remained honest about the boundary of the document database.

The canonical document exported to ordinary Markdown with normal citations. An optional sidecar contained proposal, claim, evidence, and revision lineage.

If providers, model access, or V0M3 disappeared, the text remained readable and editable. Unaccepted proposals were not required to reconstruct the current document.

The assistant participated in creation without becoming the artifact's runtime dependency.

Observability followed the workflow

The operational view answered:

• Oldest generation intent without known attempt outcome.
• Proposal revisions failing structural validation.
• Evidence-review queues and stale accepted claims.
• Acceptance conflicts and duplicate request receipts.
• Provider latency, usage, and repair attempts by adapter.
• Exports depending on later-superseded claims.

It did not call the system healthy because the model endpoint returned text.

Product state gave infrastructure evidence a reason.

V0M3 measured corpus fidelity, retrieval, evidence coverage, generation, and verification independently, then ran end-to-end temporal scenarios.

The benchmark included exact IDs, stale sources, missing answers, unsupported citations, changed targets, restricted evidence, provider timeouts, malformed operations, and human rejection of a technically valid paragraph.

One answer-quality score could not hide a permission leak or unreviewable patch.

Evaluation mapped a failure to the system capable of changing it.

Disabling providers removed generation actions. Documents, manual editing, revisions, evidence review, citations, accepted history, export, and search of canonical work remained.

Proposal records stayed inspectable. Manual patches used the same document acceptance rules where relevant. The product degraded from assisted writing to writing, not from application to empty chat shell.

This was the strongest evidence that generated output had never become product authority.

The important transition was not a model call

V0M3's actual workflow was:

document revision + task + evidence
→ generation intent
→ provider attempt
→ validated proposal operations
→ evidence and editorial review
→ exact acceptance command
→ new canonical document revision

The model operated in the middle. Product commitments happened around it.

A model output is not product state because text alone cannot say what it targets, what supports it, who reviewed it, whether it is current, or whether it belongs in the document. The engineering begins when the candidate enters a system capable of answering those questions.

V0M3 could verify identities, revisions, schemas, access, and some claim relationships. It could not prove prose quality, source truth, reviewer care, or model correctness in every case. Automated support assessment remained fallible. Imported documents could have incomplete lineage. External providers could change behavior.

The interface and case study named those limits. Strong state did not turn an invented personal archive into independent fact, and a reviewed proposal did not become objectively perfect writing.

The system made decisions inspectable enough for responsible judgment; it did not automate judgment out of existence.

Complexity had an exit test

Each state existed because a scenario required it. Remove target revision and a late proposal could overwrite new text. Remove evidence set and claim support became irreproducible. Remove attempt identity and timeout retry could duplicate work. Remove acceptance receipt and a lost response could apply twice. Remove document revision and undo could erase later edits.

I kept this mapping beside the schema. If a future simplification preserved every scenario with fewer states, it would be an improvement. The model was not allowed to become ceremony simply because this article described it in detail.

The most satisfying V0M3 run did not produce a complete section autonomously. It proposed four bounded improvements, exposed one evidence gap, accepted two edited operations, and left the original document readable throughout.

That looked less dramatic than replacing an editor with generated prose. It solved the harder problem: assistance could contribute without making authorship, evidence, and recovery ambiguous.

Product state gave the model a useful place that stopped short of ownership.

The final comparison disabled the provider halfway through the scenario. Every canonical revision, evidence relationship, review decision, conflict, export, and recovery receipt remained available. Only the creation of new proposals disappeared. Re-enabling a compatible adapter resumed from immutable tasks without reinterpreting old document state. That failure mode made the boundary undeniable: model output was one input to V0M3, while product state was the durable system the writing depended on.

V0M3 did not keep one giant JSON document containing every stage. Separate authoritative records represented document revisions, tasks, evidence sets, generation intents, provider attempts, proposal revisions, operations, claims, validation results, review receipts, acceptance commands, and exports.

Foreign keys and content digests preserved relationships. Append-only decision records fed current-state projections for the editor. A projection could rebuild without becoming authority.

The schema looked more complex than generated_text and made deletion, recovery, conflict, and audit possible without parsing old chat messages.

Invariants were executable

The document service enforced:

• One canonical child revision per accepted command result.
• A proposal never updates document content directly.
• Accepted operations belong to one proposal and target revision.
• Review receipts match exact patch and policy.
• Claims cannot cite evidence outside the admitted set.
• A stale or cancelled proposal cannot be accepted.
• Reusing request identity with different digest fails.

Property and scenario tests interrupted transitions and replayed commands. The state machine was not only a diagram in the case study.

If a worker crashed after provider response, the attempt record and raw bounded response could resume proposal compilation. If it crashed after proposal commit, the review queue discovered the proposal. If acceptance committed before response loss, request lookup returned the receipt.

The recovery console showed task, target, evidence, attempt, proposal, and document state. It never began with a generic Retry button.

Every stage had its own safe recovery because every stage had identity.

Two tabs could edit the document and review proposals. Expected revision protected acceptance. Ordinary document edits used their own operation IDs and revision protocol. Non-overlapping local drafts could rebase; overlapping changes required review.

The model's proposal received no priority merely because it took longer to produce. A human edit could make it stale and remain canonical.

This prevented asynchronous assistance from becoming a last-writer with unusually fluent output.

Policy changes were state changes

Review requirements, allowed providers, source scopes, destination visibility, and operation limits evolved. Every task and acceptance named a policy revision.

Current policy revalidated consequential transitions. A proposal created under an older, looser rule could require new evidence review or become unacceptable. Historical records retained the earlier context.

Configuration was not a hidden ambient variable when it changed what the product allowed.

The internal model had many precise states. The writer saw a smaller vocabulary: Drafting, Proposal ready, Needs evidence, Needs review, Stale, Accepted, Rejected, and Generation interrupted.

Details explained target, source, or attempt status on demand. Internal distinctions such as provider outcome-unknown appeared only when they changed available recovery.

Good state modelling supported simpler language rather than forcing database enums into every label.

The anchor scenario crossed the whole system

The verification fixture selected evidence, started a section task, changed the target during generation, received a stale operation, rebased an unaffected part, rejected one unsupported claim, edited another for voice, accepted the exact patch, lost the response, recovered the receipt, superseded one source, reviewed the affected claim, and exported Markdown with a provenance sidecar.

At no point did raw model text become canonical accidentally. Every transition remained explainable after restart.

The scenario was the project-level breakthrough: generation quality mattered, and workflow integrity determined whether quality could be used safely.

I expect model connections to become more standardized and therefore much easier to multiply. That convenience will move the bottleneck. Discovering a tool and validating its argument shape will not establish whether the caller may use it, whether the action is reversible, or whether a timeout concealed a completed effect. V0M3 keeps those semantics in the product because a future connector protocol should be able to improve transport without silently inheriting authority.