Parallel Run Reconciliation¶
Comparison procedure — instantiates Encapsulated Substitutability
Runs the incumbent and the substitute side by side on the same live inputs for a bounded window and reconciles every divergence before committing to the swap.
Recorded tests can only replay the inputs you thought to capture; Parallel Run Reconciliation validates the substitute against the live incumbent instead. For a bounded window, both the old and the new component process the same real production inputs simultaneously — the incumbent stays authoritative — and their outputs, latencies, error rates, and workflow paths are reconciled entry by entry. Its defining move is that the comparison happens on actual traffic under actual load, so it catches the divergences that only real-world data and volume reveal; and every discrepancy it finds is dispositioned into a running ledger — fixed, or accepted as an explained exception with an owner — until the unexplained backlog clears and cutover is safe.
Example¶
A company is replacing its payroll system. For two full pay cycles, the new system runs in parallel with the old: both compute every employee's gross pay, tax withholding, benefit deductions, and net pay from the same real inputs, but only the old system's numbers actually pay anyone.
Reconciliation compares the two line by line. About 98% match exactly; the rest are investigated — a wage-garnishment rule the new system applies differently, a rounding difference in a pre-tax deduction, a state-tax edge case for a handful of remote workers. Each divergence is either fixed in the new system or logged as an accepted, explained exception with a named owner and a revisit date. Only when a full cycle runs with zero unexplained divergences does the team cut over — and because the incumbent was authoritative the whole time, a bad week in the new system never mispaid a single person.
How it works¶
- Stand up the twin. Bring the substitute up alongside the incumbent, populated with the state it needs to process the same work (see State Migration Playbook).
- Fan out the same inputs. Feed both components identical live inputs across a window spanning at least one full business cycle, with the incumbent remaining the system of record.
- Reconcile on a schedule. Compare outputs, timing, and error behavior; classify each divergence by cause and severity.
- Disposition and gate. Fix real defects, or record acceptable differences as explained exceptions with an owner; gate cutover on the unexplained-divergence backlog, not on the calendar.
Tuning parameters¶
- Window length — how many full business cycles both run. Longer windows catch periodic and month-/year-end events but double operating cost and delay the swap.
- Traffic coverage — shadow all inputs or a representative sample. Full coverage catches rare cases; sampling is cheaper but can miss exactly them.
- Reconciliation granularity — reconcile totals, or every line and field. Finer comparison exposes offsetting errors that nets would hide, at more effort.
- Exit criterion — how close to zero unexplained divergence before cutover. Stricter is safer but risks chasing noise indefinitely.
- Write-off authority — who may accept a divergence as an exception. Loosen it and reconciliation moves fast but rubber-stamps; tighten it and every diff escalates.
When it helps, and when it misleads¶
Its strength is that it validates the substitute on real production inputs and real load — the messiness that recorded corpora and synthetic tests miss — while a safe fallback is guaranteed, because the incumbent is still the one doing the work. It produces an auditable ledger of exactly where old and new differ.
Its cost is real: you operate two systems at once, and it only exercises the scenarios that actually occur during the window — a rare annual event outside it stays untested. Reconciliation fatigue is the classic failure: hundreds of small diffs breed a habit of waving them through as "probably fine." And it is easily run backwards — shortening the window or writing off divergences to hit a cutover date fixed in advance. The discipline that keeps it honest is to require at least one full representative cycle, disposition every divergence to a named owner, and gate the swap on the ledger clearing rather than on the schedule.[n1]
How it implements the components¶
Parallel Run Reconciliation fills the live-comparison side of the archetype — the components a dual-operation procedure operates:
parallel_run_window— the mechanism is the bounded window of concurrent operation, with the incumbent authoritative and the substitute shadowing it.substitution_exception_register— reconciliation dispositions each divergence into a register of accepted, explained exceptions (with owner and revisit date) versus blockers that must be fixed before cutover.
It does not produce the offline, recorded-reference evidence — that is conformance_evidence_harness and observable_behavior_specification in Golden Master or Trace Comparison — nor set up the substitute's durable state, which is state_and_context_transfer_rule in State Migration Playbook; this procedure consumes both and compares the results live.
Related¶
- Instantiates: Encapsulated Substitutability — proves on live traffic that a substitute preserves behavior before the incumbent is retired.
- Consumes: State Migration Playbook supplies the state the substitute needs to run the same work; Capability Equivalence Matrix supplies the criteria for which divergences matter.
- Sibling mechanisms: Golden Master or Trace Comparison · State Migration Playbook · Service-Level Regression Monitor · Supplier or Model Homologation · Contract Test Suite · Capability Equivalence Matrix · Adapter or Facade Layer · Blue-Green or Canary Replacement · Dependency Injection or Plugin Slot · Fallback Switch or Kill Switch
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Parallel Run Reconciliation operates as an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation because it runs the incumbent and the substitute side by side on the same live inputs for a bounded window and reconciles every divergence before committing to the swap.
Independent corroboration: The frozen evidence defines Parallel Run Reconciliation as 'Runs the incumbent and the substitute side by side on the same live inputs for a bounded window and reconciles every divergence before committing to the swap', so its operative form is Experiment, Test & Rehearsal.
Nearest alternative: Protocol, Workflow & Routine — Parallel Run Reconciliation includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is an active test, trial, simulation, drill, or rehearsal that generates evidence through a deliberate attempt or perturbation.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Accounting & Auditing
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Reconciling every difference between incumbent and substitute outputs descends from accounting control and parallel-book conversion.
Related originating lineages:
- Computer Science & Software Engineering — Parallel Run Reconciliation is most directly rooted in computer science and software engineering's formal and practical treatment of computation, interfaces, data, and reliable systems. The lineage fits its defining practice: Runs the incumbent and the substitute side by side on the same live inputs for a bounded window and reconciles every divergence before committing to the swap.
- Engineering & Design — Parallel Run Reconciliation also draws materially on engineering and design's traditions of specification, testing, reliability, control, and physical-system construction, which shaped this mechanism rather than merely adopting it as an application.
Review resolution: Authoritative-source research resolves the primary-origin disagreement in favor of accounting auditing. Financial Audit Manual — U.S. Government Accountability Office documents the formative practice or theory represented here. The retained alternate domains identify material co-development or translation, while current applicability is recorded separately as domain_reach=multi_domain; origin_mode=cross_disciplinary_synthesis describes the historical relationship among lineages.
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¶
A parallel run can only see what happens during its window, so it pairs naturally with Golden Master or Trace Comparison, which can replay rare or historical cases the window will never produce. Where a Blue-Green or Canary Replacement sends a fraction of traffic to the new component and trusts its output, a parallel run sends all of it to both and trusts only the incumbent — validation, not yet rollout.
[n1] Parallel running is one of the classic system-changeover strategies — alongside direct ("big bang"), phased, and pilot changeover — distinguished by operating old and new together until the new one is trusted. Its safety comes from the retained fallback; its cost is the duplicated operation. ↩