Bidirectional Change-Data-Capture Adapter¶

Software or tool — instantiates Bidirectional Consistency Mapping

Captures origin-tagged changes from both sides and routes them through governed transforms.

Version: v1 · 2026-08-24 · History
Mechanism #: 797
Type: Software or Tool
Form family: Control, Automation & Runtime
Solution family: Mapping & Transformation
Problem family: Composition, Interface & Interoperability Failure
Problem subfamily: Distributed Consistency & Recombination Failure
Origin domain: Computer Science & Software Engineering
Instantiates: Bidirectional Consistency Mapping

A Bidirectional Change-Data-Capture Adapter is the always-on runtime component that watches both stores' change streams, matches each changed record to its counterpart, stamps every captured change with the side it came from, applies the correct forward or reverse transform, and hands the result to delivery. Its defining idea is that it is a transport-and-translation engine — it moves and reshapes changes; it does not decide who wins a conflict, does not test whether the pair converges, and does not remember what it already applied. Everything it emits is a well-formed, origin-tagged, transformed change; whether that change should be accepted is somebody else's judgment. It is the piece people wrongly assume is the whole system, when it is only the muscle.

Example¶

A company runs a CRM for its sales team and a separate marketing-automation platform for campaigns. A contact's job title lives in both; sales edits it in the CRM, marketing edits campaign-consent flags on their side, and both must stay corresponding. The adapter subscribes to the CRM's change log and the marketing platform's webhook feed. When a rep changes a title, the adapter reads the log entry, matches it to the marketing record by the shared external ID, tags the change origin=crm, applies the forward transform (the CRM's free-text title is normalized to the marketing platform's controlled vocabulary), and emits it downstream.

The payoff shows the moment the marketing platform writes that normalized title back into its own record and its change log fires. The adapter sees the new event — but the origin tag it carries says origin=crm, so the adapter knows this is the echo of its own write, not a fresh marketing edit, and declines to bounce it back. Setup to outcome: two stores that would have oscillated forever under a naïve connector now exchange one governed change and settle.

How it works¶

Log-based capture, both directions. It taps each side's durable change feed rather than polling for diffs, so it sees every committed change once, in order, with low latency.^[n1]
Match, then tag. Each captured change is resolved to its paired record through the shared identity scheme, then stamped with source side, object key, and a change identity before anything else touches it.
Apply the governed transform. It looks up the field's forward or reverse mapping (authored elsewhere, not invented here) and applies it, carrying the mapping version on the change.
Emit, don't adjudicate. The transformed, tagged change is handed to the delivery layer. Rejections, conflicts, and dedup happen downstream; the adapter's contract ends at "correctly captured and correctly transformed."

Tuning parameters¶

Capture mode — log-based versus polling. Log-based is lower-latency and catches every intermediate state; polling is simpler but coalesces rapid edits and can miss transient values.
Transform binding — transforms embedded in adapter config versus pulled from an external mapping specification. External binding keeps meaning reviewable but adds a lookup dependency.
Batch size and latency window — larger batches cut overhead but widen the inconsistency window and delay echo detection.
Backpressure policy — what happens when one side outpaces the other: buffer, throttle, or shed. Buffering protects ordering; shedding protects liveness.
Match strictness — how aggressively it fuzzy-matches records lacking a clean shared key. Loose matching fills gaps but risks binding a change to the wrong entity.

When it helps, and when it misleads¶

Its strength is uniformity: every change on either side is captured, identified, and transformed the same way, so origin tagging and mapping happen in one governed place instead of being reinvented per integration. That single discipline is what makes echo suppression and audit even possible downstream.

Its central failure is being mistaken for correctness. A green "delivered" light means transport succeeded, not that the pair corresponds — the adapter will faithfully propagate a stale overwrite or a lossy transform if nothing downstream stops it. The classic misuse is shipping the adapter alone and calling the integration done; the archetype's whole warning is that delivery reliability does not establish correspondence. The guarding discipline is to treat the adapter strictly as capture-and-transform and to require an idempotency ledger, a conflict policy, and a round-trip test around it before trusting the sync.

How it implements the components¶

paired_state_scope_and_identity — it resolves each captured change to its counterpart through the shared identity scheme, so a change is bound to the right entity before it is transformed.
directional_transformation_pair — it applies the forward mapping on captures from A and the reverse mapping on captures from B, carrying the mapping version with each.
causal_change_identity_and_origin — it stamps every change with source side, object key, and change identity, which is what lets the reverse path recognize an echo.

It does not implement bidirectional_conflict_and_exception_policy (that is the Synchronization Conflict Queue) or round_trip_and_convergence_test_oracle (that is the Round-Trip Property-Test Suite); the adapter emits changes, it does not adjudicate or verify them.

Instantiates: Bidirectional Consistency Mapping — the adapter is the capture-and-transform runtime the rest of the machinery depends on.
Consumes: Forward/Reverse Field-Mapping Specification for the transforms it applies; Synchronization Origin Token for the marking it stamps.
Sibling mechanisms: Dual-Write Outbox and Inbox Pattern · Idempotency and Deduplication Ledger · Field-Level Authority Matrix · Synchronization Conflict Queue

Editorial Notes¶

Form Classification¶

Form family: Control, Automation & Runtime

Rationale: Captures origin-tagged changes from both sides and routes them through governed transforms, making its operative form a state-dependent executable control that senses, filters, routes, or actuates during operation.

Independent corroboration: The frozen evidence defines Bidirectional Change-Data-Capture Adapter as 'Captures origin-tagged changes from both sides and routes them through governed transforms', so its operative form is Control, Automation & Runtime.

Review outcome: Independent reviewer agreement; high confidence.

Origin Attribution¶

Primary origin: Computer Science & Software Engineering

Origin pattern: Single lineage

Present-day reach: Specialized

Rationale: Database and distributed-systems engineering developed log-based change-data capture, origin tagging, governed transforms, and bidirectional delivery between stores.