Tombstone and Revocation Propagation¶
Protocol — instantiates Bidirectional Consistency Mapping
Preserves deletion or revocation evidence long enough to prevent resurrection across delayed paths.
A Tombstone and Revocation Propagation protocol makes a deletion behave like the durable, propagatable fact it is, rather than the mere absence of a record. Its defining idea is that removal must leave a marker — a tombstone — that outlives the longest delayed path, because a delete expressed as "the row is gone" is invisible to a stale replica that still holds the row and will happily re-share it, resurrecting what was meant to disappear. The protocol treats deletion, revocation, and restoration as first-class operations with their own conflict semantics (a delete versus a concurrent edit is a specific, dangerous conflict class) and, because tombstones often mark removed access or sensitive data, it must keep the marker long enough to be safe while minimizing what the marker itself retains. It is a wire-and-retention convention for removals; it does not suppress echoes and does not decide field authority.
Example¶
An organization deprovisions an employee. HR marks the person terminated, which must propagate to the corporate directory and revoke every access grant. If the directory expresses the removal as a plain delete and a stale sync node still holds the old "active" account, the next sync cycle re-creates the account — access resurrected for someone who left. The protocol prevents this: the termination writes a tombstone, user:4471 REVOKED, effective 2026-08-14, evidence hr-term-9, and propagates the tombstone, not just the absence. When the stale node reconnects and offers its cached "active" account, the tombstone — still present and newer — wins the delete-versus-edit conflict, and the account stays gone.
The minimization edge shows in what the tombstone carries: it retains the user's identifier, the revocation time, and an evidence pointer, but not the person's profile data, home address, or the reasons — enough to reliably suppress resurrection, no more. The outcome is a revocation that survives delay and offline windows without becoming a long-lived cache of sensitive personal detail.
How it works¶
- Removal leaves a marker. A delete or revocation writes a tombstone carrying the identity, effective time, and evidence, and this marker — not the row's absence — is what propagates.
- Delete-versus-edit is a named conflict. A tombstone meeting a concurrent or stale edit resolves by explicit rule (the removal wins unless a valid restoration supersedes it), never by silent last-write.
- Retention beats the delay horizon. Tombstones are kept longer than the maximum realistic offline and redelivery window, so no straggler can arrive after the marker is gone.
- Minimize what the marker holds. The tombstone carries only what is needed to suppress resurrection, keeping retention safe without hoarding sensitive detail.
Tuning parameters¶
- Retention horizon — how long tombstones live. Must exceed the longest offline/delay window; longer is safer against resurrection but conflicts with data minimization and storage.
- Marker payload — how much the tombstone retains (identity only, or identity plus evidence and reason). More payload aids audit and dispute; less payload respects minimization.
- Delete-conflict rule — whether a concurrent edit can ever override a tombstone, and what counts as a valid restoration. Strict rules prevent accidental revival but make legitimate restore harder.
- Compaction policy — bounded, auditable expiry versus unreasoned time-based deletion; auditable compaction preserves the safety guarantee, blind expiry breaks it.
- Revocation urgency — immediate one-way push for rights-affecting removals versus batched propagation; urgency cuts exposure but tightens coupling.
When it helps, and when it misleads¶
Its strength is defeating resurrection. A deletion that propagates as a durable, retained marker cannot be undone by a stale copy that never heard about it — which is the only reliable way to keep removed people, revoked access, and withdrawn consent from silently returning across delayed paths.[n1]
Its failure mode is a retention horizon set shorter than reality: expire the tombstone before the last offline replica reconnects and that replica resurrects the deleted state, now with the marker gone and no way to tell it was ever removed. The mirror-image misuse is hoarding — keeping fat tombstones of sensitive data forever "to be safe," turning a safety marker into a privacy liability. The guarding discipline is to size retention against the true delay horizon and to minimize the marker's payload, so it lasts long enough to protect and holds little enough to be safe.
How it implements the components¶
bidirectional_conflict_and_exception_policy— it defines deletion, revocation, and restoration as explicit conflict classes, giving a delete-versus-edit collision a named, evidence-backed resolution instead of a silent overwrite.sensitive_field_minimization_boundary— it bounds what a tombstone retains and for how long, keeping revocation markers safe by carrying only what resurrection-suppression requires.
It does not implement causal_change_identity_and_origin or the echo-suppression echo_idempotence_and_fixed_point_guard — recognizing a propagated change as one's own reflection is its protocol twin the Synchronization Origin Token; this protocol preserves removal evidence, it does not mark live edits to prevent bounce.
Related¶
- Instantiates: Bidirectional Consistency Mapping — the removal-and-retention convention that keeps deletions from being undone.
- Consumes: Field-Level Authority Matrix — which side may delete or revoke, and which fields are sensitive, is declared there.
- Sibling mechanisms: Synchronization Origin Token · Synchronization Conflict Queue · Field-Level Authority Matrix · Synchronization Lag and Oscillation Dashboard
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Tombstone And Revocation Propagation is defined in the frozen evidence as: Preserves deletion or revocation evidence long enough to prevent resurrection across delayed paths. Its operative deployed or enacted form is therefore Control, Automation & Runtime.
Nearest alternative: Protocol, Workflow & Routine — Protocol, Workflow & Routine can support this mechanism, but the evidence centers the concrete operation described above rather than the alternative family's defining operation.
Review outcome: Adjudicated after independent review; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: DeCandia et al., Dynamo: Amazon's Highly Available Key-value Store explains deletion by durable tombstones that propagate like ordinary writes and remain long enough to prevent an unavailable replica from resurrecting removed data. This directly supports computer science as the best-evidenced historical home of the operation—Preserves deletion or revocation evidence long enough to prevent resurrection across delayed paths.—while the alternates record adjacent lineages rather than mere domains of later use.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: preserves deletion or revocation evidence long enough to prevent resurrection across delayed paths.
- Library & Information Science — Library and information-science stewardship supplies a parallel or contributing lineage for the mechanism's defining operation: preserves deletion or revocation evidence long enough to prevent resurrection across delayed paths.
- Organizational & Management Science — Organizational management supplies a historically relevant adjacent lineage or formative practice for the operation—Preserves deletion or revocation evidence long enough to prevent resurrection across delayed paths.—but the researched evidence more directly locates the defining lineage in computer science.
- Security Studies & Intelligence Analysis — Security engineering, threat analysis, and intelligence practice supplies a parallel or contributing lineage for the mechanism's defining operation: preserves deletion or revocation evidence long enough to prevent resurrection across delayed paths.
- Systems Thinking & Cybernetics — Feedback, system boundaries, stocks, flows, and regulation supplies a distinct formative lineage for the mechanism's tombstone and revocation propagation logic.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus computer_science). The defining operation is: Preserves deletion or revocation evidence long enough to prevent resurrection across delayed paths. The researched DeCandia et al., Dynamo: Amazon's Highly Available Key-value Store explains deletion by durable tombstones that propagate like ordinary writes and remain long enough to prevent an unavailable replica from resurrecting removed data. That is mechanism-specific evidence for computer science as the historical origin. Organizational management remains represented among the uncapped alternates where it contributes a genuine formative practice, but broad deployment or governance of the operation is not by itself evidence that the mechanism originated there. origin_mode=single_lineage records lineage; domain_reach=universal separately records later applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] A tombstone is a marker that records the deletion of a record rather than physically removing it, so that other replicas learn of the deletion and do not treat their surviving copy as live data. Tombstones must be retained past the maximum replication delay before being compacted; expiring them too early is a classic cause of deleted data reappearing. ↩