The Correction Propagation Contract: When One Facility Fact Was Wrong, What Must Be Recomputed, Retracted, or Replayed?

Authored proposed method. Every facility, system, record, threshold, message, action, and result in this paper and its companion tools is fictional. This is not evidence of a Facily.ai or modSTORAGE product, deployment, customer result, performance level, certification, legal conclusion, or industry standard.

A facility address was wrong in the source record. The operator fixed it.

That sentence sounds like closure. It is usually the beginning of the hard part.

The old address may still exist in a reporting table, a call-routing export, a cached API response, an automation condition, a search index, a generated briefing, a vendor file, or a message already sent. A correction applied at the point of entry does not prove that the operational system now agrees with it. It proves only that one representation changed.

This problem becomes sharper when AI is involved. A corrected source row does not automatically retract a prior model recommendation, remove an obsolete retrieval chunk, revise a human decision already made, or undo a real-world action. The correction has to travel through the same dependency structure that allowed the wrong fact to travel in the first place.

I call the control for that work a correction propagation contract: a versioned packet that identifies the superseded assertion, establishes correction authority, freezes an exact dependency view, assigns a disposition to every affected consumer, and requires readback before the correction can be called reconciled.

The contract is not a database feature. It is an operating agreement across data, workflow, automation, reporting, AI, communication, and human authority.

Open the full-size accessible diagram.

Governed companion package

Use the contract. Test propagation and residuals.

These files contain fictional examples and structural tools. They do not establish a live facility fact, source authority, product capability, customer result, correction outcome, operating performance, certification, or independent validation.

Download the source and limitations register ↓Download the correction-propagation register ↓Download the correction-propagation readiness suite ↓Download the Draft 2020-12 correction contract schema ↓Download the fictional correction-propagation record ↓Download the correction-propagation runbook ↓Download the accessible correction control-plane SVG ↓Download the correction control-plane PNG ↓

A correction is not an overwrite

An overwrite answers one question: what value is stored here now?

A governed correction must answer at least seven:

1. What exact assertion was wrong?
2. Who or what has authority to supersede it?
3. From what effective time is the correction applicable?
4. Which consumers used, copied, derived, displayed, or acted on the old assertion?
5. What disposition does each consumer require?
6. What cannot be reversed and therefore must be annotated or escalated?
7. What evidence proves the governing outputs now reflect the intended state?

The W3C Data on the Web Best Practices recommends persistent identifiers, provenance, version indicators, version history, and documented update practices. Those ideas are useful, but a self-storage operator still has to define the operational closure rule. A visible “updated” timestamp does not show which reports were recomputed or which actions remain contaminated.

The distinction is practical:

• update changes a value;
• correction supersedes a prior assertion under named authority;
• propagation applies an explicit disposition to affected consumers;
• reconciliation compares governing outputs with the correction packet;
• closure records completed readback and every unresolved residual.

Skipping any of those states invites false confidence.

The unit of control is an assertion

A facility fact is more than a field and value. The useful unit is an assertion:

subject + predicate + value + effective interval + source + authority + version + evidence boundary

Suppose a fictional facility record says:

FAC-FIC-004 + access_hours + 24/7 + effective 2026-08-01 + vendor_feed + unqualified + v17

The candidate correction says:

FAC-FIC-004 + access_hours + 06:00–22:00 + effective 2026-08-01 + signed_manager_notice + facility_operations_owner + v18

Changing 24/7 to 06:00–22:00 without preserving the superseded assertion destroys information needed to determine who saw the old value, what period it affected, and whether a previous action was reasonable under the evidence then available.

The W3C PROV Data Model supplies domain-neutral concepts for entities, activities, derivation, agents, generation, invalidation, and revision. It also states its own boundary: provenance can support assessments, but the model does not decide domain truth. In this method, PROV concepts help describe the correction chain; the named facility authority still determines which assertion governs.

The PROV Constraints Recommendation adds ordering and consistency constraints for provenance descriptions. A valid ordering is valuable, but it does not prove the dependency inventory is complete. The PROV Ontology provides interoperable vocabulary, not an operational promise that every downstream copy was found.

That is why the correction packet should preserve both identities:

• superseded_assertion_id
• governing_assertion_id

It should never silently mutate the first into the second.

Freeze the dependency closure

Before propagation begins, freeze a versioned view of the affected dependency closure. This is the set of known consumers reachable from the superseded assertion at the moment the correction is scoped.

For facility operations, I use seven consumer classes.

1. Governing source

The system or record allowed to hold the corrected assertion. It needs a conditional write, immutable audit entry, or equivalent conflict control. If the governing record changes again during propagation, the packet must stop or rebase.

2. Replicas and read models

Operational databases, replicated tables, caches, API projections, search indexes, mobile stores, extracts, and spreadsheets. These may require replacement, invalidation, rebuilding, or quarantine.

3. Derived information

Metrics, aggregates, rankings, forecasts, exception lists, dashboards, scheduled reports, and exported files. Replacing the source value is insufficient when the derivative persists independently.

4. Workflow and automation state

Tasks, eligibility results, routing decisions, timers, retries, approval queues, and pending actions. A corrected fact can change whether work should continue, stop, or return to a human.

5. AI context and evaluation state

Retrieval chunks, embeddings, prompt context, feature rows, recommendation records, evaluation cohorts, and durable operational memory. Some artifacts should be rebuilt; others should remain immutable but receive a correction link and exclusion status.

6. Communications and public surfaces

Drafts, sent messages, call scripts, web pages, listings, documents, and vendor notifications. A sent message cannot be unsent. Its disposition may be correction notice, annotation, targeted follow-up, or no further action under a documented threshold.

7. Executed real-world actions

Access changes, work performed, money moved, notices posted, customers contacted, or decisions approved. Data replay must never be confused with physical reversal. These effects require an accountable human disposition.

The closure is versioned because dependencies change. dependency_snapshot_id identifies what was inspected. closure_query records how it was built. known_gap records what could not be enumerated. A correction packet with an undocumented consumer gap is not complete; it is qualified.

Give every consumer a typed disposition

“Update downstream systems” is not executable. Each consumer should receive one disposition from a small controlled vocabulary:

• replace — write the governing assertion into a mutable consumer;
• recompute — regenerate a derivative from qualified inputs;
• retract — mark an artifact as no longer eligible for use;
• invalidate — force a cache, index, retrieval object, or decision input to be refreshed;
• replay — rerun a bounded, idempotent process against the corrected assertion;
• annotate — preserve an immutable historical artifact and attach the correction;
• notify — send a governed correction notice to an affected recipient;
• quarantine — remove the consumer from decision use until qualified;
• no action — retain the consumer with an explicit reason and authority;
• cannot reverse — escalate a completed real-world effect and record the residual.

These are operational meanings, not generic software verbs.

For structured mutations, RFC 6902 defines ordered JSON Patch operations including test, remove, add, and replace. The test operation is particularly useful for asserting the expected predecessor before change. But a successful JSON Patch says only that operations applied to a target document. It does not prove that the target was authoritative or that any derivative was repaired.

For HTTP resources, RFC 9110’s If-Match semantics can prevent a correction from overwriting a representation that changed after qualification. That is a concurrency guard, not closure evidence.

For caches, RFC 9111’s invalidation rules explain when stored responses become invalid after successful unsafe requests. Facility correction scope is wider: exports, embeddings, messages, and completed actions do not disappear because an HTTP cache was invalidated.

Typed dispositions keep those differences visible.

Tombstones have a deadline

Event-driven systems often represent deletion or retraction with a tombstone. That marker matters only if consumers can observe it before retention removes it.

The versioned Apache Kafka 4.2 log-compaction design explains keyed compaction, delete markers, offsets, and delete retention. It also exposes a critical operating lesson: a consumer that is too far behind can miss the window needed to reconstruct a valid final state from the log.

The correction contract should therefore record:

• tombstone or retraction event ID;
• topic or channel;
• partition and offset when applicable;
• retention deadline;
• consumer checkpoint before propagation;
• consumer checkpoint after propagation;
• replay source if the retention window closes;
• owner of any lagging consumer.

“Tombstone emitted” is not the same state as “all named consumers observed the retraction.”

Preserve history without serving the wrong history

Some systems use immutable files and snapshots. A correction may create a new governing snapshot while older snapshots remain intentionally queryable.

The current Apache Iceberg table specification documents snapshots, sequence numbers, optimistic concurrency, row-level deletes, retained history, and version distinctions. Versions 1 through 3 are described as complete; version 4 is explicitly under development. The lesson here is bounded: immutable history and a corrected current view can coexist, but consumers must identify which snapshot governs their task.

A correction packet should record:

• predecessor snapshot;
• candidate snapshot;
• commit condition;
• delete or replacement mechanism;
• query or report snapshot selection;
• historical-use label;
• rollback target;
• retention boundary.

An older snapshot can remain valid evidence of what the system held at the time while being ineligible for a current operating decision.

Recompute is not replay

The words are often used interchangeably, but the risk is different.

Recompute regenerates a derived artifact from corrected inputs under a named transformation version. Example: rebuild a fictional weekly exception count after a unit-state correction.

Replay re-presents an event or command to a process. Example: rerun a fictional routing workflow after correcting the facility identity attached to the event.

Recompute should declare:

• input assertion set and versions;
• transformation identity and hash;
• effective interval;
• output artifact identity;
• comparison method;
• release owner.

Replay should declare:

• original event identity;
• correction identity;
• causation and correlation identifiers;
• idempotency key;
• replay boundary;
• side effects suppressed or allowed;
• expected governing readback;
• stop condition.

Never replay an operation with physical, financial, access, or communication effects merely because the data path is technically idempotent. The business effect may not be.

Treat AI artifacts by their operational role

“Refresh the model” is rarely a useful correction instruction. Different AI artifacts need different treatment.

Retrieval content

Invalidate the obsolete chunk, preserve its version for audit when allowed, rebuild the current chunk from the governing assertion, update the retrieval manifest, and test that the old assertion is no longer returned for current-state questions.

Embeddings and indexes

Record the source version, embedding or index version, deletion or invalidation receipt, rebuild job, and query readback. Vector deletion is not proof that every cached answer or exported index changed.

Recommendation records

Do not rewrite a historical recommendation as though the model had seen the corrected fact. Preserve the original input envelope, mark the recommendation affected, and create a separate reevaluation record if useful.

Evaluations

If a corrected assertion changes cohort membership, label, ground truth, or outcome status, do not silently edit the score. Version the evaluation dataset, recompute eligible measures, and disclose the correction boundary.

Durable memory

Invalidate or supersede the affected memory item, propagate the new authority and version, and test retrieval under the decision context where the old assertion mattered.

The JSON Schema Draft 2020-12 Core specification can help validate that a correction packet contains required structural fields. Schema conformance cannot prove the dependency graph is complete or that the governing assertion is true.

The NIST AI RMF 1.0 frames AI risk work across Govern, Map, Measure, and Manage. The NIST AI 600-1 generative-AI profile adds cross-sector considerations around provenance, monitoring, feedback, incident response, and information integrity. Both are voluntary. In this method they support disciplined questions, not certification or a claim that an AI system is safe.

Use a seven-stage correction state machine

I recommend seven states.

1. Detected

A possible wrong assertion is reported. No correction is yet assumed.

2. Qualified

The exact subject, predicate, predecessor, candidate, authority, evidence, effective time, confidentiality, and consequence class are named.

3. Scoped

The dependency snapshot is frozen. Every known consumer receives a proposed disposition, owner, deadline, and readback method. Known gaps are explicit.

4. Authorized

The governing source owner and consequence-qualified reviewers approve the exact packet. High-consequence replays or notices require separate authority.

5. Propagated

The approved dispositions execute with idempotency and receipt capture. Failures stay open; success in one consumer does not advance another.

6. Read back

Named queries, views, reports, retrieval tests, workflow states, public surfaces, and affected records are checked independently of the write response.

7. Reconciled

The packet records completed consumers, unresolved residuals, nonreversible effects, notices, exceptions, and the next review date. Only then can the correction close.

This state machine prevents a common reporting error: treating “accepted for processing” as “correct everywhere.”

The minimum correction packet

The companion correction propagation register expands the fields, but the minimum packet is small enough to inspect:

• correction ID and status;
• subject and fact path;
• superseded and governing assertion IDs;
• prior and corrected values or protected hashes;
• discovery, effective, recorded, authorized, executed, and readback times;
• correction reason and evidence reference;
• correction authority and approval scope;
• dependency snapshot and query;
• consumer identity and class;
• disposition and consequence class;
• transformation, snapshot, event, or index versions;
• idempotency and concurrency control;
• execution receipt;
• governing-output readback;
• rollback or compensating action;
• residual, exception owner, and review date;
• fictional or production-data flag;
• evidence boundary.

Sensitive values do not belong in a broad correction register. Store a protected reference or hash when the value itself is private, financial, access-related, or customer-specific.

The companion runbook turns these fields into stop, qualification, scoping, authorization, propagation, readback, and reconciliation gates. The control-plane diagram shows the full assertion-to-consumer path. A Draft 2020-12 teaching schema and conforming fictional instance make the packet mechanically inspectable without suggesting that structural validation establishes operational truth.

A fictional walkthrough

A fictional manager reports that FAC-FIC-004 was labeled as offering 24/7 access for a period when the governing approved schedule was 06:00–22:00.

The correction owner does not immediately push a new value everywhere.

First, the owner qualifies the source evidence and effective interval. Second, the team freezes dependency snapshot DEP-FIC-029. It identifies a public-hours projection, a call-center export, an internal briefing, a retrieval chunk, two unsent message drafts, one already-sent message, and an immutable recommendation record.

The dispositions differ:

• replace the current public-hours projection;
• recompute the call-center export;
• retract the internal briefing;
• invalidate and rebuild the retrieval chunk;
• replace the unsent drafts;
• send a correction notice only if the message owner confirms the already-sent message crossed the defined consequence threshold;
• annotate the immutable recommendation record and exclude it from current-state evaluation.

The team then reads back the governing public view, export row, retrieval result, draft content, and recommendation status. The sent message remains a residual until its owner chooses and records a disposition.

The correction is propagated, but not reconciled, until that residual is resolved or accepted under explicit authority.

Nothing in this fictional walkthrough asserts that a real facility had incorrect hours, that a specific system exists, or that any customer was affected.

Tests that catch false closure

The companion readiness suite covers beginner through architect cases. The most valuable tests are the ones that make a technically successful correction fail operationally:

• predecessor changed after qualification;
• candidate authority is missing;
• effective time is unknown;
• one consumer has no owner;
• cache invalidated but export not rebuilt;
• metric recomputed under a different transformation version;
• tombstone retention expires before a consumer catches up;
• replay reissues a message or access side effect;
• retrieval index is rebuilt but old response cache persists;
• immutable recommendation is silently rewritten;
• public page changes but structured data does not;
• one readback queries a replica older than the correction;
• correction notice is sent but delivery is unknown;
• source is corrected but a real-world effect cannot be reversed;
• all writes succeed but the governing output still shows the predecessor.

These are not edge cases. They are the difference between a corrected record and a corrected operation.

An operator exercise

Choose one low-risk fictional assertion, such as a made-up office-hour label.

1. Assign it a subject, predicate, version, effective time, source, and authority.
2. Draw seven consumer classes and add at least one fictional consumer to four of them.
3. Change the assertion and preserve both predecessor and candidate identities.
4. Give every consumer exactly one typed disposition.
5. Name the write receipt and the independent readback for each.
6. Add one immutable historical artifact and one nonreversible action.
7. Decide what evidence is required for reconciliation.
8. Introduce a second correction before the first finishes. Decide whether to stop, merge, or supersede the packet.

If the exercise ends with “the field is fixed,” the dependency closure is incomplete.

What this method does not claim

The correction propagation contract is a proposed operating method. It does not prove that a dependency graph is complete, a source is authoritative, a correction is true, a consumer observed a tombstone, a replay is safe, an AI answer is repaired, a notice was delivered, or a real-world effect was reversed.

It also does not replace privacy, legal, accounting, safety, access-control, customer-communication, or incident-response review. Consequence-qualified owners remain responsible for those decisions.

What the method does is make the work inspectable. It refuses to let one successful write stand in for a corrected operation.

That is the standard operators should apply internally: not “did we change the value?” but “did every named consumer receive the right disposition, and did we read back the governing result?”

Until the answer is evidenced, the correction is still open.