Competitive analysis — dual-run parity harness

2026-07-18 · Author: Fable. Scope: template §7 (competitive/alternative-solution analysis), reinterpreted for an internal product. Inputs: 00-context-brief.md, initial-recommendation.md, discovery notes d1 (OSS/commercial landscape), d2 (case studies), d6 (verification-science evidence).

Internal-product framing used throughout: “competitor” = a tool or process we could adopt instead of building the parity kernel. “Buyer” = program gate approval (Tomas Zaruba signs the scope contract; Robert signs the build-vs-buy call). “Procurement” = getting an OSS/commercial dependency through security review and onto the 4-person strike unit’s toolchain. “Churn” = a builder or agent bypassing the harness because it produces more noise than signal. “Pricing” = engineering weeks + agent-token spend, not dollars-per-seat.

1. The alternative landscape

Grouped by mechanism, per d1/d2/d6. Every tool below was evaluated against the kernel definition: record HTTP+bus events → normalize → replay → diff → verdict, cross-language, against a pinned-EOL legacy estate.

1.1 OSS — in-process parallel-run (Scientist family)

github/scientist (Ruby, MIT, active), tzientist (TS port, active), Scientist.NET, laboratory (Python). Runs control and candidate in the same process, same request — wrong shape for us: legacy is a separate EOL container, and the audit doctrine forbids touching legacy’s request path (“legacy code is never ported”). Value is vocabulary (control/candidate, ignore blocks = normalization ledger’s ancestor) and a possible future in-process guardrail inside the new Encore.ts services, not a kernel component.

1.2 OSS — live triple-instance diff (Diffy lineage)

twitter-archive/diffy (Apache-2.0, archived 2020-07-02 by Twitter itself, “outdated tech stack”) and opendiffy/diffy (CC BY-NC-ND 4.0 — legally blocked for Groupon, forbids commercial use/derivatives; functionally stalled since its 2023-09 release, dependency bumps only). Mechanism: multicast live traffic to primary/secondary/candidate, use primary-vs-secondary natural disagreement as a statistical noise floor. Assumes same-language, always-live, horizontally-scaled HTTP services — none of which describes a pinned-EOL Ruby/JRuby estate that can’t be casually kept “always on.” The design (relative-disagreement-rate noise floor, default-off for mutating verbs) is reusable prior art; the code is not (license + archival + architecture mismatch).

1.3 OSS — live-vs-recorded diff (Hoverfly diff mode)

SpectoLabs/hoverfly (Apache-2.0, active). Forwards a live request to one real service and diffs against a stored simulation — architecturally closer to our shape (two-way, recorded baseline) than Diffy’s three-live-instance model. No MBUS concept, no verdict/severity model, no normalization ledger, Go-native (external-process dependency, not a library).

1.4 OSS — HTTP record/replay substrate

mitmproxy (MIT, most mature/active tool in the whole survey, 44k stars, pushed 2026-07-18), probelabs/goreplay (LGPLv3 core; binary-protocol/keep-alive replay — the parts we’d want for MBUS — gated behind a commercial Pro tier), keploy/keploy (Apache-2.0, eBPF syscall capture, very active; a test-generation tool, not a parity tool, and eBPF-vs-JRuby-1.7/Ruby-1.9.3 compatibility is unverified). None diff two systems; all are capture/replay substrate only.

1.5 OSS — service virtualization (lab dependency isolation)

WireMock, Mountebank, Hoverfly simulate mode. Stub servers, not diff engines — useful for isolating what legacy calls out to (payment gateways etc.) so the legacy lab boots deterministically, not for the candidate-vs-legacy comparison itself.

1.6 OSS — Ruby-native record/replay

VCR/WebMock — idiomatic Ruby HTTP-interaction recording, language-matched to 702k LOC of the legacy estate. Narrow but real use: isolating the legacy lab’s own outbound dependencies, not the cross-system kernel.

1.7 Live traffic mirroring infra (not diffing)

Envoy request_mirror_policies, Istio traffic mirroring, nginx ngx_http_mirror_module, AWS VPC Traffic Mirroring. All “fire and forget” — mirrored responses discarded, zero diff/verdict logic. Wrong layer; if used at all, belongs to Zaruba’s production-infra plane, not the harness.

1.8 Contract testing — Pact

Consumer-driven contract testing (very actively maintained family). Design-time schema agreement, not production-traffic behavioral diffing. Different problem, healthy tool for that different problem — not a parity-kernel candidate.

1.9 Golden-master / approval testing

ApprovalTests family (Java/.NET/C++, active). Capture output, human approves as new baseline, future runs fail on divergence until re-approved. Closest existing pattern to our human-decision step (DIVERGED → real regression / acceptable difference / add normalization rule, decision recorded) — worth stealing the approval-workflow data model, not the capture/diff engine (it has none for cross-system HTTP+bus comparison).

1.10 Commercial — Speedscale/proxymock, Signadot

Both are live-shadow, Kubernetes/service-mesh-native products. Free tiers are local-dev-only; anything resembling cluster-scale capture+replay+diff is Enterprise-gated. Neither fits a pinned-EOL-Docker legacy estate booted ad hoc rather than a long-running K8s deployment.

Enterprise procurement friction for a 4-person program (principle-based simulation, not vendor-confirmed): Signadot/Speedscale Enterprise pricing is not published; a real evaluation would require (a) a security review of a closed-source control plane touching PII/PCI-adjacent traffic, (b) a paid trial commitment before knowing if the K8s-native routing model even applies to lab-booted EOL containers, (c) a champion inside a 4-person strike unit spending weeks on a vendor POC instead of Orders-flagship work, with no guarantee the model transfers. For a team this size, on this schedule (dual-run live by week 6), that lane realistically does not close before the flagship gate regardless of technical fit. Decision: do not spike commercial shadow platforms before M2; revisit only if live-shadow is later confirmed load-bearing for the ledger gate (§3).

1.11 Message-bus (JMS/STOMP/Kafka) parity — confirmed empty

No OSS or commercial tool diffs two systems’ bus events against each other. Kafka testing frameworks exist (verify one app’s own usage); Keploy/Speedscale claim some Kafka capture; nothing touches JMS/STOMP. This is not a gap in the research — it’s a gap in the market. Shadow-taps are 100% custom build, budgeted as the single highest-uncertainty leg of the kernel.

1.12 Non-tool alternatives

Zaruba’s per-domain oracles only (do less): merchant-accounting’s reconciliation.service.ts + crossCheckRange — ~300 LOC, one domain slice, already exists. Extending this pattern domain-by-domain without a shared kernel is a real alternative to building a generic harness at all.
100%-existing-test-suite gate (Bun pattern): per prior web research, Anthropic’s Bun port used “100% of existing test suite passes” as its gate — no dual-run machinery. Cheap, well-precedented at ~1M LOC / <2 weeks scale, but requires the old system to already have a trustworthy test suite — the legacy estate mostly doesn’t (that’s why characterization/golden-master testing exists as a category).
Test-impact analysis only: the TDAD result (6.08%→1.82% agent regression rate, ~70% relative reduction) — cheap, agent-native, but single-study/uncorroborated/off-domain (SWE-bench, not a 1M-LOC legacy migration) per d6 Q7. Already named in the context brief as the fallback if the harness “becomes the schedule.”
Manual QA panel: human testers exercise both systems and sign off. TSB’s negative-control evidence (§9, d2) is direct disconfirming evidence for this as the sole gate at financial stakes: nine successful dress rehearsals plus board sign-off still produced a catastrophic live failure — rehearsal-scale human judgment did not transfer to full-scale reality.
Contract tests only (Pact): guarantees API-shape stability between old and new callers, says nothing about behavioral equivalence. Complementary, not sufficient.

2. Per-alternative profile and comparison matrix

Target user / mechanism / strengths / weaknesses / risk / switching cost / what’s left open, for the alternatives that could plausibly be proposed instead of the kernel.

Alternative	Target user	Mechanism	Strengths	Weaknesses	Adoption/maintenance risk	Switching cost	Leaves open
Scientist family	In-process refactors	Live dual-execution, same runtime	Mature, MIT, active ports incl. TS (tzientist)	Same-process assumption; can’t bridge EOL-container ↔ Encore.ts boundary	Low (healthy projects) but architecturally inapplicable	Low to adopt narrowly (future in-Encore guardrail only)	Entire cross-system kernel
twitter-archive/diffy (as code)	Live HTTP triple-instance	3-way multicast + statistical noise floor	Best-documented noise-cancellation design found anywhere	Archived 2020, author-abandoned, Apache-2.0 so no legal block but zero support; assumes always-live legacy capacity we don’t have	High if forked as infra (dead upstream); low if used only as design reference	Design-reference use: zero. Fork-and-maintain use: high (inheriting a 5-year-dead Scala/Finagle codebase)	MBUS entirely; recorded-replay mode; verdict/evidence-bundle format
opendiffy/diffy	—	same as above	—	CC BY-NC-ND — legally blocked for commercial use	N/A — not usable	N/A	N/A
Hoverfly diff mode	Live-vs-recorded HTTP diff	Compare live response to stored simulation	Closest OSS architectural match to “fixture vs fresh response”; active, Apache-2.0	No MBUS, no verdict model, no normalization ledger, Go dependency	Low (active project)	Medium — usable as one leg (HTTP diff), not the pipeline	Bus events, verdict semantics, PII masking, legacy lab
mitmproxy	HTTP capture/replay substrate	Scriptable TLS proxy, client/server-side replay	Most mature/active tool surveyed, MIT, Python-scriptable	No diff/verdict layer at all — pure substrate	Very low	Low — genuinely composable into our own pipeline	Everything past capture: normalize, diff, verdict, MBUS
GoReplay	HTTP capture/replay at scale	Packet-level capture + replay	Proven at scale (19k stars), LGPLv3 core usable	Binary-protocol/keep-alive replay (what MBUS work would need) is Pro-only paid tier; 341 open issues (support-strain signal)	Medium (Pro-tier lock-in risk if we lean on it)	Medium	MBUS, diff, verdict
Keploy	Auto test/mock generation via eBPF	Kernel-level syscall capture	Extremely active (releases weekly), Apache-2.0	Not a parity tool by design (generates one service’s own tests, not a 2-system diff); JRuby 1.7/Ruby 1.9.3 compatibility unverified	Medium (unverified on our exact stacks — spike needed)	Medium-high if bet on before spiking	Diff/verdict, MBUS, EOL-runtime validation
VCR/WebMock	Ruby lab-dependency isolation	Record/replay a Ruby process’s own outbound HTTP	Language-matched, mature, low risk	Narrow scope (lab hygiene only, not cross-system)	Very low	Low	The entire kernel — this solves a sub-problem only
WireMock/Mountebank	Legacy-lab dependency stubbing	Canned HTTP/TCP responses	Mature, isolates lab boot from transitive legacy deps	No diff capability; Mountebank’s TCP imposters are conceptually adjacent to MBUS stubbing but unproven for JMS/STOMP	Low	Low	Diff/verdict, real MBUS shadow-tap
Signadot / Speedscale Enterprise	Live K8s shadow traffic	Routed live-traffic shadow, real-time compare	Real, maintained, closest commercial fit to “shadow testing”	Closed-source control plane; K8s/mesh-native (legacy estate is pinned EOL Docker booted ad hoc, not a live K8s deployment); Enterprise-gated; procurement friction (§1.10)	High — vendor dependency for auditable evidence QSA/SOX must trust	High (full re-architecture around vendor’s routing model)	MBUS entirely; EOL-lab fit unverified
Pact	API-shape contract stability	Consumer-driven contract verification	Very active, mature, different-but-real problem solved well	Not a behavioral-diff tool at all	Low (as a complementary tool)	Low to add alongside, doesn’t replace kernel	Everything the kernel is for
ApprovalTests family	Golden-master approval workflow	Human approves baseline; diverge = fail until re-approved	Best existing model for our human-decision/audit-trail step	No capture, no cross-system diff, no MBUS	Low	Low (steal the data model, not the code)	Capture, replay, MBUS, verdict engine
Zaruba’s oracles only (do-nothing-generic)	Merchant-accounting domain	Feed vs. ledger vs. consumption anti-join	Already exists, already trusted, zero new build	Doesn’t generalize (1 domain, ~300 LOC); no legacy lab, no MBUS shadow-tap, no HTTP capture — repeats bespoke effort per domain forever	Low risk today, high risk at scale (16/33 repos are MBUS-coupled; this pattern has no bus story)	N/A (status quo)	Everything outside merchant-accounting
100%-test-suite gate (Bun pattern)	Whole-program cutover confidence	Existing test suite must fully pass	Cheap, precedented at similar LOC scale	Requires a legacy test suite worth trusting — mostly absent here (why characterization testing exists as a category)	Medium — false confidence if legacy tests are thin/stale	Low to run, but doesn’t produce counterexamples or an evidence bundle	Auditor-grade evidence, MBUS parity, DIVERGED root-causing
Test-impact analysis only	Agent regression triage	Graph-based impact selection, run only affected tests	Cheap, agent-native, precedented direction (TDAD)	Single uncorroborated study, off-domain benchmark (SWE-bench, not legacy migration); answers “did I break something,” not “does this match legacy”	Medium (evidence strength)	Low	Legacy-behavior verification entirely — different question
Manual QA panel	Human sign-off	Testers exercise both systems, judge equivalence	No tooling cost	TSB: 9 rehearsals + board sign-off + 1,600-person pilot still failed catastrophically at full scale — direct negative evidence at financial stakes	High (schedule-pressure collapse is the documented failure mode)	N/A	Everything a machine-checked gate provides

Hard-requirements matrix

Columns are the harness’s non-negotiable requirements (context brief + initial recommendation). ✓ = meets natively, ~ = partial/needs extension, ✗ = does not meet, — = not applicable to this tool’s scope.

Alternative	EOL-lab compat	Bus-event parity	Deterministic verdicts	Auditor-grade evidence	Agent-consumable output	Per-domain adapter cost
Scientist family	✗ (same-process)	✗	~ (match/mismatch, no severity model)	~	~ (structured logs)	High — wrong shape, needs full reinvention
twitter-archive/diffy	✗ (assumes always-live)	✗	~ (statistical, not per-field)	✗ (no evidence-bundle concept)	✗	High
Hoverfly diff mode	~ (HTTP only)	✗	~	✗	✗	Medium — one leg only
mitmproxy	~ (capture only)	✗	— (no diff logic)	—	—	Medium — substrate only
GoReplay	~ (OSS tier HTTP only)	✗ (Pro-gated)	—	—	—	Medium-high (license risk)
Keploy	~ (unverified on EOL)	~ (Kafka claimed, unverified)	—	—	~ (YAML fixtures)	Medium — spike required
VCR/WebMock	✓ (lab hygiene)	✗	—	—	—	Low, narrow scope only
WireMock/Mountebank	✓ (lab hygiene)	~ (TCP imposters, unproven)	—	—	—	Low, narrow scope only
Signadot/Speedscale	✗ (K8s-native)	✗	~	✗ (closed-source)	~	High — procurement + re-architecture
Pact	—	—	✓ (contract-level)	~	✓	Low, different problem
ApprovalTests	✗	✗	✓ (approval workflow)	✓ (versioned baselines)	~	Low, steal pattern only
Zaruba’s oracles only	✗ (no lab)	✗	✓ (in-domain)	✓ (in-domain)	~	N/A — repeats per domain
100%-test-suite gate	✗	✗	✓ (pass/fail)	~ (no counterexample)	✓	Low, but weak signal
Test-impact analysis	—	—	✓ (own axis)	~	✓	Low
Manual QA panel	~ (human judgment)	~ (human judgment)	✗ (TSB evidence)	✗	✗	High (human time, doesn’t scale)
Parity kernel (built)	✓ (designed for it)	✓ (shadow-taps, designed for it)	✓ (designed for it)	✓ (evidence bundle + normalization ledger, designed for it)	✓ (designed for it)	Designed to be Orders-adapter-first, generalize only per gate

No row clears more than 2-3 columns. This is the matrix’s own argument for BUILD — not a close call.

3. Classification question

Is the harness a standalone product, a feature of Zaruba’s plane, a workflow, or an orchestration layer?

Decisive answer: it is a standalone internal product — a workspace package + CLI/CI runner living outside Encore, with a narrow Encore-side surface (verdict rows in work-ledger). Not a feature of Zaruba’s plane, not a workflow, not an orchestration layer. Reasoning:

It has its own runtime boundary Zaruba’s plane structurally cannot host. Architect correction #4 (binding, context brief) already settled this: Encore/Cloud Run cannot run pinned EOL Docker images or tap MBUS. The legacy-runtime lab and parity kernel need a home Zaruba’s system of record does not provide. That alone disqualifies “feature of Zaruba’s plane.”
It is not a workflow. A workflow orchestrates existing capabilities; the parity kernel creates a capability (record→normalize→replay→diff→verdict) that exists nowhere in the estate today except as ~300 LOC in one domain. Zero of the surveyed tools (§1, §2) provide this pipeline; a workflow definition has nothing to route between.
It is not an orchestration layer over third-party tools, because — per the matrix — no combination of third-party tools covers the pipeline end-to-end (see §3.1 below for the closest achievable combination and why it still falls short).
It does share a boundary with Zaruba’s plane at exactly one seam: verdict rows land in work-ledger, and Zaruba’s existing oracles (merchant-accounting) are the pattern the Orders adapter generalizes. That seam is real and intentional — it is why the harness is of the program, not a bolt-on tool — but a shared seam does not make the kernel a feature of the plane it feeds.

Verdict: standalone product, Orders-adapter-first, deliberately narrow Encore surface. This matches the initial recommendation’s platform section (§12) exactly; research did not overturn it.

3.1 Minimal existing-tool combination and its ceiling

Precise combination: mitmproxy (capture + replay substrate) + Hoverfly diff mode (live-vs-recorded comparison leg) + WireMock/VCR (legacy-lab dependency isolation) + ApprovalTests’ approval-workflow data model (borrowed pattern, not code) + Diffy’s design (relative-disagreement-rate noise floor, borrowed pattern, not code).

Coverage estimate against the five-stage kernel (record → normalize → replay → diff → verdict), each stage scored against how much of it this combination actually does natively:

Record: mitmproxy — ~80% covered (HTTP only; zero MBUS).
Normalize: nothing in the combination does this natively; Diffy’s design is borrowed, not its code — 0% covered, 100% custom.
Replay: mitmproxy + Hoverfly — ~70% covered (HTTP only).
Diff: Hoverfly diff mode — ~40% covered (no severity model, no normalization ledger, no MBUS).
Verdict/evidence bundle: nothing — 0% covered natively; ApprovalTests’ data model is borrowed, not built.

Blended coverage: ≈35-40% of the kernel, entirely on the HTTP leg, entirely at fixture-vs-live granularity, zero on MBUS. This is below the “≥60%” bar the task asks to test — stated plainly: no combination of existing tools reaches 60% coverage of the kernel as defined. The honest ceiling is closer to 40%, and that 40% excludes the single highest-uncertainty leg (MBUS shadow-taps, §1.11) entirely. This matches d1’s headline finding (“no tool does the whole kernel”) and confirms — does not merely repeat — the initial recommendation’s build premise.

What is genuinely uncovered — the build core:

MBUS shadow-taps (JMS/STOMP/Kafka cross-system event diffing) — confirmed zero OSS/commercial coverage, 100% custom.
The verdict model itself (PARITY / DIVERGED / UNVERIFIABLE with severity, counterexample minimization, evidence bundle) — no surveyed tool produces this; closest analog (ApprovalTests) is a workflow pattern, not diff logic.
The normalization ledger (explicit, auditable, human-decided exclusion rules with rationale) — Scientist’s ignore blocks and Zalando’s header filters are precedent for the concept, but no tool ships a portable, auditable implementation of it.
Cross-runtime bridging (EOL Docker lab ↔ Encore.ts candidate, orchestrated as one comparison) — every surveyed tool assumes same-process (Scientist) or same-language/always-live (Diffy) or K8s-native (Signadot) topology; none assumes “boot a pinned-EOL container on demand, replay recorded fixtures, tear down.”
PII/PCI-safe fixture masking for recorded HTTP traffic — GoReplay’s masking is Pro-only paid; no free OSS tool does this for record-replay fixtures (as opposed to DB rows).

These five items are the harness’s actual product. Everything else in §1 is plumbing worth borrowing pieces from, never worth adopting whole.

4. Recurring complaints and disconfirming evidence (receipts)

Diffy’s own inventor abandoned it — Twitter archived twitter/diffy 2020-07-02, stated reason “outdated tech stack… unpractical to maintain,” reinvented internally, never open-sourced the successor. [github.com/twitter-archive/diffy README, verified 2026-07-18]
opendiffy/diffy is functionally stalled — dependency-bump-only commits since its last tagged release 2023-09-11 (checked through 2026-05-18), despite being nominally “maintained.” [gh api repos/opendiffy/diffy, 2026-07-18]
GoReplay gates the exact capability we’d need most (binary-protocol/MBUS-adjacent replay) behind a paid Pro tier, and carries 341 open issues — a soft support-strain signal even with recent pushes. [docs.goreplay.org, verified 2026-07-18]
No published false-positive rate exists for Diffy’s noise-cancellation mechanism, anywhere — searched specifically, found none. The harness cannot borrow confidence in the mechanism from Diffy’s track record; it must earn that confidence itself via the self-replay falsification recipe already in the initial recommendation. [d6 Q2]
Datafold sunset its OSS data-diff tool entirely (archived 2024-05-17, official blog post) to refocus on a commercial product — a company that built exactly this class of tool chose not to keep maintaining an open version. Out of MVP scope (DB-diffing) but a relevant durability signal for the category. [datafold.com/blog/sunsetting-open-source-data-diff, 2024-05-17]
TSB (negative control, no tooling at all): nine successful dress rehearsals + 1,600-person pilot + board sign-off still produced a catastrophic full-scale failure — the clearest available evidence that rehearsal-plus-human-judgment does not substitute for a structural machine-checked gate at financial stakes. [Slaughter and May review via TSB press release + techmonitor.ai + Computer Weekly, d2 §9]
Every credible primary-sourced financial-grade parity example found (Uber, Stripe) uses live/continuous shadow traffic, not recorded-fixture replay, for the final gate — this is a live tension with the initial recommendation’s “recorded replay first” v1 scoping, not a confirmation of it (d6 Q4). See §5 open question below.

5. What this means for the harness’s shape (decisive, not hedged)

Build the kernel. No combination of existing tools clears even 60%, let alone the honest ceiling of ~40%. This is now confirmed by direct tool-by-tool evaluation, not merely asserted from the 001 synthesis.
Borrow four specific things, adopt zero dependencies wholesale: mitmproxy as capture/replay substrate (own the diff/verdict logic on top — do not fork or wrap it as a black box); Diffy’s relative-disagreement-rate noise-floor design (not its code, which is dead/license-blocked) as one candidate mechanism for the normalization ledger, validated via our own self-replay test since Diffy never published its own accuracy numbers; ApprovalTests’ baseline-approval data model for the human-decision audit trail; WireMock/VCR for legacy-lab dependency isolation only.
MBUS shadow-taps are entirely custom-build — budget them as the highest-risk, highest-uncertainty line item in the whole plan, not a footnote. No tool, OSS or commercial, does any part of this.
The recorded-replay-vs-live-shadow tension (§4, last bullet) is real and unresolved by this document. Every comparable financial-grade cutover found in the wild used live shadow traffic for its final gate. The initial recommendation’s “recorded replay first, live shadow only where the ledger proof demands it” stance is not disproven, but it is not corroborated either — flagging this explicitly rather than resolving it here, since resolving it changes whether “live shadow” machinery belongs to the harness’s lane or Zaruba’s (context brief open question #2). Recommendation: treat recorded-replay as sufficient to de-risk M2 reads-authoritative and the early write-ramp steps; do not assume it alone clears the ≥99.999% ledger-reconciliation gate without a live-shadow component, and decide whose lane that component is in before M3, not after.
Do not spike Signadot/Speedscale before M2. Procurement friction alone (§1.10) burns weeks a 4-person program on a week-6 deadline does not have, before any technical-fit question is even answered.

Open questions

Whose lane does live-shadow machinery belong to if recorded-fixture replay cannot clear the ≥99.999% ledger-reconciliation gate alone (§5.4) — the harness’s or Zaruba’s production-infra plane? Unresolved by this document; every external precedent (Uber, Stripe) used live/continuous mechanisms for the equivalent gate, and this document does not have the authority to assign that lane.
Is there internal precedent inside repos/monorepo-development/ or Zaruba’s existing oracle code for any message-bus comparison this research should have found but didn’t? d1 confirmed the OSS/commercial market has zero MBUS-diffing tools; it did not exhaustively re-audit internal code for a bespoke precedent.
Does eBPF-based capture (Keploy) work at all against JRuby 1.7 / Ruby 1.9.3-era syscall patterns? Genuinely untested territory per d1; worth a cheap spike if Keploy is ever considered for the HTTP-capture leg, but not before the Orders-adapter build.
Diffy’s real-world false-positive rate is unpublished anywhere found (d6 Q2) — the self-replay falsification recipe (record → replay against the same legacy instance must yield PARITY) is therefore the harness’s only source of evidence for its own noise-normalization accuracy. No external tool’s track record can be borrowed to shortcut this validation.
Does the legacy estate run on infrastructure (Kubernetes, AWS EC2/VPC, a service mesh) that would make Envoy/Istio/AWS Traffic Mirroring’s routing model physically applicable at all, should live-shadow later become in-scope? Not established by this research pass (d1 §6).