Approval must bind to the exact patch

I approved three V0M3 operations. The server applied four.

The proposal had regenerated one failed transition after I opened review. The client selection still referred to “all valid operations,” and that set now included the new one. The final patch was coherent, small, and not the patch I had inspected.

Approval had bound to a category of future state instead of exact state.

I changed acceptance so every approval named the precise patch and preconditions it authorized.

Approval was an object

V0M3 stored a review receipt containing:

• Reviewer identity and authority.
• Document and exact target revision.
• Proposal and proposal revision.
• Ordered selected operation IDs.
• Normalized patch digest.
• Evidence-set and validation revisions.
• Policy revision.
• Relevant output and destination scope.
• Expiry and single-purpose command capability.
• Created time and review UI version.

The server constructed the receipt from canonical records after the reviewer selected operations. The client could not submit approved=true.

The digest included operation type, target identity, before digest, proposed content, dependency graph, citation effects, evidence references, and normalized execution order.

Generated reasons and display-only layout were excluded unless policy made them review-critical. Changing a word, source, target, selected operation, or dependency created a different digest.

Canonicalization was versioned. The server recomputed it at acceptance.

The digest detected mismatch and did not prove the patch was good.

Before confirmation, V0M3 showed a deterministic summary:

Accept 3 operations: 2 replacements and 1 move. 86 words changed. No deletions. One new supported claim. Target document revision 17.

Every count linked to the exact operation. The detailed review and summary derived from the normalized patch the server would execute.

No model-generated paragraph described what approval meant. The product computed it.

A provider repair or author edit created a new proposal revision. Even if operation IDs were reused accidentally, the proposal and patch digest changed. The old receipt could no longer authorize acceptance.

The interface preserved earlier review notes and highlighted changed fields. Unchanged operations could be reviewed efficiently; approval still covered a freshly normalized selected patch.

Checkmarks were evidence of past inspection, not transferable permission.

Selection was closed before approval

“All valid operations” was a live query and could change. V0M3 converted selection to an immutable ordered list before creating the receipt.

Later operations appeared unselected in a newer proposal revision. Validation state changes could remove actionability and invalidate the receipt; they never added an operation to it.

Approval accepted a set, not a rule for discovering one later.

The exact patch might remain unchanged while the document changed around it. Acceptance required current canonical revision to match the receipt.

An unchanged block could support reviewed rebase, but rebase created a new proposal revision and approval. A new neighboring paragraph could change meaning without text overlap.

The server never applied an old patch because the line-level merge looked clean.

A source might be superseded, access revoked, or claim-support review updated. Review policy or destination scope could change.

The receipt named evidence and policy revisions. Acceptance evaluated current policy and source availability. A stricter current rule could require renewed review; a looser rule did not make an old receipt broader.

Approval was an authorization under world state, not a permanent property of text.

Receipts had a bounded clock expiry to reduce abandoned capability risk. They also expired immediately on relevant state changes.

An hour-old approval could remain semantically current; a ten-second-old one could be stale after a document edit. The interface explained the actual invalidating precondition rather than saying only “Session expired.”

State-sensitive expiry improved both security and recovery.

Server authority checked every field

At acceptance, V0M3 loaded current document, proposal, operations, evidence, validation, reviewer authority, and policy. It recomputed plan and digest and compared the receipt.

Client fields were identifiers and requests, never proof. Guessing a proposal ID, changing selected operations, or replaying a receipt on another document failed.

The approval capability was scoped to one command and could not call generation, export, or policy APIs.

The acceptance command carried stable request ID. If a response was lost after commit, retry returned the existing receipt. If the same approval and request ID were reused with different arguments, the server rejected it.

Once consumed successfully, the review receipt could not create another document revision. The resulting revision linked to it.

This prevented double-clicks and network retries from multiplying an approved patch.

Approval could cover several operations only within a review budget. Large changed-word count, deletes, new claims, structural moves, or scope changes triggered decomposition or a higher-friction review mode.

The product did not let a valid digest turn a thousand-line patch into an informed decision. Cryptographic-like integrity and human comprehension solved different problems.

The author could override limits deliberately and still had to inspect exact content.

Approval did not transfer between reviewers

A technical evidence reviewer could verify support without authority to accept prose. An author could accept wording while policy required an additional destination-scope check.

Receipts represented bounded decisions and could compose under policy. The final acceptance named all required current receipts. One person's review token could not be replayed as another decision type.

The interface showed what each review established.

When acceptance failed, V0M3 explained:

• Which precondition changed.
• Which operations remained identical.
• Which text, evidence, policy, or target differed.
• Whether rebase was possible.
• Which reviews needed renewal.

The author did not receive a generic forbidden error after careful review.

Recovery preserved prior work without stretching old permission.

The acceptance receipt included final document revision, applied normalized patch digest, and source review receipt. The success view compared it with the approved digest.

If post-commit rendering or cache invalidation failed, receipt lookup still established what changed. The current document could be reconstructed from the revision.

The user did not need to trust that the server had applied “roughly the same” operations.

External consequences needed separate approvals

Accepting text into a document did not approve export, public distribution, sending, or tool execution. Each downstream action named its artifact revision, scope, policy, and exact arguments.

A document approval could be a precondition for export and not the export command itself. Undoing the document later did not recall an artifact already shared.

Approval boundaries followed consequences.

Storing the entire proposed text in every review receipt would duplicate content and evidence. The receipt kept stable IDs, canonical digests, bounded summary, and required decision metadata. Canonical proposal records held the text under their own lifecycle.

Exports or offline review packets could include exact content intentionally with their own security and retention.

Integrity did not require uncontrolled duplication.

The confirmation summary was a real heading and list, not a transient tooltip. Keyboard users could traverse changes and return to the Accept control. Screen readers heard operation count, high-consequence changes, target revision, and validation state.

If approval expired while the page remained open, status changed through a polite announcement and the action disabled with a reason.

Informed consent to a patch had to be available beyond visual diff color.

The test changed one field at a time

After creating approval, fixtures changed:

• One character in proposed text.
• Operation selection.
• Target document revision.
• Evidence source revision.
• Support-verification result.
• Policy and destination scope.
• Reviewer permission.
• Dependency order.
• Request ID and arguments.

Every relevant change invalidated acceptance. Display-only layout changes did not.

The original extra-operation bug became the first regression case.

The old confirmation asked, “Apply these changes?” while “these” remained live. The revised system could identify the exact patch, evidence, document, policy, reviewer decision, and command result.

This did not guarantee the author read carefully. It made careful review possible and prevented the system from substituting a different action afterward.

Approval must bind to the exact patch because permission to change one state is not permission to change whichever state exists when the server finally runs.

The repaired interaction proved the point by doing less. It displayed a fixed set, created a bounded receipt, committed that set once, and refused every changed version. Nothing about the model's confidence, the patch's similarity, or the reviewer's earlier intent could broaden the authorization. “Approved” finally described an exact historical decision instead of a hopeful UI state.

The final attack was mundane

I opened review in two tabs. Tab A prepared approval for operations 1, 2, and 3. Tab B edited operation 2, regenerated operation 4, and changed the destination from private draft to public article. Tab A's screen still looked familiar and its approval reference reached the server.

Acceptance failed on proposal revision, patch digest, and destination policy. The page showed all three differences and preserved Tab A's notes. Reopening review selected no new operation automatically.

Nothing in the scenario required a sophisticated attacker. Ordinary concurrent editing had produced the same substitution risk. Exact binding protected the author from both malicious and accidental state drift.

The best approval UI did not celebrate security machinery. It named the patch, target, scope, and meaningful changes in calm language, then either committed that object or explained why it had changed.

The complexity lived in canonicalization, validation, capability scope, and durable records. The author's decision remained simple because “this” finally referred to something stable.

The review screen used server-confirmed state

Opening review loaded canonical proposal, document, evidence, and policy versions from the server. Client-side optimistic edits to proposal text remained Draft and could not be included in approval until saved as a proposal revision.

The page displayed the receipt inputs returned by a prepare-approval command. This prevented a stale browser cache from creating a digest over state the server no longer recognized.

The reviewer inspected a stable server-confirmed candidate, not a locally assembled approximation.

V0M3 did not lock canonical writing while someone reviewed a proposal. A lock would protect approval by blocking authorship and could be abandoned.

Instead, optimistic concurrency allowed document changes and invalidated the prepared receipt. The interface warned when another revision arrived and preserved the review comparison. A fresh prepare step could reuse unchanged inspection evidence where policy allowed.

The cost of conflict was preferable to making model review a global editing pause.

Time-of-check and time-of-use stayed together

The gap between review and commit invited change. V0M3 rechecked every precondition inside the acceptance transaction or under a durable decision protocol before writing the revision.

Current author authority, expected document revision, proposal state, evidence status, policy, and receipt consumption were evaluated together. A preflight check in the UI improved feedback and never replaced the transactional check.

Approval was validated at use, not only at preparation.

The client received an opaque approval reference rather than a self-authored JSON statement. The server stored or cryptographically protected its exact scope, expiry, and digest under application control. Regardless of representation, current records were revalidated on use.

The token could perform only acceptance for one document and patch. It was not a session credential and could not retrieve hidden sources or approve another operation set.

Possession enabled one bounded request; it did not erase policy.

Offline review produced a review packet

An author might inspect a proposal without a live connection. V0M3 could export a packet containing target revision, exact patch, evidence excerpts permitted for offline use, digests, and expiry.

Returning approval imported the packet as a review assertion. The server compared every digest and current precondition and normally required reconfirmation if anything changed. It never treated a detached signature-like artifact as proof that current world state matched.

Offline review preserved inspection; online acceptance preserved authority.

A reviewer could annotate an operation, ask a question, or record rationale without invalidating patch approval unless the comment was a required policy field. Editing proposed text or selected evidence did invalidate it.

The digest schema distinguished decision-bearing content from discussion metadata. This reduced unnecessary reapproval while keeping the boundary precise.

The distinction itself was versioned and tested; a new required field could not hide in “metadata.”

A proposal branch for the concise article and another for the technical report could share task ancestry. Approval on one branch applied only to its document revision and selected operations.

Merging branches created a new patch and required review. Identical text did not transfer approval automatically because destination scope, neighbors, evidence needs, and policy could differ.

Content equality was not decision equality.

Review receipts formed an audit chain

The accepted document revision linked to command receipt, approval receipt, proposal operations, evidence state, reviewer, and policy. Later correction created new records and supersession relationships.

The audit view could answer what was shown, what was approved, what executed, and what currently exists. It did not infer those steps from timestamps alone.

This chain helped distinguish a reviewer mistake from a server applying a different patch.

A reviewer could revoke an unused approval after noticing a problem. Policy or authority change could revoke it automatically. The server marked the receipt non-consumable and recorded reason.

Revocation after successful acceptance did not undo the document. It initiated a separate correction or inverse-patch workflow. This kept approval capability lifecycle distinct from committed state lifecycle.

The interface used “Revoke approval” and “Revert accepted revision” as different actions.

Once review began, V0M3 did not ask the model to summarize changes again inside the confirmation. That could produce wording different from what the author inspected or introduce a persuasive omission.

All confirmation text came deterministically from canonical operations and validation results. Model reasons remained available as labelled proposal content, not the authority statement.

The system itself explained the exact consequence.

Large language changes surfaced claim deltas

Changed-word count alone could label a one-word negation as small. The summary included added, removed, broadened, narrowed, contradicted, and unsupported claim states.

A patch introducing not into a policy sentence received high-consequence review even if it changed three characters. A long purely stylistic reflow could receive a lower claim-change signal.

Approval presentation followed meaning-bearing differences alongside text size.

For sensitive destination scope, V0M3 could require recent authentication before acceptance. Reentering credentials confirmed current identity and did not refresh a stale patch approval.

If state changed during reauthentication, the receipt invalidated and the reviewer inspected the diff again. Identity assurance and action agreement were separate preconditions.

Security ceremony could not cover a changed object.

The client displayed remaining approval time as convenience. The server evaluated expiry using its own clock and current revocation state. Pausing a tab or changing a device clock could not extend capability.

Expiry errors returned the still-visible review and a Prepare again action if other preconditions held. The author did not lose annotations or operation choices merely because the receipt timed out.

Safe expiration and humane recovery coexisted.

The success page was a receipt viewer

After commit, the page showed new document revision, exact applied-operation summary, accepted patch digest, and links to proposal and review. It did not rely on an optimistic client diff as proof.

Reloading or opening on another device produced the same information from durable records. The author could compare the accepted document with the approved patch and report any mismatch.

Success became inspectable state, not a green toast. The applied revision matched the reviewed bytes, preconditions, and declared consequence exactly. Nothing drifted.