How Superintelligence Works | Concurrent Document Edits — ETags, Lost Updates and Safe Merging

Two AI agents can edit the correct document at the same time and still produce a wrong final page. Each may read revision 7, prepare a reasonable correction and save later. If the second write replaces a complete document based on the old revision, it can erase a change saved by the first editor. This is the lost-update problem. Safe collaborative editing requires version-aware writes, deliberate conflict handling and independent readback rather than a model’s confident promise that the page is fixed.

Did you know that HTTP already defines a practical control for such conflicts? The If-Match request header asks a compatible origin server to apply a change only when the current representation has the expected strong ETag. When the state has changed, the server can reject the stale update, and the agent must reconcile before trying another write. An ETag does not provide user permission, resolve factual disputes or automatically merge documents; it protects one specific representation precondition.

This reader-first guide develops a fictional two-editor example, an eighty-edit reconciliation ledger and a changed sixty-update scenario. All numbers are original teaching data, not actual eduKate operations or evidence that artificial superintelligence exists. The wider How Super Intelligence Works series includes distinct lessons on agent ownership and workflow migrations.

Choose your reading route

• Editing shared school documents? Start with the two-editor race and version identities.
• Implementing an edit API? Read If-Match, 412 and conditional creation.
• Learning Mathematics? Recompute the eighty-attempt and sixty-update examples.
• Publishing through agents? Focus on current approval, independent readback and multiple-resource updates.

Contents

• 1. The ordinary two-editor race
• 2. Stable identity and revision form the edit contract
• 3. Strong ETags and the If-Match precondition
• 4. Understand 412 rather than trying to suppress it
• 5. Three-way merging uses base, mine and theirs
• 6. Conditional creation and canonical names
• 7. Modification times and content versions are not identical
• 8. Permissions and cancellation can change mid-merge
• 9. An eighty-operation teaching ledger
• 10. A transfer to sixty school-notice edits
• 11. Multi-resource work requires separate verification
• 12. Unknown responses require a stable operation trail
• 13. Strong checks complement source correctness
• 14. Diagnose rather than suppress concurrency errors
• 15. Practical checklist and learning transfer
• Frequently asked questions
• Standards and source notes
• Further reading

1. The ordinary two-editor race

Imagine a school notice at revision 7 that says the Mathematics workshop begins at 09:00 and links to last year’s information page. Teacher A checks the latest official notice and prepares a corrected time of 10:00. Agent B notices the broken link and prepares a better URL. Both edit copies of revision 7. A’s write produces revision 8; B then writes its whole document based on revision 7, unintentionally restoring 09:00. Both proposed corrections were individually useful, but the saved document lost one of them.

The precise failure is that B’s operation was not conditioned on the version it observed. A last-writer-wins store cannot tell whether B meant to preserve the new time, because B submitted a stale full replacement. A model could later write a beautiful summary claiming it fixed the link, yet the user’s real outcome also includes the incorrect time. The task needs a protected comparison of current state and an actual saved-state check, not merely a successful HTTP response.

To reproduce the problem safely, create two fictional local drafts from the same initial notice. Change the time in one, the link in the other, and save both as full replacements in order. Compare the final record with both requested changes. The second save may erase the first edit without triggering a syntax error. The lesson is that correctness of isolated text changes does not imply correctness of their concurrent composition.

Return to contents or continue with Stable identity and revision form the edit contract.

2. Stable identity and revision form the edit contract

A collaborative agent should identify the exact resource, tenant and revision it plans to change. A title such as ‘Secondary Mathematics Notice’ is not an adequate resource key when several schools and years have similar titles. Use a stable post or document ID under the authenticated user’s scope, together with a provider-supported version or validator. The identifier answers what is being edited; the revision answers what state the agent actually inspected.

Keep the original intended change separate from the content version. A writer can request ‘replace the broken link in paragraph three’ while holding a reference to revision 7. If a new version appears, the controller can compare the proposed edit against it instead of replaying the stale entire document. The application must still check whether that target field exists and whether the replacement remains appropriate to the current official source.

Version checks do not create authority. An ETag for another account’s file may be perfectly valid but the user may have no right to edit it. Before committing, verify authenticated identity, document ownership, action permission and any required approval. A correct concurrency gate and a correct access gate solve different problems; a reliable agent needs both at the actual tool boundary.

Return to contents or continue with Strong ETags and the If-Match precondition.

3. Strong ETags and the If-Match precondition

RFC 9110 defines If-Match as a conditional request field comparing supplied entity tags with the selected current representation. For this purpose the server uses strong comparison. An editor can GET a document with an ETag, prepare its authorized change, and send the resulting write with that earlier tag. If the current representation no longer matches, the origin server cannot safely apply the requested change under the original assumption. This is a standard way to prevent a lost update.

The ETag should come from the origin server and remain associated with the representation it validated. Do not manufacture one from a model-generated hash unless the service explicitly defines that mapping. Some APIs offer revision IDs or expected-content hashes instead of HTTP entity tags; these can serve related optimistic-lock contracts, but only when the actual server enforces the comparison before applying the write. Adding a header that the provider ignores provides no protection.

Strong-versus-weak distinctions matter. HTTP also defines weak validators that can help with caching, but strong If-Match comparison is deliberately more exact for state-changing operations. If the server returns a weak tag, an agent must not strip its weakness marker and pretend it is a valid strong write precondition. Use the supported edit API, request a reliable version token or hold the action until a safe mechanism is available.

Return to contents or continue with Understand 412 rather than trying to suppress it.

4. Understand 412 rather than trying to suppress it

An HTTP 412 Precondition Failed response is not an instruction to retry unconditionally. In a concurrent-edit scenario it can indicate that another actor changed the relevant representation after the agent’s read. The safe next step is to fetch the current document and examine the difference. A retry without the old If-Match simply removes the guard that saved the competing author’s work. A user-facing message can explain that a later revision was found and the edit needs reconciliation.

Distinguish a version failure from a permission refusal or validation error. An account lacking edit access may be denied even when the version is current, and a malformed document can fail for reasons unrelated to concurrency. The controller should classify the actual provider response and preserve the original operation identity. One generic ‘failed’ label can hide the correct next action and encourage broad, unsafe retries.

RFC 9110 permits particular success responses for a conditional request when the requested change is already established as applied, rather than assuming every precondition failure always returns 412. This nuance is another reason to inspect actual resource state after an ambiguous write. A model should never infer that a missing response means no edit occurred, nor that a 2xx response proves every downstream publication stage finished.

Return to contents or continue with Three-way merging uses base, mine and theirs.

5. Three-way merging uses base, mine and theirs

A three-way merge compares the shared base revision, the agent’s proposed version and the current saved version. If A changed the workshop time and B changed a link in an otherwise independent sentence, a suitable merge can retain both edits. The controller still needs to check exact source references, protected fields and effective dates. A textual merge that produces valid grammar is not automatically a correct school notice.

Overlapping changes demand more review. If one editor changes the deadline to 17:00 and another to 18:00 based on different notices, choosing the later text is not an evidence-based resolution. Determine which institution issued each notice, which cohort the rule covers and whether a genuine conflict remains. A qualified human may need to decide. An AI agent can prepare a comparison without gaining authority to invent the official answer.

Automatic merging is safest under narrow contracts. Nonoverlapping independent structured fields may be mergeable after validating both sources and revision relationships. A change to an attachment, permission grant or publishing status may require a fresh explicit approval even if no words overlap. The application’s merge policy should be versioned and tested, rather than described only by a model instruction to resolve all conflicts politely.

Return to contents or continue with Conditional creation and canonical names.

6. Conditional creation and canonical names

Two agents can race to create the same initial document. Both search and see no post, then each creates one; the result may be two pages with slightly different slugs. HTTP’s If-None-Match star can support create-if-absent semantics when the origin server implements the relevant method and precondition. Other providers use uniqueness constraints or idempotency keys. The essential property is that only one intended logical resource owner is created.

A preliminary search is useful but not atomic with a later create. Another worker can create a post between the two operations. Before retrying after a timeout, inspect the canonical intended slug, task ID and provider records. Do not select a suffixed URL automatically to make the workflow appear successful. Duplicate pages can confuse readers, split search visibility and require avoidable cleanup.

Not every content-management interface exposes HTTP conditional creation. A protected server method can implement equivalent uniqueness and task identity rules. The agent should adapt to the provider’s real API rather than claim a guessed If-None-Match header guarantees behaviour it never verified. Successful creation still needs an authenticated readback of the exact intended public or draft state.

Return to contents or continue with Modification times and content versions are not identical.

7. Modification times and content versions are not identical

RFC 9110 also describes If-Unmodified-Since, which can condition a change on a resource’s modification time where appropriate. It can help avoid writing over changes if a suitable entity tag is unavailable. However, timestamp precision and origin-server semantics matter. A client-local clock value or a rounded display date is not automatically a trustworthy state token for concurrent editors.

Imagine two updates occurring within one reported second. A date with one-second granularity might not distinguish them even though the content changed twice. A strong representation validator or revision sequence is usually a more precise concurrency tool when the provider offers it. The correct design is based on documented server guarantees, not the visible timestamp’s resemblance to a clock.

Some page-editing systems offer both expected modified time and content hash. If those are supported as write preconditions, the agent can detect a concurrent change before inserting a new section. After the write, independently verify the earlier prefix remains intact. The method is not identical to universal HTTP ETag handling; use the actual provider’s contract and name the observation it proves.

Return to contents or continue with Permissions and cancellation can change mid-merge.

8. Permissions and cancellation can change mid-merge

Suppose the user approved preparing a draft and later cancelled publication while two agents were resolving an edit conflict. A current document version does not reinstate the earlier approval. The executor must revalidate current user intent, recipient or audience, and relevant source state before producing a consequential effect. Optimistic locking prevents stale overwrites, but user authority is an independent constraint.

An assistant may also lose access to the document during a long operation. The fact that it once retrieved revision 7 does not guarantee future permission to publish revision 9. Current object-level access should be enforced by the target service. A summary in the model’s context saying ‘editor approved’ is weaker than a trusted current grant tied to the exact resource and revision.

Safe fallback can preserve preparatory work without acting. The agent might offer a private proposed merge and explain which reviewer needs to approve it, rather than force a public save. This keeps the process helpful and transparent while respecting the changed conditions. The result should be labelled Prepared, Held or Verified, not simply Done.

Return to contents or continue with An eighty-operation teaching ledger.

9. An eighty-operation teaching ledger

Consider a fictional Cedar Writing Desk recording eighty attempted edits. Forty-six are directly applied with matching versions and verified saved results. Sixteen are stopped by a stale-version precondition. Eight are safely merged after new source and approval checks and verified. Six have unknown external effects after a timeout. Four are properly cancelled before another action. The categories add to 46 + 16 + 8 + 6 + 4 = 80.

The share of direct verified edits is 46 ÷ 80 = 57.5%, while safe reviewed merges account for 8 ÷ 80 = 10%. Thus 54 of 80, or 67.5%, reached verified completion at this cutoff. Blocked stale-version attempts are 20%, unknown results 7.5% and cancellations 5%. These fictional numbers are not a provider benchmark and should not be described as real AI-agent error rates.

The sixteen rejected stale edits may be evidence that useful competing work was protected. They are not sixteen authoring failures simply because no new content was written. An agent that always retries and overwrites would raise its apparent ‘write completion’ rate while losing user data. Correct evaluation distinguishes legitimate refusals from verified fulfilled tasks and from unresolved outcomes.

Return to contents or continue with A transfer to sixty school-notice edits.

10. A transfer to sixty school-notice edits

Try a separate fictional workload of sixty notices. Thirty-five edits have independently verified intended results, twelve conflict with newer source revisions, eight are held because current approvals or source facts are missing, and five have uncertain provider effects. Check 35 + 12 + 8 + 5 = 60. The verified share is 35 ÷ 60 ≈ 58.33%; conflict holds are 20% under this chosen teaching population.

Now six of the twelve conflicts are resolved through three-way review and new version-checked writes. Verified completions increase to forty-one, unresolved conflicts decrease to six, and the other categories stay eight and five. The total remains 41 + 6 + 8 + 5 = 60, with verified share about 68.33%. These are updated observations about the same fictional cohort, not evidence that a real service spontaneously improved.

Change another condition: the school source for one deadline is superseded by a newer notice. Even a nonoverlapping edit can now be substantively wrong unless the applicable date and issuer are checked. The agent must distinguish a text-version conflict from a factual-source conflict. An accepted conditional write cannot establish that the date is current for every family.

Return to contents or continue with Multi-resource work requires separate verification.

11. Multi-resource work requires separate verification

A WordPress publishing task may update a post body, SEO metadata, category, featured image and a hub page. These can be separate resources or operations with different save semantics. A successful write to the article does not prove the hub links to it or that metadata survived the server’s content normalization. Each claimed end state needs suitable independent readback.

When updating a shared hub, first read its current version and append only the intended new section under the supported optimistic lock. If another agent updates it first, reread, recompute the append and retry under current preconditions rather than overwrite the entire older hub snapshot. Preserve the existing prefix as a test invariant. This is a narrower case than general agent lease ownership.

A conflict in the hub should not automatically cause deletion of a correctly published article. The article may remain an authorised independent asset while the hub link waits for safe reconciliation. Record the partial state and resume only the missing step. A model-generated claim that the whole pipeline completed is not a substitute for separate resource-state observations.

Return to contents or continue with Unknown responses require a stable operation trail.

12. Unknown responses require a stable operation trail

A network timeout after a content write does not prove the write failed. The origin server might have committed and lost the response. Repeating the operation without inspecting the target can cause another edit or duplicate post. Keep the original operation identity, intended resource and expected result, and reconcile the actual saved state before any new consequential call.

If the provider has already committed the exact intended change, report it after readback and avoid a second write. If the provider shows the old revision and no accepted operation, a bounded retry may be appropriate under current authority. If its result cannot be established, preserve Unknown and route to responsible review rather than generate a confident success or failure.

A resumed agent must not lose these details through context compaction. A summary saying ‘still need to finish publishing’ can be dangerously vague if the resource was already created. A structured checkpoint with post ID, original slug, prior receipt and expected content prevents the next worker from beginning the whole workflow again.

Return to contents or continue with Strong checks complement source correctness.

13. Strong checks complement source correctness

A server can enforce every ETag rule while an agent cites last year’s admissions notice. Concurrency safety says the edit did not accidentally overwrite a newer resource representation, not that its information is correct. Material education claims still require primary-source checking, effective-date analysis and qualified review when sources conflict.

A versioned approval can also be perfectly current for one target and invalid for another. Publication to a public audience differs from saving a private teacher draft. Include the exact action and content revision in the permission record. A model’s correct link correction is not a basis to add an unsolicited subscription email or expose another person’s private document.

Use complementary test oracles: version precondition, object-level authority, factual source applicability, exact changed fields and final target state. These tests cover different failure paths. One passing gate cannot compensate for a failure in another when the user has requested a consequential verified outcome.

Return to contents or continue with Diagnose rather than suppress concurrency errors.

14. Diagnose rather than suppress concurrency errors

Failure one: an agent uploads the entire old document and erases a coworker’s edit. Add a server-enforced version precondition. Failure two: a 412 error triggers a retry without the validator. Re-read current state and merge only under explicit compatible rules. Failure three: a weak ETag is treated as a strong one. Follow the provider’s actual validator semantics.

Failure four: multiple agents create separate posts for one intended slug. Use stable task identity and server-side uniqueness or conditional creation when supported. Failure five: an update to one post succeeds while the hub remains outdated. Track and verify each related resource separately. Failure six: current content is saved under an expired user grant. Recheck authority before the write.

Test these failures with synthetic documents and controlled workers. Allow one editor to commit while another is paused, then inspect whether the stale write is refused and whether a reviewed merged version preserves both changes. Test legitimate positive edits too; an application that refuses every write would prevent some lost updates but fail the service’s purpose.

Return to contents or continue with Practical checklist and learning transfer.

15. Practical checklist and learning transfer

Before editing, identify the exact owner and resource, fetch the current representation, retain its version and prepare a narrow intended change. Validate current user permission and factual source. Submit through the actual provider-supported optimistic precondition, not merely a model-written description of one. If the state changed, stop and reconcile rather than remove the guard to force success.

After a compatible edit, read the saved resource and check the desired change, protected unrelated fields, publication status and relevant metadata. If an external result is uncertain, reconcile the original operation. When multiple resources are involved, record partial completion and update only the missing step under its own current version. These habits preserve others’ legitimate work.

Students can reproduce the two-editor time-and-link scenario with paper worksheets and see why two individually correct changes can combine incorrectly. Then calculate 54 verified completions out of eighty attempts and explain why sixteen blocked overwrites need not be classified as unsafe outcomes. The deeper lesson is that reliable AI collaboration requires current evidence, not confidence in an old copy.

Return to contents.

17. Optimistic locking and leases are different strategies

An exclusive lease can establish which worker is allowed to write during a period, while an optimistic version check asks whether the resource changed since a particular read. They solve overlapping but nonidentical problems. A lease may expire while a worker is still running; a version check can prevent that worker from overwriting a newer document if the old expected revision no longer matches. This lesson concentrates on conditional edits rather than the separate topic of single-writer fencing.

A protected document service may use both. A worker can have a valid assigned task and still be asked to submit the version it examined. If another authorised editor updated the document first, that edit must be reconciled. Holding a workflow lease should not mean deleting a teacher’s legitimate newer information simply because the agent believes it owns the overall project.

Choose mechanisms under the actual provider’s semantics. An HTTP If-Match protects the particular selected resource representation according to RFC 9110; it is not automatically a distributed lock across many databases. A business transaction might require several independent preconditions or a dedicated transactional service. Describe these boundaries clearly before using a general phrase such as ‘the document is safe to edit’.

Return to contents for the full sequence.

18. A conflict report should tell people what actually changed

A useful review interface compares the base version, the latest saved version and the proposed change, with exact resource IDs. It can highlight that a school workshop time changed from 09:00 to 10:00 while the proposed edit alters only the link. The reviewer should be able to accept a compatible merge without accidentally reverting the timetable. A generic error saying ‘someone else edited the document’ is less informative but still safer than silent overwriting.

Separate three kinds of disagreement: a mechanical revision mismatch, a factual source conflict and an authorisation change. An ETag mismatch establishes that the selected representation differs under the server’s validator. It cannot determine which school date is correct or which user should be allowed to publish. Those require source evidence and permission checks. Distinct classification makes the next action safe and prevents needless model retries.

Do not show private competing edits to an unauthorised person merely to explain a conflict. A parent may learn that the document was updated without receiving internal staff comments. The review interface should fetch the relevant diff under trusted access rules. A model’s desire to summarize the whole history does not create permission to disclose another person’s notes.

Return to contents for the full sequence.

19. A source revision is not always a presentation revision

A school information page can change its formatting or sidebar while the underlying eligibility fact stays the same. Conversely, the official source may change a crucial rule while the page’s cached preview appears unchanged. Document version checks protect the selected target representation; factual assurance requires a separate link to the authoritative source and its applicable revision. They can change on different timelines.

An agent that edits the published article may need to retain a map between each important claim and the source notice that supports it. If the source notice changes, the article may need an editorial correction even when no other agent changed its body. A clean ETag-based write will not detect that external factual drift unless the workflow explicitly checks source applicability.

This is why quality gates should include both concurrency and evidence. An accepted update can be mechanically valid, yet wrong for the cohort or incomplete after the editor removed an exception. A review can preserve the textually compatible link correction while holding the newly proposed source-dependent claim. Completion is the user’s correct saved outcome, not simply a write without an HTTP error.

Return to contents for the full sequence.

20. Avoid unsafe automatic conflict resolution

Some collaborative editors use last-writer-wins rules because they are simple and fast. For low-impact independent preferences, that may be acceptable under a declared product contract. For deadlines, eligibility, consent, recipient identities and public education notices, silently choosing whichever write arrived later can be unacceptable. The safe merge policy should name which fields may be automatically combined and which demand fresh review.

A model-based merge is particularly vulnerable to inventing bridging text that neither editor approved. If one paragraph says sessions begin at 10:00 and another introduces a timetable exception, the assistant should preserve the actual source conditions rather than average or paraphrase them into a pleasant compromise. A review can use the model’s suggested diff as a proposal while checking source IDs and effective dates independently.

When a conflict cannot be resolved from authorised evidence, keep it explicit. Preserve both proposed changes and the existing published revision, and tell the responsible editor what needs decision. A safe hold is often cheaper than correcting a misleading announcement after families act on it. A performance dashboard should not reward automatic merging solely for reducing the number of visible conflicts.

Return to contents for the full sequence.

21. Exact-readback tests can catch transformed content

Content-management systems may transform uploaded markup, normalize characters or discard unsupported fields. An agent might submit a well-formed draft and receive a successful save response, yet the stored body may differ. Read back the actual raw content through an authorised edit context and compare what matters: headings, important factual sentences, links, source citations and metadata. For high-assurance workflows, an exact-body comparison may be appropriate where the API preserves that representation.

A WordPress article could be published with a generated title and valid slug while lacking the user’s requested internal links or SEO description. That is not full completion of the task. Save-state verification should include the intended post ID, live status, category, relevant registered metadata and any required cross-links. Avoid claiming a featured image exists without observing an actual assigned media item.

A mismatch should lead to a controlled repair under the current revision rather than blind resubmission of an old entire document. Check whether another writer modified the article or the platform itself normalized markup. Repairing a formatting issue should preserve newly inserted authorised material. The protected write condition should continue to apply during the correction.

Return to contents for the full sequence.

22. Read the eighty-edit table as a real operational question

The fictional eighty operations contain forty-six directly verified edits, eight reviewed merges, sixteen blocked stale versions, six unknown effects and four cancelled requests. Those sum to eighty. A useful dashboard would report fifty-four verified completed results rather than eighty attempted writes. It would also show the sixteen conflicts as protected work needing review, not as a reason to disable the version check.

Suppose a manager asks whether reducing precondition failures improves service quality. The answer depends on how the failures are resolved. A design that silently overwrites newer revisions will reduce visible 412 errors while increasing lost updates. A better improvement might present clearer diffs so compatible edits can merge safely. Measure how many legitimate teacher changes survived and how many user tasks actually finished.

A team can separately measure conflict detection, review time, safe merge rate and final content correctness. The denominators must remain clear. The eight reviewed merges are a subset of the eighty attempted edits in the invented snapshot, not eight extra user requests to add to the workload. When outcomes change after review, produce a new dated ledger without erasing the original cutoff.

Return to contents for the full sequence.

23. Failure recovery is itself a concurrent edit

An undo action can overwrite somebody else’s subsequent work. Suppose a faulty agent publishes a wrong session time, then a teacher legitimately corrects the same page and another person adds an accessibility note. A rollback that restores the entire old page could remove both later improvements. Repair should target the incorrect change against the current version with source and permission checks, not blindly restore a previous full snapshot.

The same applies to a failed hub update. If a previous append timed out, the agent should fetch the latest hub before trying again. The prior section may already have been inserted by another worker, or new chapters may have been added since. Deduplicate exact article links and apply append-only changes under supported optimistic locking. Do not overwrite the hub with a snapshot from before other articles were published.

Reliable recovery preserves both history and progress. The user should know which correction is complete, which link or metadata is pending and whether a separate source decision is required. A model’s final message can summarize those verified facts, but its description of an intended rollback is not evidence that the target was actually repaired.

Return to contents for the full sequence.

24. How to teach safe shared editing with a simple worksheet

Give two students one fictional notice containing a time, teacher name, venue and URL. Each receives a copy of revision 7. One changes the time after reviewing a current notice, and the other changes the broken URL. Ask them to combine changes without deleting either. The simplest accurate answer is to inspect the shared base, compare current saved state and apply only the compatible change under a new revision.

Now change the exercise so both students modify the same deadline based on two different documents. A three-way text merge no longer settles which deadline applies. Require the students to identify the issuer and effective year of each source and explain what they can and cannot conclude. This builds the same skill used in real AI collaboration: recognise the difference between mechanical state conflict and a factual question.

Finally, make the teacher revoke publication approval while the merge is being prepared. Even a perfectly current merged worksheet must remain private unless an appropriate new grant permits publishing it. Students can see why version, factual support and authority are separate gates, and why checking the actual final saved page is more useful than a confident statement that the edit succeeded.

Return to contents for the full sequence.

• 17. Optimistic locking and leases are different strategies
• 18. A conflict report should tell people what actually changed
• 19. A source revision is not always a presentation revision
• 20. Avoid unsafe automatic conflict resolution
• 21. Exact-readback tests can catch transformed content
• 22. Read the eighty-edit table as a real operational question
• 23. Failure recovery is itself a concurrent edit
• 24. How to teach safe shared editing with a simple worksheet

Frequently asked questions

What is a lost update?

One actor overwrites changes made by another after both worked from an earlier state of the same resource.

What does If-Match protect?

Under HTTP’s documented semantics, it conditions a change on the current representation matching the supplied strong entity tag.

Is a 412 error permission to retry without a guard?

No. Fetch the current version, assess the competing changes and deliberately reconcile under a fresh precondition.

Can an ETag prove the user authorized publication?

No. Permission, current source correctness and saved-state verification are separate checks.

Are independent text edits always safe to merge?

No. Even different fields can interact semantically or depend on different applicable source revisions.

How should the assistant confirm the edit completed?

Read back the canonical saved resource, check intended fields, current status and any related hub or metadata operation.

Standards and source notes

Sources reviewed 24 October 2026. All Cedar Desk activity, times, revisions and outcome counts are original fictional teaching data, not a measured production system.

• RFC 9110: HTTP Semantics: If-Match, strong entity-tag comparison, preconditions and 412 responses.
• MDN: 412 Precondition Failed: A practical explanation of midair edit collisions.
• PostgreSQL: MVCC: Background on concurrent resource observation and writing.
• PostgreSQL: Transaction Isolation: Why concurrent state assumptions matter beyond individual write calls.
• NIST AI RMF Playbook: Manage: Accountable changes and oversight of AI-assisted operations.

Further reading

Continue with Super Intelligence curriculum; How X Works hub; Cross-Agent Resource Ownership; Workflow Migrations; Tool Contract Drift; Cache Invalidation; Gold Standard of Education. Safe editing protects the original authority, current version and final saved outcome.