A task needs a target revision

V0M3 generated a careful replacement for paragraph twelve and applied it to paragraph thirteen.

The document had changed while the model worked. I inserted a paragraph near the beginning, shifting every later character offset. The proposal still targeted start: 1842, end: 2210. Those numbers now described different text.

A text editor could detect that the patch no longer applied cleanly. The product needed a stronger rule: the task itself must name the document revision it understood.

The task captured a source snapshot

Creating assistance stored:

• Document ID and immutable target revision.
• Stable block and source-range identities.
• Exact selected text and content digest.
• Surrounding authored structure needed for the task.
• Evidence-set revision.
• Requested operation types and constraints.
• Author and output scope.

The model received that snapshot, not a live document reference. Its proposal could be evaluated against exactly what it saw.

The current document could continue changing independently.

Offsets were locations, not identities

Character offsets were useful inside one immutable revision. They did not survive an insertion before the target.

V0M3 represented documents as stable authored blocks. A target included block ID, revision, local range, selected-text digest, and structural path. Unchanged blocks could be found across later revisions through lineage. Split, merged, or substantially rewritten blocks produced explicit mappings or no mapping.

I did not use fuzzy text matching as silent authority. Similar prose elsewhere in the document could make the wrong range appear plausible.

Stable identity narrowed rebase candidates; current content still had to validate.

Generation ran against immutable input

The model adapter received a task manifest and content-addressed target representation. If the user edited the current document, the generation request did not change beneath the provider.

This improved reproducibility and failure diagnosis. A proposal's wording could vary between attempts, but the task, target, evidence, and constraints remained fixed.

A task revision was required to change any input. The interface did not update context silently in an in-flight prompt.

The model could finish what it had been asked even when the answer was now stale.

When generation returned, V0M3 compared target revision with current document. If they differed, the proposal became Stale before Accept was available.

The page showed:

• Original target text.
• Current descendant text, if one could be identified.
• Proposed operations.
• Intervening document changes.
• Evidence or policy changes since task creation.

Stale did not mean the proposal was bad. It meant the acceptance preconditions no longer held.

The author could inspect and decide without a race becoming a generic error.

Rebase was a reviewed transformation

For an unchanged target block moved elsewhere, V0M3 could propose a mechanical rebase. The before digest and block lineage proved the content was identical. The author confirmed the new structural context still made sense.

For non-overlapping edits inside the same section, a three-way merge produced a candidate patch:

base: target revision
current: latest document
proposal: base + generated operations

Conflicts remained explicit. V0M3 never asked a model to resolve them and apply the result in one hidden step.

Rebase created a new proposal revision against the current document.

Semantic context could change without text overlap

A target paragraph might remain byte-identical while a new preceding paragraph changed its purpose or made the proposal redundant.

V0M3 tracked structural context: heading lineage, neighboring block identities, section claim map, and task constraints. A context change marked the rebase as needing editorial review even when the patch applied mechanically.

This prevented clean diff application from becoming proof that the edit still belonged.

Text merge and writing judgment stayed separate.

Evidence could become stale too

The document was not the only moving input. A selected source could gain a new revision, become superseded, or lose access. The evidence set remained immutable, and its currentness status changed.

Acceptance revalidated evidence required by each operation. A proposal based on historical evidence could still be accepted into a historical passage if labelled appropriately. A current technical claim needed current support under policy.

Refreshing evidence created a new task or proposal revision. The old model output did not silently inherit sources it had never seen.

The review receipt covered target document revision, exact selected operations, proposed text, evidence revision, validation results, policy revision, and patch digest.

Rebasing, editing a proposal, changing an operation selection, or updating evidence invalidated prior approval. The author reviewed the new exact patch.

An approval token expired and could be used only for the named document command. It did not mean “apply something like this when convenient.”

The server recomputed every digest before commit.

Acceptance used optimistic concurrency

The document service accepted the command only if the expected current revision matched. The transaction applied the validated patch, appended lineage, and created a new document revision.

If another tab committed first, acceptance returned a conflict with the intervening revision. It did not overwrite or retry against the new document automatically.

The same request ID returned the existing receipt after a lost response, preventing duplicate patches.

Concurrency control made author authority durable across browsers and workers.

Long model latency became manageable

Generation could take seconds or fail and resume. Locking the document during that time would make assistance hostile to ordinary writing.

Immutable targets allowed the author to continue. A short proposal often rebased cleanly; a large one became stale more often, which was useful pressure toward smaller tasks.

The interface showed which pending tasks targeted the current revision and which were likely to need review after edits. It never told the author to stop writing while a model thought.

Asynchrony remained outside canonical state until acceptance.

The author might request a clarity rewrite and an evidence review for the same paragraph. Both referenced the same document revision and could finish independently.

Accepting one changed the current document and made the other's patch stale. Comments whose target mapping remained valid could rebase; replacement text required comparison. V0M3 did not order completion by provider speed.

Task priority and mutual exclusion were visible in the review queue. The author could cancel redundant work or combine it in a new task.

Concurrency created alternatives, not last-result-wins editing.

Cancellation did not erase a provider attempt

Cancelling a task stopped future acceptance and asked the adapter to cancel if supported. A provider might already have completed or might still return output.

Late output stayed attached to the cancelled task and could not become an actionable proposal without an explicit restore under policy. Usage and attempt outcome remained recorded.

The document never inferred that a closed dialog had cancelled external computation.

Z29C's unknown-outcome model applied to generation again.

Target size affected review and staleness

Whole-document targets became stale after almost any edit and produced overwhelming diffs. V0M3 encouraged the smallest region that contained the writing problem and necessary context.

The task could read broader context than it was permitted to modify. Read context and write target were separate fields. A model might see the whole section for coherence and propose operations only inside two blocks.

This was least privilege applied to text editing.

Narrow targets reduced accidental change without starving generation of context.

Moving a paragraph involved source block, destination block or section, ordering relationship, and document revision. A numeric “insert at index 7” was fragile.

The proposal said “move block B after block A under heading H in revision 12,” with before digests and structural constraints. Acceptance validated that A, B, and H remained compatible.

If another edit moved A, the operation could remain meaningful through identity. If H changed purpose, review was required.

Structured operations made intent more durable than offsets while preserving conflict.

A review comment about an unsupported claim might remain relevant after the sentence moved or changed slightly. V0M3 attached comments to claim or block identities and showed possible descendants.

Automatic reattachment required exact lineage and displayed confidence. Ambiguous comments became Orphaned and waited for manual placement; they did not attach to similar wording elsewhere.

The system treated feedback and mutation differently because their consequences differed.

Exports named one revision

An export started from a specific canonical document revision. Pending tasks and proposals targeting it remained outside the artifact. Accepting a proposal later produced another revision and did not mutate the completed export.

The optional provenance sidecar listed accepted proposal lineage present in the exported revision. Stale or rejected tasks were absent from reader-facing content and remained in review history.

Revision identity kept writing, assistance, and distribution from collapsing into one moving “latest” document.

The test interrupted every boundary

The scenario suite:

1. Started a task on revision 10.
2. Edited a different section into revision 11.
3. Edited the target into revision 12.
4. Returned the proposal.
5. Attempted stale acceptance and expected refusal.
6. Rebasing produced a three-way conflict.
7. The author adapted one operation into revision 13.
8. A lost acceptance response retried with the same request ID.
9. The document contained the patch exactly once.

Another scenario changed only a later unrelated block and exercised safe reviewed rebase.

Before target revisions, a prompt referred to “the selected paragraph” as though selection remained stable while the world changed. Afterward, every task could answer:

• Which document state did the model see?
• Which region could it modify?
• Which broader context informed it?
• Which evidence and policy applied?
• What changed before acceptance?
• Who decided how to reconcile that change?

The model could take time because its authority did not expand with time.

A task needs a target revision because useful assistance is still a proposal about one specific state. Applying it to another state requires a new, reviewable decision.

The final scenario rewarded continued writing

The author started three bounded tasks, then revised the document normally. One proposal targeted an untouched block and rebased with an exact lineage check. One overlapped a manual edit and opened a three-way review. One targeted a deleted paragraph and closed without action. Completion order changed nothing.

The model work remained useful where its preconditions survived and harmless where they did not. No document lock, last-result-wins merge, or invisible prompt refresh was necessary.

That was the practical benefit of revision binding: asynchronous assistance could coexist with authorship instead of asking the author to pause until every proposal returned.

Targeting made cancellation cheap

If the document moved in another direction, the author could close every task on revision 10 and continue. Their proposals remained review history under policy and had no latent write capability.

The system did not need to hunt through the current document for text a cancelled model might have inserted. Because proposals had never crossed the acceptance boundary, abandoning them was a state transition rather than a repair.

Each revision had a monotonic document sequence and a content digest. The sequence explained history; the digest detected accidental mutation or a patch computed against different bytes. Parent links supported ordinary linear editing and explicit branches where review needed alternatives.

The target stored both sequence and digest. A restored database or imported document could not satisfy the task merely by reusing revision number 12 with different content.

Digests were integrity checks, not signatures or proof of who authored the text. Authenticated revision receipts carried that separate decision evidence.

Offline drafts introduced another state

An author could edit locally while disconnected. The browser held operations based on accepted revision 10, while the server might have advanced to 11. A task created offline could not be submitted as though 10 were current.

V0M3 preserved the local draft, synchronized it through the ordinary revision-conflict protocol, and created assistance only after the draft had an accepted target or an explicitly local disposable mode. Model output from a local-only task could not reach canonical acceptance until both draft and proposal were reconciled.

This prevented server generation from legitimizing an unaccepted document state accidentally.

The task often needed neighboring paragraphs, section headings, terminology, and a style reference beyond the editable range. Every context unit appeared in an input manifest with purpose: target, read-only context, evidence, glossary, or instruction.

The model could propose operations only against target IDs. Text from read-only context was available for coherence and could not become an implicit second write target.

The visible manifest helped the author spot unnecessary private context and reduced both token cost and injection surface.

Lineage mappings could be wrong

Automatic block lineage used retained IDs for direct edits and explicit structural operations for moves or splits. Imports or external edits sometimes forced text-based similarity.

Similarity produced candidates, never authoritative mapping. The review view showed old and new blocks, score, structural location, and competing matches. The author confirmed a relationship or declared the target gone.

An uncertain lineage could not enable acceptance. Convenience in finding the likely paragraph did not become permission to edit it.

If the author removed the target paragraph intentionally, a late rewrite should not recreate it by default.

V0M3 marked the proposal Target deleted and disabled rebase. The author could open its text, copy an idea manually, or create a new insertion task against the current revision. That new task made resurrection explicit.

This protected negative document decisions. Absence was state, not a merge conflict waiting for generated content to win.

Review requirements, destination scope, provider allowance, or evidence rules could change while generation ran. The task retained the policy revision under which it was created; acceptance evaluated current policy too.

If requirements tightened, the proposal gained missing checks or became unacceptable. If they loosened, an old proposal did not self-approve; the author still reviewed it. Policy comparison explained the changed action state.

Time altered more than document text, so preconditions extended beyond a revision number.

A provider retry kept the same target

When an attempt failed safely and policy allowed retry, the new attempt used the identical task revision. It did not reload current document content under the old task ID.

If the author wanted current text, V0M3 created a new task revision with a diff from the prior target. Outputs from both remained comparable and could not be applied interchangeably.

This removed a subtle reproducibility bug where “retry” actually meant “ask a different question about a newer document.”

Task templates had compatibility versions

A task type such as preserve-claims rewrite specified required inputs, allowed operations, output schema, and review policy. Updating the template did not reinterpret in-flight tasks.

The task referenced a content-addressed template revision. A later retry under the same task used it; adopting the improved template created a new task revision. Evaluation could compare outputs without hidden instruction drift.

The target revision named document state, and the task-template revision named requested behavior. Both belonged to provenance.

Pending tasks displayed their target revision and how many document revisions had occurred since. A proposal did not flash red merely because it was old. It explained whether changes touched the target, context, evidence, or policy.

An unchanged target five revisions later could need modest review. A one-minute-old proposal against a rewritten sentence was stale. Structural impact mattered more than elapsed clock time.

This kept the queue calm and directed attention to actual precondition changes.

Review history kept failed rebase attempts

Trying to rebase could reveal conflicts and lead the author to reject the proposal. V0M3 stored the attempted mapping and conflict explanation as review evidence without creating a proposal revision that looked valid.

This helped diagnose recurring task sizes or unstable sections. It also prevented another tab from repeating the same automatic rebase and presenting it as new.

The history was retained proportionally and could be minimized after the task closed.