Synchronization Origin Token¶
Protocol — instantiates Bidirectional Consistency Mapping
Marks propagated changes so the reverse path can suppress echo without discarding independent edits.
A Synchronization Origin Token is the small marker attached to every propagated change that records where it came from and which prior change it answers. Its defining idea is enabling echo suppression by provenance rather than value: when a change synchronized from A arrives at B, is written, and B's own change feed fires the resulting event, the token on that event says "origin A, in response to change c-42," so the reverse path recognizes it as an echo of its own write and declines to send it back — while a genuinely independent edit at B, carrying no such origin, still flows. It is a wire-level convention, a field carried on the change, not a store and not a decision engine. Its power and its peril are the same: it lets the system tell "this is my own reflection" from "this is a new voice" without ever comparing the values.
Example¶
In a desktop app, an editable currency field is bound both ways to a decimal domain model. A user types 1,234.5. The view propagates it to the model as 1234.50; the model normalizes and writes back the formatted string. Without provenance, the view would see the normalized write as a fresh user edit, re-propagate it, and the two would bounce. The origin token breaks the loop: the model's write-back carries origin=view, in-reply-to=edit-91, so when the binding sees it, it matches the token to its own outstanding edit and treats the write as the settled echo — not a new change. The field displays 1,234.50 and stops.
The subtlety that makes the token more than a mute flag: a moment later, a background recalculation independently changes the same field in the model. That change carries origin=model, no in-reply-to for any view edit — so the binding correctly treats it as a new value and updates the display. The token suppressed the echo without deafening the field to a real independent change.
How it works¶
- Stamp on propagation. Every synchronized change is tagged with source side, the change identity, and the identity of the change it responds to.
- Suppress by matching, not comparing. The reverse path checks whether an incoming change's origin matches an edit it just sent; a match is an echo and is dropped, regardless of value.
- Let unmarked changes through. A change with no matching origin is treated as independent intent and propagates normally — the guarantee that echo suppression does not swallow real edits.
- Carry causal context. The token includes version or causal-predecessor data, so the receiver can also spot concurrency and staleness, not just echo.
Tuning parameters¶
- Token scope — per-change, per-field, or per-transaction identity. Finer scope suppresses echoes precisely but adds marking overhead.
- In-reply-to depth — tracking just the immediate parent versus a causal chain; deeper chains catch multi-hop echoes but cost bookkeeping.
- Origin trust boundary — whether a partner's origin tags are trusted or re-derived at the edge; trusting is simpler, re-deriving is safer against a misbehaving partner.
- Suppression window — how long an outstanding edit stays echo-matchable before its token is retired; too short lets a late echo through, too long risks matching a coincidental later change.
When it helps, and when it misleads¶
Its strength is stopping echo loops without the crude mistake of suppressing every equal value — because two independent edits can legitimately produce the same value, and value-based suppression would silently eat one of them. Provenance draws the line where it actually belongs: at who caused this.[n1]
Its failure mode is over-suppression from a leaky window or a mismatched token: retire an edit's matchability too aggressively, or trust a partner's stale origin tag, and a real independent change gets mistaken for an echo and dropped — an invisible lost update. The classic misuse is using the token as the only replay defense; it suppresses reflections in flight but does not remember what was already applied. The guarding discipline is to size the suppression window to the real echo latency and to pair the token with a durable dedup store for retry safety.
How it implements the components¶
causal_change_identity_and_origin— it is the on-the-wire embodiment: source side, change identity, and in-reply-to reference carried with every propagated change.echo_idempotence_and_fixed_point_guard— its provenance match is the echo-suppression half of the guard, breaking the loop where a propagated change would be re-read as new local intent.
It does not implement the durable retry-dedup half of that guard — remembering which changes were already applied so a redelivery is a no-op is its complement, the Idempotency and Deduplication Ledger. And it carries no bidirectional_conflict_and_exception_policy or sensitive_field_minimization_boundary — surviving deletion across delayed paths is its protocol twin the Tombstone and Revocation Propagation, which preserves removal evidence rather than suppressing echoes.
Related¶
- Instantiates: Bidirectional Consistency Mapping — the provenance convention that makes echo suppression possible.
- Consumes: Idempotency and Deduplication Ledger — the durable memory that covers retry replay the token cannot.
- Sibling mechanisms: Tombstone and Revocation Propagation · Idempotency and Deduplication Ledger · Bidirectional Change-Data-Capture Adapter · Round-Trip Property-Test Suite
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Synchronization Origin Token is defined in the frozen evidence as: Marks propagated changes so the reverse path can suppress echo without discarding independent edits. Its operative deployed or enacted form is therefore Control, Automation & Runtime.
Nearest alternative: Monitoring, Sensing & Alerting — Monitoring, Sensing & Alerting 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; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Tagging updates with their source prevents loops and establishes provenance in synchronization protocols.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: marks propagated changes so the reverse path can suppress echo without discarding independent edits.
Review resolution: The blind reviewers agree that computer_science is the primary origin and differ only on alternate origin disagreement, domain reach disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain single_lineage because the combined evidence shows one traceable formative lineage. The broader reach of universal records portability separately from historical provenance; encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Replication systems prevent infinite loops by tagging each change with the identity of the node that originated it, so a server ignores changes that carry its own origin — the same idea a single server-identifier serves in log-based replication. The origin token generalizes this to a bidirectional pair: suppress by provenance, not by value, so independent edits that happen to match a value are not lost. ↩