Streaming valid operations, not raw tokens

V0M3's first streamed rewrite changed the document in front of me one token at a time.

The selected paragraph faded, replacement words appeared, and a citation marker arrived after the sentence. Halfway through, the stream ended inside a code fence. The canonical document had not committed anything, but the interface made unfinished output look like an edit already happening.

I replaced token streaming with operation streaming. The model could emit however its adapter required. The product revealed only a complete, validated proposal unit.

Transport events were not review events

A provider stream reported fragments, tool deltas, partial JSON, usage, and completion. None was inherently safe to show as document state.

V0M3's stream processor assembled candidate operations:

operation_start
operation_type
target
before_digest
proposed_content
evidence_ids
dependencies
reason
operation_end

Only operation_end created a validation candidate. Partial fields remained transport diagnostics.

The product stream began after the provider stream had produced something reviewable.

Before revealing a replacement, V0M3 checked that:

• Target document and revision matched the task.
• Block and span belonged to allowed write scope.
• Before digest matched the immutable target.
• Operation type was allowed.
• Range aligned with document structure.
• No previously accepted candidate overlapped incompatibly.

An operation targeting an unknown block never appeared as a ghost change in the editor.

Valid target did not mean current acceptability; document edits after task creation could still make the proposal stale.

Every generated factual claim referenced evidence IDs from the selected set. The application verified membership, current access, source revision, and exact spans before rendering links.

The operation card showed proposed text, claim markers, and evidence together. Automated semantic support could remain Review required. A source ID arriving later in the raw stream could not retroactively legitimize prose already displayed.

The unit of revelation included the context needed to judge it.

Proposed text was untrusted. V0M3 parsed the allowed Markdown-like subset only after the operation closed, escaped text, validated links, kept code inert, and rejected unknown elements.

The editor never rendered partial markup or provider-supplied HTML. Quotations came from exact source spans rather than model reconstruction. External URLs remained review candidates.

A structurally valid operation could fail rendering policy and stay in diagnostics instead of entering the review layer.

The document did not animate as though edited

Early UI overlaid each partial token directly on the source. The revised interface left canonical text stable and added operation cards or bounded inline previews after validation.

The author chose when to assemble selected operations into a whole-section preview. Until then, proposed text occupied a clearly provisional layer.

This reduced layout movement and automation pressure. Generation progress no longer looked like writing progress before review.

The model first proposed a structural plan: clarify definition, move limitation, shorten example, add evidence comment. The application validated task scope and expected operation slots without exposing private reasoning.

Complete operations then arrived in document order. Required slots and dependencies were known. An optional comment could fail without blocking a valid definition edit. A required replacement failure left the plan incomplete.

Progress could say “2 of 4 proposal operations ready” instead of displaying a typing simulation.

Preparation could be concurrent; review order stayed stable

Provider or application work could prepare several operations concurrently. V0M3 revealed them in target document order unless operations belonged to independent sections with stable headings.

An operation finishing early did not jump above an earlier paragraph and then move later. The review list reserved named slots from the plan. Failed slots displayed a bounded state.

Streaming UI repeated P6X4's old lesson: execution timing need not dictate reading order.

A transition operation depended on a heading move. It could render for inspection after validation and remained Not independently actionable until the dependency arrived.

If the dependency failed, the transition became blocked. The author could edit it into an independent proposal revision or reject it. Accept selected never included a dependency-incomplete operation.

The interface distinguished visible from actionable. Streaming an operation did not grant patch authority.

Claims could invalidate an operation after structure passed

Schema and target checks were fast. Claim-support assessment could identify contradiction or missing qualifier later.

V0M3 displayed states such as Structurally valid, Evidence check pending, Needs review, and Contradicted. For maintained technical prose, the configured policy could withhold the operation from Ready until support completed. For creative transitions, structural readiness could be enough.

One green check never stood for every validation layer.

Some streaming interfaces could revise earlier output. V0M3 never mutated a revealed operation in place.

A correction became operation revision two, linked to the first and shown as changed text, evidence, or target metadata. Previous review state did not transfer unless every approval-bound field was identical.

The author could compare or discard the old candidate. The visible record did not rewrite itself because the model reconsidered.

Partial output had a real state

If three operations validated and the provider failed during the fourth, V0M3 created a Partial proposal revision. Its task plan named the missing slot and whether the completed operations formed a coherent selectable set.

The author could review, accept an allowed independent subset, request bounded repair, or close the task. Required missing changes prevented misleading whole-section preview.

Partial did not mean corrupt. It meant the product knew exactly which proposal units existed.

A bounded repair attempt received task, target, evidence, plan, accepted candidate operations, and failure reason. It could produce the missing operation and not revise previous ones silently.

If repairing required changed evidence or target, V0M3 created a new task or proposal revision. The repair budget prevented endless provider calls.

Attempts and usage remained visible in diagnostics. A final successful operation did not erase earlier failure.

Cancellation closed the acceptance path

The author could cancel a generating task. The server marked it cancelled and requested provider cancellation where supported. Late operations could be retained for diagnostics but did not become actionable proposal state.

Restoring required an explicit command and current target review. Closing the browser alone did not prove the provider stopped.

The document remained unchanged throughout.

If the stream disconnected, the client reopened the durable proposal revision and operation sequence. Stable IDs prevented duplicate cards. Uncommitted partial provider events were not replayed as text.

The server could resume adapter streaming or reconcile attempt outcome according to provider capability. The interface showed what had been validated, what remained pending, and what was unknown.

The stream was delivery over state, not the only record of state.

Backpressure had product limits

A provider could emit faster than parsing, validation, or the reader could consume. The processor bounded buffered bytes, record size, operation count, changed words, and validation concurrency.

Exceeding task review budget stopped or closed the proposal as Needs decomposition. V0M3 did not buffer an unbounded whole-document rewrite because the provider kept talking.

Resource limits and human attention limits met in the same protocol.

Screen readers did not receive token-by-token announcements. A polite status announced when a complete operation became available. Operation cards had headings, target labels, change type, evidence state, and keyboard navigation.

Focus stayed on the document or current review card. New operations never stole it or forced scroll. Reduced-motion mode used no streaming animation; the default used only subtle insertion.

The proposal unfolded like a review queue, not a live transcript.

Performance milestones changed

I measured:

• Provider request accepted.
• First raw event.
• First complete operation record.
• First target- and schema-valid operation.
• First evidence-linked reviewable operation.
• Coherent proposal subset ready.
• Complete proposal and verification.

Time to first raw token remained diagnostic. The product optimized first reviewable operation and time to coherent selectable patch.

A slightly later stable card was more valuable than immediate unfinished text.

The fixture streamed a replacement sentence, delayed its citation, revised a qualifier, and terminated inside a code fence. Assertions required that none of the partial text entered the review layer.

Another fixture emitted a valid operation against an unauthorized target and a well-formed link with an unsafe protocol. Both stayed invisible outside a safe failure summary.

The sequence mattered. A final clean screenshot could not prove that wrong prose had never flashed earlier.

Final preview used the same operations

After streaming completed, V0M3 assembled the proposal preview from committed operation records and normalized dependency plan. Reload, export of review material, and acceptance used the same objects.

There was no second interpretation of raw output that might differ from what the author reviewed. Any editorial revision created a new proposal record and diff.

The stream and final review were two views of one product state.

The raw stream had been visually active and epistemically delayed. Operation streaming showed less motion and more progress.

The author could inspect the first validated edit while generation continued. Canonical text stayed stable. Claims arrived with evidence. Invalid output did not need to be retracted from view. Partial completion remained useful.

Streaming valid operations preserved the benefit of progressive output without asking a person to review unfinished transport.

The stream became quieter, later, and substantially more honest about what existed.

Only reviewable work entered view.

The old and new interfaces received the same provider events. The token view displayed unsupported prose at 420 milliseconds, changed its qualifier at 810, attached evidence at 1,140, and broke markup at 1,600. The operation view showed the evidence set immediately and its first complete validated edit at 1,210. Nothing required retraction.

The comparison did not claim a universal perception threshold. It demonstrated that the faster first event had produced a slower trustworthy state. Reviewers found the planted unsupported claim more consistently when it appeared as one operation with evidence than inside the moving section.

Completion no longer meant silence

The provider stream ending did not prove the proposal complete. V0M3 verified required plan slots, operation graph, evidence checks, usage record, and attempt outcome before marking Complete. A closed transport with a missing required operation became Partial or Failed, not a deceptively quiet ready state.

Conversely, a proposal could become coherently reviewable before the provider emitted optional explanation or usage trailers. Product completion followed the artifact contract rather than socket closure.

This final distinction made streaming an implementation of the workflow, not the workflow itself.

The plan listed intended product units, targets, required evidence categories, and dependencies. It did not ask the model to reveal private reasoning tokens or present them as an explanation of correctness.

Reasons remained concise review aids attached to operations. The system evaluated outputs and evidence rather than treating a long reasoning transcript as assurance.

This kept progress informative without manufacturing authority from internal narration.

Source revocation stopped commitment

A source could become inaccessible after an operation first validated. V0M3 rechecked evidence access before marking it Ready and again at acceptance.

If revocation occurred while buffered, the operation never appeared with the hidden citation. If it occurred after review, the operation became stale and prior approval expired. Disclosure-safe UI said required evidence was no longer available without exposing its content.

The commitment boundary used current policy, not the stream's starting assumptions.

While operations streamed, the author could continue writing. V0M3 compared each completed target with current document lineage. An operation against an untouched block stayed current; an overlapping one became stale; a deleted target closed.

The review queue did not discard every operation because one paragraph changed. Final acceptance still created a proposal revision against one current document state and revalidated the selected set together.

Granular streaming enabled granular conflict without fragmented document commits.

Usage and discarded output were measured

Provider usage occurred before an operation passed validation. V0M3 recorded tokens or provider units generated, buffered, discarded, repaired, and accepted where the adapter supplied them.

A provider that reached first token quickly and produced many invalid operations could be slower and more expensive to a reviewable patch. Evaluation compared first valid operation, valid-operation rate, repair rate, and accepted-change yield.

The product did not hide failed work behind a smooth progressive interface.

Structural, target, access, and rendering checks ran before every reveal. Semantic support checks could take longer. A stylistic proposal could appear as structurally reviewable while support was irrelevant; a current technical claim could wait for evidence assessment.

Task policy defined the minimum state for visibility and for action separately. Labels explained pending review without flashing unsupported text as accepted truth.

This prevented the most conservative workflow from making every creative edit slow and the fastest workflow from making technical claims unsafe.

Alternative providers created parallel lanes

When the author requested two alternatives, each provider or attempt streamed into a separate proposal branch with its own plan and operations. Cards never interleaved into one patch.

The comparison aligned operations by target and task intent after each became valid. Choosing one created a reviewed branch; combining them required a new normalized proposal revision.

Parallel generation did not imply shared authorship or compatible operations.

The parser handled truncated UTF-8, duplicated record starts, unknown fields, out-of-order IDs, oversized strings, missing terminators, and late events after completion. It never guessed by extracting JSON-looking fragments from arbitrary prose.

A bounded adapter repair could transform provider-specific framing into the product schema. The untrusted payload remained separate from document operations.

Fuzz and fixture tests treated the stream processor as a protocol parser, not a convenient UI helper.

Operations carried source and output digests

Each completed operation stored the raw candidate digest, normalized operation digest, and rendered review digest. This detected accidental transformation between provider response, validator, UI, and acceptance.

Digests were integrity evidence, not signatures or correctness proofs. Normalization rules were versioned. Editing a proposal produced a new digest and review state.

The author accepted the exact normalized content shown in the review.

Opening an in-progress proposal could server-render already committed operations and then subscribe for later sequence numbers. The client ignored duplicates and requested a snapshot when a gap appeared.

Optional live updates could fail while the page remained useful. Refresh reconstructed current state. The proposal did not depend on one WebSocket or component instance to exist.

This made progressive operations compatible with V0M3's server-first route architecture.

Copying provisional text preserved its status

The author could copy a proposed operation for comparison. Clipboard plain text remained portable. Within V0M3, optional structured metadata identified proposal revision and provisional state.

Pasting into the canonical editor did not accept the operation automatically. It became an authored edit unless the author used the explicit acceptance command. The product never inferred authority from clipboard origin.

Convenience could not bypass the document boundary.

Generated operations often arrived with confident reasons or large changes that drew attention. The queue ordered by document structure and task plan, not model confidence or provider completion time.

Unsupported claims, deletions, and scope changes received visible review indicators without automatically rising above the author's current location. Filters could show high-consequence changes deliberately.

The interface avoided turning the model's own certainty into editorial priority.

The protocol supported no-stream adapters

A provider that returned one complete response could pass it through the same operation compiler and commit valid operations in sequence. V0M3's product model did not require token streaming.

Streaming-capable adapters improved time to first reviewable operation. Non-streaming adapters remained compatible and honest about their progress. Provider selection could weigh quality, privacy, cost, and context rather than treating stream support as mandatory intelligence.

Transport capability stayed behind a stable proposal contract. The review model stayed provider-agnostic throughout.