The direct answer
Bind the approved patch and target to the strong validator obtained with the representation that was actually reviewed. The origin must coordinate the condition with the complete mutation; If-Match is neither approval nor object authorization, and a later mismatch cannot settle an earlier unknown outcome.
Identify the edit that could overwrite someone else’s work
A fictional assistant proposes changing note N-A from title “Draft” to “Ready” while preserving its body. The reviewer sees representation R-A. Before the write reaches the origin, another editor corrects the note. Applying the original edit without a condition could discard assumptions the reviewer relied on.
The exact-action approval guide binds what was approved. This guide asks a different question: what HTTP write contract prevents that approved patch from being applied to a different base representation? It is also separate from conditional GET and 304 cache reuse.
Require a supported origin contract before constructing a request
RFC 5789 section 2 defines a patch document identified by its media type; there is no default format every server must support. It recommends conditional requests for patches needing a known base, including strong ETags with If-Match. PATCH is not inherently idempotent.
For this proposed worksheet, F-A labels an integration’s separately reviewed patch format. P-A labels the immutable document expressing the title-only change in that format. Neither is executable syntax or evidence that an endpoint supports it. Before implementation, verify the actual route, media type, format semantics, resource limits and handling of unsupported input. Advertised support is not proof that every condition is enforced.
The narrow application policy permits editing existing N-A only. It excludes creation, other notes and effects such as sending messages. Authentication, current object rights, content validation and any necessary approval remain independent requirements.
Preserve the representation and validator association
RFC 9110 sections 8.8 and 13.1.1 define ETags as opaque representation validators. If-Match uses strong comparison: neither tag may be weak and their opaque values must match character-for-character. A list matches any listed tag; “*” tests current representation existence. Neither is necessarily a match to one reviewed snapshot.
Propose this server-owned review record, using inert labels rather than wire values:
PROPOSED_UNRUN — no HTTP request constructed
Target: existing note N-A / workspace WS-A
Reviewed representation: R-A / selection profile SEL-A
Observed validator: TAG-A / strong / obtained with R-A
Approved method: PATCH
Approved change: immutable P-A / reviewed format F-A
Application condition: exactly TAG-A
Permitted consequence: title-only update on N-ASEL-A fixes the supported representation-selection contract. Preserve its association with the actual origin response; do not attach a tag from a summary, another note or another negotiated representation. For example, the integration must account for content-coded variants rather than assume the displayed decoded text identifies every wire representation. A model must not invent a tag, remove a weakness marker or replace TAG-A with a newly observed value.
This application deliberately accepts one strong snapshot tag, excluding weak tags, wildcard conditions and multi-tag alternatives. That is a stricter integration policy, not a declaration that those forms are all invalid HTTP. Treat tag values as opaque; the names TAG-A and TAG-B imply no numeric ordering.
Put the origin check at the mutation boundary
RFC 9110 section 13.2 places normal request checks before preconditions, then evaluates conditions just before content processing or the method action. A matching tag cannot turn an authorization failure into permission. This profile rejects missing required conditions with the origin’s declared policy after applicable normal checks.
RFC 5789 requires the entire patch to apply atomically, without exposing a partially modified representation; if it cannot all apply, no changes may be applied. For our design, require a supported mechanism that coordinates the current-condition check, applicable current authorization and whole mutation against the same state. A separate read or HEAD check followed by an unconditional write leaves a race.
No database transaction, HTTP middleware or server implementation is supplied here. Release requires implementation evidence that an intervening writer cannot slip between an accepted comparison and its mutation. A screenshot of the outgoing header does not establish this property. Nor does updating a local UI preview reserve the origin state.
Review eight inert acceptance cases
Every row is PROPOSED_UNRUN. The positive case assumes the actual origin contract and required local authority are established; it is not an observed successful PATCH.
| Case | Inert state or condition | Proposed disposition |
|---|---|---|
| Unchanged ordinary note | R-A/TAG-A still current; P-A, F-A and rights unchanged | Eligible for the coordinated title-only update; preserve body |
| Intervening editor | Review used TAG-A; current origin uses TAG-B | Do not overwrite; obtain fresh authorized state and review |
| Weak evidence | Only a weak tag accompanies the preview | Unsupported snapshot contract; never strip its marker |
| Broader condition | Wildcard or several alternative tags offered | Reject under the single-snapshot policy |
| Condition absent | No required reviewed tag supplied | No mutation under this profile; explain the required condition |
| Object or rights unavailable | N-A absent or actor no longer authorized | Apply normal checks and disclosure policy; no creation fallback |
| Separated check and write | TAG-A checked, another edit occurs, unconditional update follows | Fails the coordination gate; do not claim lost-update prevention |
| Initial reply lost | First outcome unknown; later response reports a mismatch | Reconcile; no automatic retagging, replay or outcome inference |
Keep failure, missing proof and uncertain history separate
Under RFC 9110, a false If-Match condition prevents performing the method. The response can be 412; an allowed 2xx alternative reports an already-applied change, not permission to reapply it. This profile should document its chosen behavior explicitly.
RFC 6585 sections 3 and 7.1 define optional 428 Precondition Required for an origin requiring conditional requests. A 428 response must not be cached. Missing required proof and a supplied false condition are different cases; clients cannot assume every server implements 428.
For an authorized conflict, show that the reviewed base changed, retain the original proposal separately, and require reconsideration against the fresh representation. Do not silently substitute its validator and resubmit P-A. That would authorize a different base without review.
A lost reply might follow a completed write. A subsequent 412 says nothing definitive about that earlier attempt. Even current content matching the desired title might reflect another editor’s equivalent change. Keep the operation unresolved until the integration’s supported reconciliation evidence settles the relevant outcome. Conditional writes do not establish exactly-once external effects.
Describe the unrun boundary honestly
No application HTTP request, patch document execution, datastore mutation, concurrency test or approval operation occurred. The eight cards are a proposed release worksheet, not server enforcement evidence. Real adoption needs the actual format and origin implementation reviewed, including changed state, denied access and uncertain outcomes.
Boundary is a prelaunch model request router and does not ship this conditional-write origin. Its synthetic action exercise and mock policy evidence establish separate, limited behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.