Execution safety, control 7 of 9
S-07 Prevent stale, concurrent and duplicate writes
P0Hard gateNeeds your evidence
Writes must target the reviewed version, respect concurrent human work and avoid duplicate effects after retries.
- Priority
- Gate. A FAIL stops publish or launch.
- Hard gate
- Yes. A FAIL stops publication, whatever the score.
- Change class
- READ_ONLY: Inspect authorised evidence.
- Quality bucket
- Not scored: hard gate only
Evidence to review
- Version checks, lock state, idempotency record and retry tests.
How to implement
- Use compare-and-swap or equivalent version checks.
- Lock the relevant site/template scope for consequential changes.
- Use idempotency keys where supported and verify effects before retrying uncertain writes.
- Invalidate stale plans when source data or the candidate changes.
How UltimateSEO checks this
Needs your evidence. No automated check covers this control, so it stays UNKNOWN until evidence is supplied.
States used: PASS, FAIL, UNKNOWN, NOT_APPLICABLE or BLOCKED. UNKNOWN is never shown as a pass. How states work.
Part of The UltimateSEO Framework v4.3, catalogue dated 2026-10-14. Evidence states, control states and the publish gate are explained on the hub.