srDB POC
← All ADRs

ADR-003 — Shadow IBOR (reconcile to ABOR) over straight IBOR replacement

Status: Accepted (POC). Date: 2026-05-28.

Context

The JD calls out "Shadow IBOR reconciled to ABOR" as a headline requirement. There are two distinct architectural reads:

  • Replacement IBOR. srDB becomes the system of record for positions; the old IBOR is retired; ABOR (Accounting Book of Record) is recomputed downstream from srDB. This is the cleanest end-state and what most "modern data platform" pitches default to.

  • Shadow IBOR. srDB runs in parallel to the existing IBOR. ABOR remains the system of record. srDB reconciles to ABOR continuously and reports breaks. The IBOR replacement is a separate, multi-quarter program; the substrate is useful from day one without requiring it.

Real ops teams in alternative asset managers spend most of their time investigating breaks between books, not on green-field architecture. A substrate that makes break investigation faster — typed break categories (PRICE / QUANTITY / CLASSIFICATION / MISSING_IN_ABOR), bitemporal lineage to defend a position's value, break carry-forward so the same break doesn't get re-investigated daily — earns its keep before any replacement decision is made. A substrate that requires the replacement before delivering value is a multi-year bet with no proof points.

The role this artifact targets is player-coach, with explicit responsibility for building the team. A Shadow-IBOR posture is a hire-and-grow narrative: start with reconciliation analytics (week 1), add scenario analytics (month 3), evaluate replacement (month 12 or later) once the substrate has earned trust. A Replacement-IBOR posture is a single load-bearing program that the new lead would have to defend in the first quarter against every accounting and audit stakeholder.

Decision

srDB is the substrate; ABOR remains the system of record during POC and Phase 2. The reconciliation pipeline produces typed breaks in a four-table model (reconciliation_run → reconciliation_pair → reconciliation_break, plus an abor_position_feed mirror table). Break categories are PRICE / QUANTITY / CLASSIFICATION / MISSING_IN_SRDB / MISSING_IN_ABOR. The logical_break_key (entity + instrument + category) lets the same break be carried forward across runs without re-investigation — n_breaks_new=0 on a re-run is a first-class metric.

Replacement is explicitly Phase 3+ work, gated on (a) ops trust earned through Shadow operation, (b) accounting sign-off on srDB's mark lineage as defensible, (c) audit firm acceptance of bitemporal lineage as adequate.

Consequences

Positive:

  • The substrate is useful on day one. Ops gets a daily break report. Risk gets cross-asset scenario analytics. Audit gets bitemporal lineage. None of this depends on retiring IBOR.
  • Break carry-forward (the n_breaks_new=0 invariant from T15 gate G3) is a real, demonstrable trust-building artifact. A break that's been investigated and confirmed-OK stays confirmed-OK on every subsequent run.
  • The replacement decision becomes evidence-based rather than vision-based. By the time it's on the table, the team has months of break data showing where srDB and ABOR disagree, which side was right, and what the migration cost would actually be.
  • Org design follows. The first hire is a reconciliation/ops-facing data engineer, not a migration architect. The second is a quant dev to extend engineering identities. Replacement architects come last, when the case for them is made.

Negative:

  • Two books to maintain. The ABOR mirror table requires a feed from the ABOR system (real or, in POC, synthesized). Ops has to maintain reconciliation tolerances, exception workflows, sign-offs.
  • Disagreements between srDB and ABOR require explicit resolution. "srDB says $5.1M, ABOR says $5.15M, which is right?" doesn't have a free answer. The bitemporal lineage helps (you can see the source observation and vintage on the srDB side) but the process discipline still has to exist.
  • The "modern data platform" pitch is less crisp. Stakeholders who expected replacement may read Shadow IBOR as scope reduction. The framing has to make clear that Shadow IBOR is the prerequisite path to replacement, not the abandonment of it.

Alternatives Considered

  • Replacement IBOR from day one. Cleanest end-state, worst opening move. Requires accounting + audit sign-off before any business value is delivered. Single point of failure if any stakeholder withholds approval. Multi-quarter delay before the substrate starts paying back.
  • srDB as analytics-only sidecar (no ABOR feed). Substrate exists but never reconciles to anything. Loses the JD headline. Ops gets no value from it; only quant gets value, and even that's limited because positions are uncorroborated.
  • One-way feed srDB → ABOR (srDB drives ABOR). Inverts the system-of-record. Same trust requirements as Replacement IBOR but harder to back out of if disagreements surface. Worst of both: looks like Replacement to stakeholders, fragile to operate.