ADR 003 — Versioned withdrawals and visible source ambiguity

Status: implemented; decision recorded 28 September 2026

Context

A correction can invalidate a published balance row or alert. Delivery retries and reordering can otherwise recreate an invalid result. Conflicting source assertions also require a visible state that does not invent authority.

Decision

Use namespaced stable output IDs and durable per-ID versions. Publish BalanceStated/BalanceRetracted and AlertRaised/AlertRetracted. Retain deletion versions indefinitely in this bounded reference example. Materialize only the highest version, atomically with the view's input position.

Add a small KeyStatusStated control output. When the highest revision of an identity has multiple canonical payloads, freeze the key's business computation and mark it BLOCKED. Retain input evidence. A unique higher revision can resolve the conflict; then refold the entire key, publish repairs, and publish READY afterward.

Alternatives

Physical deletion without a version permits stale-message resurrection. First-arrival or hash-based conflict resolution invents source authority. Silently dropping conflicts lets an apparently clean view conceal an uncertified business result.

Consequences

Publication is at least once; current-state materialization is idempotent and version-aware. Not every intermediate output version must be applied. Multi-row repairs remain asynchronously visible, and a retraction does not undo external action.

Change-attribution fields identify the source assertion that caused an output revision. They are not a complete dependency graph. Full reconstruction still depends on source history and immutable configuration.

Review trigger

Any tombstone cleanup, new irreversible downstream action, or live cross-namespace cutover needs a separate protocol before this decision can be relaxed.