Good frame, but I want to correct two things before we build on them, because both will bite us in the spec.

1. The invariant you wrote is not the invariant. Sum(Assets) - Sum(Liabilities) == Sum(Equity) is a report — a balance sheet — not something an engine can continuously assert. It's also undefined across currencies unless you've picked a translation policy (spot at event time? month-end close rate? ASC 830 CTA bucket?). The assertion that actually holds every microsecond is narrower and stronger:

• Per transaction, per currency: sum(debits) == sum(credits). No multi-currency journal entry balances without an explicit FX-gain/loss line, so the engine must refuse the entry rather than silently net it.
• Per account, over any window: closing_balance == opening_balance + sum(postings).
• Per source: sum(ledger postings tagged source=stripe) == stripe_reported_balance at a stated cut time.

That third one is the reconciliation product. The first two are just a correct ledger.

2. The hole isn't where you said it is. TigerBeetle already owns the double-entry primitive — open source, Zig, and it does debit/credit with two-phase transfers at absurd throughput. Beancount and hledger own the plaintext ledger and already have plugin hooks and balance assertions. If we ship another ledger core we are competing with those and losing. The genuinely empty square is one layer up: the ingestion + matching + evidence layer between a processor's settlement report and whatever ledger you already run. Modern Treasury and Sequence sell exactly this and there is no credible open-source equivalent. Let's build that and stay ledger-agnostic — emit Beancount directives, or postings over TigerBeetle's API, or plain SQL. Pluggable sink, not our own ledger.

Library vs daemon: library, and Python, not Rust-with-bindings. The people who will actually adopt this are one controller and one backend engineer at a Series A, and they live in pandas and Airflow. Rust buys us throughput we don't need — a marketplace doing $50M GMV at a $60 average order is ~70k transactions a month; that's 840k rows a year. DuckDB scans that in milliseconds on a laptop. Write it in Python against an embedded DuckDB/SQLite file, ship a recon CLI that wraps the same functions, and if someone shows up with 10^8 rows we rewrite the matcher — one module — later. Rust on day one costs us every casual contributor.

The failure mode nobody has named yet: time is two-dimensional. Every reconciliation engine I've seen dies on restatements, not on FX. Stripe amends a balance_transaction; a bank re-issues a CAMT.053 for a value date you already closed; a chargeback lands 45 days after you matched and cleared the original charge. If your matches are mutable rows, you have just silently changed what the books said last quarter, and an auditor asking "what did the March 31 close look like as of April 5" gets an answer that no longer exists.

So I'd make bitemporality non-negotiable in the core schema: every event and every match carries value_time (when it happened economically) and record_time (when we learned it). Matches are never updated or deleted — a new match row carries supersedes_match_id. Every match row also carries rule_id, rule_pack_version, reason_code, and the raw payload hash of both sides. Then "as of" queries are just a WHERE record_time <= ?, and the whole engine becomes replayable: same input events + same rule pack version → byte-identical match set. That property is what makes it testable, and it's the thing heuristic matchers usually can't claim.

Which means your Pass 2 and Pass 3 should not be Python functions. They should be declarative rules — data, versioned in the repo, with a tolerance and a window and a fee formula — so a user can add a rule for their PSP without forking us, and so a rule change is a diff someone can review.

One more thing I'd put in the MVP that isn't engine work at all: an open corpus of anonymized fixtures. Real CAMT.053 files, a Stripe payout with an embedded refund and a chargeback clawback, a Wise multi-currency payout with a mid-market/actual-rate gap, an Adyen batch where one payout covers 1,412 charges. Nobody has published these. Even if our matcher turns out mediocre, that corpus is the asset — it's what lets anyone else test their matcher, and it's how we get contributors.

What I don't have a good answer for: how a partial match is represented when a $12,400.13 payout covers charges summing to $12,400.00 and the 13¢ is an unexplained rounding artifact. Do we post a plenty-small suspense entry automatically under a threshold, or hard-fail? I lean hard-fail with an explicit recon accept-variance command that writes a signed, attributable adjustment — because auto-suspense under a threshold is exactly how a $0.13 bug becomes a $130,000 bug when someone bumps the threshold. Curious whether Codex thinks that's too strict for a first release.

Taking the two questions in order, and the answer to the first is: the template model as written is broken, and the 13¢ fixture is exactly what breaks it.

1. Templates must evaluate per child, and the payout entry is a closure check, not a posting

stripe_payout_settlement reads event.total_fees and event.gross_amount off the payout. But a Stripe payout isn't an event with those fields — it's a batch whose children are balance transactions of six different types (charge, refund, adjustment, dispute, dispute_fee, application_fee), each with its own fee, its own currency, and its own sign. Aggregating them into total_fees at the payout level means the engine derives net from the reported payout amount, which is the one number you must never trust, because it's the number you're reconciling against.

Worked, with the fixture pinned down:

Under the facilitator's template the engine computes net from event.net_amount = 12,400.13, debits the bank 12,400.13, and the entry balances perfectly. The 13¢ vanishes. Under per-child evaluation you get 440 entries that move 12,400.00 into clearing_stripe, one settlement entry that moves 12,400.13 out of it, and a residual clearing balance of −0.13 that the case cannot close on. That residual is the finding.

So I'd restate it as one rule: a batch case may close only when the post-export balance of its clearing account is exactly zero. Templates are keyed on canonical child event type, never on the batch. The batch contributes one settlement entry and one invariant.

2. Two schema corrections before the DDL

Money. Kill amount_cents. JPY has exponent 0, BHD and KWD have 3, and if anyone ever points a connector at USDC you need 6. Store amount_minor BIGINT plus currency CHAR(3) plus exponent SMALLINT, and never a float anywhere in the pipeline — DuckDB will happily give you 0.1 + 0.2 in a SUM if you let it.

Mutable state contradicts the append-only stance. lifecycle_state as a column on the case row is an in-place update, which is the thing we just said we don't do. Make it derived from an append-only case_state_transitions table; current state is the latest row by record_time. Same argument as matches.

And parent_case_id is too narrow. The day-45 reversal relates to the dispute case and to the original charge case, and the payout batch contains 217 charge cases. That's a DAG. One nullable parent pointer forces you to pick one edge and lose the other, then re-parent later. Use an edge table — it's four columns and it never needs a migration:

CREATE TABLE case_links (
  from_case_id  VARCHAR NOT NULL,
  to_case_id    VARCHAR NOT NULL,
  link_type     VARCHAR NOT NULL,  -- contains | reverses | corrects | settles
  record_time   TIMESTAMPTZ NOT NULL,
  PRIMARY KEY (from_case_id, to_case_id, link_type)
);

3. The replayability schema

-- what we were handed, byte for byte
CREATE TABLE source_files (
  file_id        VARCHAR PRIMARY KEY,      -- blake2b of bytes
  connector      VARCHAR NOT NULL,
  connector_ver  VARCHAR NOT NULL,
  ingested_at    TIMESTAMPTZ NOT NULL,
  byte_len       BIGINT NOT NULL
);

CREATE TABLE raw_rows (
  raw_id     VARCHAR PRIMARY KEY,          -- blake2b(file_id || row_ordinal || bytes)
  file_id    VARCHAR NOT NULL,
  ordinal    BIGINT  NOT NULL,
  payload    JSON    NOT NULL
);

-- canonical, bitemporal, append-only
CREATE TABLE events (
  event_id       VARCHAR PRIMARY KEY,      -- derived, see below
  raw_id         VARCHAR NOT NULL,
  source         VARCHAR NOT NULL,         -- stripe | mercury | adyen
  external_id    VARCHAR,                  -- bt_1P..., end-to-end id
  kind           VARCHAR NOT NULL,         -- charge | fee | refund | dispute | payout | ...
  amount_minor   BIGINT  NOT NULL,
  currency       CHAR(3) NOT NULL,
  exponent       SMALLINT NOT NULL,
  value_time     TIMESTAMPTZ NOT NULL,     -- when it happened economically
  record_time    TIMESTAMPTZ NOT NULL,     -- when we learned it
  supersedes_id  VARCHAR,                  -- restatement chain
  normalizer     VARCHAR NOT NULL,
  code_hash      VARCHAR NOT NULL
);

CREATE TABLE matches (
  match_id          VARCHAR PRIMARY KEY,   -- derived, see below
  rule_id           VARCHAR NOT NULL,
  rule_pack_version VARCHAR NOT NULL,
  reason_code       VARCHAR NOT NULL,      -- EXACT_ID | FEE_TOLERANCE | BATCH_SUM | ...
  evidence_digest   VARCHAR NOT NULL,      -- blake2b over sorted member event_ids
  record_time       TIMESTAMPTZ NOT NULL,
  supersedes_match_id VARCHAR
);

CREATE TABLE match_members (
  match_id  VARCHAR NOT NULL,
  event_id  VARCHAR NOT NULL,
  side      VARCHAR NOT NULL,              -- internal | external
  PRIMARY KEY (match_id, event_id)
);

The piece that actually buys replayability isn't the columns — it's that no id is a sequence. match_id = blake2b(rule_id || rule_pack_version || evidence_digest), event_id = blake2b(raw_id || normalizer || code_hash). Autoincrement ids make a rerun produce a diff even when nothing changed, which destroys the golden-file test suite that's supposed to be our proof of correctness.

And a determinism trap specific to our stack: DuckDB's hash joins are parallel, so candidate ordering is not stable across runs or across machines with different core counts. Any rule query that can produce competing candidates must end with an explicit ORDER BY (value_time, external_id, event_id) and pick by an explicit rank, or the same input will produce different matches on a 4-core CI runner than on the dev's 16-core laptop. That bug takes about three weeks to find.

One operational thing nobody has flagged: DuckDB is single-writer. One process holds the write lock on the file. So recon ingest running as four parallel Airflow tasks will fail, not queue. Either the CLI takes an advisory lock and serializes, or ingest writes Parquet per source and a single merge step loads them. I'd pick the second — Parquet-per-ingest is also a free append-only archive of exactly what each run saw, which is half of the audit story for nothing.

On the dispute lifecycle: I agree Case B never touches Case A. But there's a subtlety in your day-45 example — when the dispute is won, Stripe returns the $100 and reverses the $15 as two separate balance transactions in different payouts sometimes weeks apart. So "reversed" is not one state transition, it's two partial ones, and a case sitting in disputed with $100 back and $15 outstanding is a legitimate long-lived state. Whatever state machine we draw needs to tolerate partial reversal rather than treating it as an error.

Before the CLI question, three corrections — one of them undoes a decision that was just codified.

The YAML rule contradicts the two-level split we agreed on ten minutes ago

rules/stripe_payout_batch.yaml puts this in invariants:

- name: amount_match
  expression: "sum(children.amount_minor) == parent.amount_minor"

Run that against fixture 1. Children sum to 12,400.00, the payout says 12,400.13, the invariant fails, the rule doesn't fire — and therefore no case is created. You end up with 440 unmatched balance transactions and one unmatched payout sitting in a pile, which is precisely the state a controller was already in before installing us. The whole point of the case object is that the discrepancy has somewhere to live.

Matching predicates group. Closure rules assert. sum(children) == parent is a closure rule and it belongs in case_closure_rules, exactly where the two-level model put it. What the matching rule should say is only "children are the balance transactions whose payout_id equals this payout's external_id" — no arithmetic at all. Same objection kills all(children.currency == parent.currency): that predicate makes fixture 3 unmatchable, since a EUR charge inside a USD payout is the normal case, not an anomaly.

And join_key: payout_id only expresses Pass 1. Fixture 4 has no join key — a CAMT.053 line and an ACH batch share nothing but an amount and a date window. The DSL needs a second predicate form or it can only describe the easy half:

predicates:
  left:  { source: mercury, kind: credit }
  right: { source: internal, kind: ach_batch }
  match_on:
    - { field: amount_minor, op: eq }
    - { field: value_time, op: within, tolerance: 48h }
  cardinality: "1:1"
  rank_by: [abs_time_delta, event_id]   # deterministic tie-break, mandatory

FX gain/loss is not equity

Equity:FXGainLoss is wrong. Transaction-level FX gain or loss hits the income statement — Income:FX:Gain and Expenses:FX:Loss in Beancount's five-root world. The thing that lives in equity is CTA, the cumulative translation adjustment from restating a subsidiary's whole functional-currency financials under ASC 830, and we're nowhere near that. Ship the wrong root and every user's P&L is understated by their FX drift, silently, forever.

The related trap: "the explicit exchange rate derived from the processor's settlement statement." Stripe doesn't hand you a rate on a balance transaction — it hands you a presented amount and a settled amount, and the rate is implied. If you store rate = 1.0850 and recompute, EUR 100.00 × 1.0850 gives you 108.50 today and 108.4999999 the day someone touches it with a float. So: store both legs as integers, never a rate. The rate is a display artifact computed at render time from the two amounts. That also makes fixture 3's 0.40 EUR variance fall out as a real integer residual rather than a rounding argument.

Now the CLI, and the thing recon init has to guarantee

The test for recon init isn't "a workspace exists." It's that these three commands work with no credentials, no bank account, and no network:

$ recon init --with-fixture stripe_payout_with_variance
$ recon match
$ recon cases list
CASE                 TYPE           STATE              RESIDUAL
rc_a3f19c…           payout_batch   variance_pending   -0.13 USD

That's the README's first sixty seconds and it's also the acceptance test for the MVP. If it needs a Stripe key, nobody evaluates us.

Workspace layout:

myco-recon/
  openrecon.yaml          # engineer's file: sources, rule-pack pins, sinks
  accounts.yaml           # controller's file: chart-of-accounts mapping
  rules/                  # vendored rule packs, pinned by version
  archive/                # content-addressed .raw + .parquet  — SYSTEM OF RECORD
  workspace.duckdb        # derived cache, deletable
  exports/
  .gitignore              # archive/, workspace.duckdb, exports/

Two files rather than one, deliberately: accounts.yaml is reviewed by the person who owns the chart of accounts and changes at a different cadence than source config. Different reviewer, different file, different PR.

The design line I'd insist on: workspace.duckdb is a cache, not a database. recon rebuild reconstructs it byte-identically from archive/ alone. The moment that file becomes precious we have built a database, and every corrupted page, every failed migration, every "can I copy this to my laptop" is our support burden. Keep it disposable and the archive is the only thing that needs backing up.

Subcommands, flat, every read command taking --as-of:

recon init [--with-fixture NAME]
recon ingest <source> <path...>     # writes archive/, never touches the db
recon rebuild                       # archive/ -> workspace.duckdb
recon match [--rule-pack stripe@1.2.0]
recon cases list|show|explain
recon variance accept --case …
recon export beancount --out …
recon replay --from … --to …
recon check                         # exit code, for CI
recon doctor
recon close --period 2026-03 --cutoff 2026-04-05T00:00:00Z

recon check exit codes need to distinguish two very different things, because a CI job should behave differently for each: 0 everything closed; 1 open or variance_pending cases exist (normal, someone has work to do); 2 a closure invariant is violated with no case explaining it (this is the alarm — money is missing and the engine can't say where); 64 usage/config error. Collapsing 1 and 2 into "nonzero" is how the alarm gets muted by a || true in someone's Makefile.

recon close is the object nobody has named yet. Right now --as-of is a query filter, which means "the March close" is a thing you reconstruct by remembering which flags you typed. A close should be a first-class, content-addressed row that pins: the period, the cutoff record_time, the exact set of archive/ file ids in scope, every rule-pack version used, the resulting case states, and the export_digest of what was written to the ledger. Then recon close verify 2026-03 re-derives all of it and tells you whether it still reproduces. That artifact is what an auditor is actually asking for when they ask "how do you know the books are right", and it costs us one table.

Two smaller things:

Secrets and PII. openrecon.yaml holds ${STRIPE_API_KEY} style references and never a literal. Better still, the MVP shouldn't need API access at all — ingest a file the user already downloaded. And archive/*.raw will contain real IBANs and account numbers, so recon init writes the .gitignore and recon doctor hard-fails if git is tracking anything under archive/. People will otherwise commit a CAMT.053 to a public repo; it has happened to every treasury tool that shipped without that check.

The binary name is a problem. recon is thoroughly taken in the security world — recon-ng, and "recon" as a search term returns pentest tooling for pages. Anyone Googling our error messages lands in reconnaissance frameworks. I'd keep OpenRecon as the project name and ship the binary as something searchable. Not worth spending a turn on, but worth not defaulting into.

The quarantine model and the sink contract both have gaps, but there's a third thing that's more urgent: the golden-file harness as described cannot pass, ever. Let me take that first because it invalidates the proof-of-correctness plan the whole design rests on.

Wall-clock is in the hashes

source_files.ingested_at, case_state_transitions.record_time, closes.created_at, and default_as_of: now are all wall-clock. Run the fixture suite twice and every one of those differs, so "byte-for-byte equality against expected goldens" fails on run two. Worse, it fails nondeterministically — CI goes red on a rerun with no code change, everyone learns to hit retry, and the test suite stops meaning anything within a month.

Two fixes, both needed:

1. openrecon reads a clock override — --record-time on ingest, and a SOURCE_DATE_EPOCH-style env var the harness sets. Ingest defaults record_time to the statement's own date when the format carries one (CAMT.053 <CreDtTm>, MT940's statement date), falling back to now only for formats that carry nothing.
2. Wall-clock fields are excluded from every content hash. created_at can sit in close.json as a recorded fact; it must not be an input to close_id.

And this one, which was decided three turns ago and is a bug:

case_id VARCHAR PRIMARY KEY,  -- blake2b(case_type || natural_key || first_record_time)

first_record_time in the case id means ingesting the same file into a fresh workspace produces different case ids. openrecon close verify 2026-03 on a rebuilt workspace then reports every case as changed, and workspace.duckdb is a deletable cache stops being true. Drop it — blake2b(case_type || natural_key) is sufficient, because the natural key is by definition the thing that identifies the case.

Quarantine catches the wrong failure

The three examples given aren't one class. Duplicate rows parse fine — they're handled by content-addressing (raw_id = blake2b(file_id || ordinal || bytes)), not by quarantine. And the genuinely dangerous case is the one quarantine structurally cannot see: the row that parses cleanly and is wrong.

Concrete: a bank changes its CSV export and flips the sign convention on debits, or switches 1.234,56 to 1,234.56 between two downloads. Every row parses. Every row validates. quarantined_rows is 0, ingest_warning is false, and you have just booked the entire statement backwards.

What catches that is not row-level validation — it's file-level control totals, and the good news is the formats hand them to us:

• CAMT.053 carries <Bal> with OPBD opening and CLBD closing balances, plus <TxsSummy>/<TtlNtries> with entry counts and total credits/debits.
• MT940 carries :60F: opening and :62F: closing.
• Stripe's payout reconciliation report carries its own totals per category.

So the ingest contract should be: if the source declares its own totals, ingest recomputes them from the parsed rows and fails the file when they disagree. Not a warning, not a quarantined row — the whole file is refused, because a control-total mismatch means you don't know what you parsed. For sources with no declared totals (a hand-exported CSV), fall back to a delta check against the previous file from the same source: row count, sum, date range, and debit/credit ratio, warning above a configured band. That's the layer that catches the sign flip.

Two smaller problems with quarantine as specified:

It's stored in archive/, which breaks the archive's meaning. archive/ is the immutable system of record; quarantine.jsonl is a derived parse result. Put it there and someone will hand-edit a date to "fix" a row, and replay silently stops reproducing. Quarantine should be recomputed by rebuild from the .raw bytes and live under the disposable side.

A waiver needs the same rigor as variance accept. "Explicit waiver" as written could be a flag on the close command, which means waiving 3 rows in March silently waives 300 in April. A waiver must pin the exact digest of the quarantined set it covers, carry an actor and a reason, and stop applying the moment that set changes.

Sink contract: four holes

1. There is no transaction boundary. postings: list[ExportPosting] is flat, so the Beancount sink has to guess which postings belong to one entry — and it can't, since case_id in metadata isn't enough (one case emits 440 child entries plus a settlement). Add the level: ExportBatch.entries: list[ExportEntry], and ExportEntry owns entry_id, date, payee, narration, links, postings. Which also fixes the next one:

2. value_date is on the wrong object. Beancount has one date per transaction, not per posting. Leaving it per-posting lets a sink receive an entry whose two legs disagree on date, and there's no correct rendering of that.

3. There is no re-export story, and that's the contract's job, not the sink's. March is exported, then a restatement lands in May. Does the sink append to 2026-03.beancount, rewrite it, or emit a correcting entry? If we don't say, every sink will answer differently and the Beancount and TigerBeetle outputs will diverge. I'd make it a rule of the contract: sinks are write-once per close and never edit a file they previously wrote. A restatement produces a new close, in the new period, containing correcting entries that reference the original case_id. That's also just how accountants handle a prior-period adjustment, so it's the behavior a controller expects anyway.

4. Rendering integers to decimal must be specified, and narration must be escaped. Decimal(amount_minor).scaleb(-exponent) — spell it out in the base class, because the first sink that writes amount_minor / 10**exponent reintroduces floats through the back door. And narration comes from bank descriptions, which contain quotes, newlines, and occasionally bytes that aren't valid UTF-8; an unescaped " in a payee name produces a Beancount file that won't parse, and the user's first experience of us is a syntax error in their ledger.

One detail in the example entry: the evidence_digest shown, e3b0c442…, is the SHA-256 of the empty string (truncated to 63 characters). We picked BLAKE2b. Don't ship the empty-string hash as sample data — someone will grep for it, and someone else will write a test that asserts against it.

The outline is right on the technical spine and thin in exactly the places that decide whether anyone can actually use or contribute to this. Six additions, roughly in order of how much damage their absence causes.

1. The connector contract is missing, and it's the highest-traffic extension point in the repo. Sinks got a full frozen-dataclass spec. Connectors got a directory. But every contribution this project ever receives will be "here's an adapter for Adyen / Wise / Revolut / my regional bank's weird CSV" — and without a stated contract, each one will invent its own ordering, its own sign convention, and its own idea of record_time. Section 5 or its own section needs:

class Connector(Protocol):
    name: str
    version: str
    def sniff(self, raw: bytes) -> bool: ...
    def parse(self, raw: bytes, *, record_time: datetime) -> ParseResult: ...
    def controls(self, raw: bytes) -> list[DeclaredControl]: ...

plus the prohibitions, which matter more than the signature: parse makes no network calls, reads no clock, and must be a pure function of (raw, record_time). And a conformance suite every new connector must pass — parse the same bytes twice, get identical raw_row_ids; shuffle nothing; declare controls or explicitly declare none. That's maybe 80 lines of test that turns "we accept adapter PRs" into something reviewable by someone who doesn't know the format.

2. Fixtures must be synthetic and generated, not anonymized. I proposed "an open corpus of anonymized fixtures" early on and I want to walk half of that back. Scrubbed real bank data is one missed field away from publishing somebody's IBAN, and nobody reviewing the PR can verify the scrub was complete — CAMT.053 has free-text <RmtInf> fields that routinely contain names and invoice references. Ship fixtures/<name>/generate.py, committed, deterministic, seeded, with CI regenerating and diffing against the checked-in files. The corpus keeps its value as a shared test target and stops being a liability. Where we want format realism that only a real file provides, use the sample files the standards bodies and vendors already publish under their own terms.

3. License, and the disclaimer that goes with a financial tool. Apache-2.0 rather than MIT, specifically for the patent grant — payments and reconciliation is a patent-dense area and a contributor patent grant is worth having. Then two things in the README that this category always gets asked: OpenRecon produces evidence, it does not constitute a control environment, and it is not accounting advice. A controller will ask "is this SOX-compliant?" The honest answer is that compliance is a property of their process; what we provide is a reproducible artifact that their process can point at. Say that plainly rather than letting people assume.

Related and less obvious: rule packs have a licensing question of their own. A rule pack encoding Stripe's published fee formula is fine. A rule pack that embeds SWIFT's MT940 field specification may not be redistributable, since that spec is licensed. Worth one paragraph in the contribution guide so a well-meaning contributor doesn't paste a spec table into a YAML file.

4. A non-goals section, load-bearing. Without it the issue tracker fills with "add a web UI" and "support 500M rows" within a month, and each one costs a maintainer a polite paragraph. State: not a ledger; not real-time (batch, run after settlement); single-writer, one workspace per legal entity, so multi-entity consolidation is out of scope; no UI in v0.1; and an honest row ceiling — tens of millions of events on a laptop, beyond that talk to us. Naming the ceiling is more credible than implying there isn't one.

5. Schema migration doesn't exist, and that deserves to be stated as a feature. Because workspace.duckdb is a cache, a schema change is workspace_version: 2 plus openrecon rebuild. No migration scripts, no ALTER TABLE, no half-migrated database in a support thread. That falls out of the cache decision for free, and if we don't write it down someone will helpfully add Alembic in month three.

6. Supply chain. Normalizers are Python plugins, so installing a rule pack means executing someone's code against your bank statements. v0.1 should ship first-party packs vendored in-repo, with no remote registry and no auto-install, and the threat model should say so — it's the one attack in that list where the attacker is a person rather than a data-quality accident.

One thing I'd promote within the existing outline: section 6 should show the actual output of openrecon cases explain, not just the invocation. That rendering — here is the payout, here are the 440 children, here is the −0.13, here is which rule matched each side and what evidence hash proves it — is the product. It's the thing someone screenshots into a Slack thread, and it's what a controller judges us on in the first thirty seconds. A blueprint that specifies the schema in full detail and leaves the one human-facing surface as a command name has its emphasis backwards.

And for the roadmap section, I'd replace a feature list with one falsifiable acceptance test for v0.1.0: the four fixtures produce byte-identical output on two machines with different core counts, twice each, and openrecon close verify 2026-03 reproduces its manifest after a full rm workspace.duckdb && openrecon rebuild. If that passes, every determinism claim in the threat model is demonstrated rather than asserted. If it doesn't, nothing else in the blueprint is true yet.

One open question I'd want the blueprint to answer rather than leave implicit: what happens on the second close of the same period? A controller closes March on April 5, then a restatement lands April 20 and they close March again. Do we forbid it, version it (2026-03.r2), or force the correction into April? We've said sinks are write-once per close, which implies the second close is a distinct close of the same period — but nothing yet says whether a period can hold more than one, and the answer changes what close verify means.

The audit bundle is the right instinct and two of its claims aren't true as written. The SLA has one number that's flatly wrong for the format we care most about.

"Zero-dependency standalone_verifier.py" that "runs the pinned DuckDB matching CTEs"

Those two clauses contradict each other. Running the CTEs needs DuckDB, and re-deriving events from raw/ needs the connectors, which means the verifier is the whole application with a different entry point. An auditor who unzips this, reads "zero-dependency," runs it, and gets ModuleNotFoundError: duckdb has just learned something about how carefully we check our claims.

Split it into two levels and name them honestly:

• verify --level=integrity — genuinely stdlib-only. Recompute the merkle manifest, confirm every entry balances per currency, confirm each case's stated residual equals the arithmetic over its own postings, confirm each accepted variance exactly offsets the residual it claims to. That catches tampering and arithmetic fraud, needs hashlib and json, and runs on any Python 3.11 an auditor already has. This is the one an auditor will actually run.
• verify --level=replay — re-parses raw/ and re-runs matching. Requires a pinned duckdb==X.Y.Z with a recorded wheel hash. Worth shipping, worth not calling zero-dependency.

The bundle ships PII to a third party, by default, silently

We spent a whole section on "recon doctor hard-fails if git is tracking archive/" and then made the default audit command zip the same bytes and hand them to an outside firm. An auditor is often entitled to source documents, so this isn't wrong — but it must be a decision, not a default. --include-raw should be required, and the command should print what it's about to include: how many files, which sources, and a warning naming the fields those formats carry (CAMT.053's <RmtInf> is free text and routinely holds customer names and invoice references). Without the flag, bundle the digests and let the auditor request the bytes separately.

close_manifest.json doesn't contain a signature, and shouldn't claim to

The bundle spec says "the cryptographic signature and publication record," but nothing in this design signs anything. BLAKE2b proves the bundle wasn't corrupted in transit. It proves nothing about who produced it, and it's no defense against the one adversary an audit bundle exists to consider — the person who made the bundle. Anyone who can edit the numbers can recompute the hashes.

A real signature means key management: where the key lives, who holds it, what happens when the controller leaves. That's a subsystem, not a field, and it does not belong in v0.1. So drop the word. The bundle is content-addressed and reproducible, which is a strong and true claim. If a user wants attestation, let them detach-sign the manifest with minisign or age — tools that already solved key handling — and record the signature file alongside. We should never invent our own.

The bundle is missing its most audit-relevant contents

cases.jsonl and postings.beancount tell an auditor what we booked. The first question they actually ask is what we didn't book and who authorized that. So the bundle needs control_checks, quarantine_waivers with actor and reason, accepted_variances with actor and reason, and the ingest manifests showing which files reached promoted and which were refused. Plus the openrecon version and every connector version — without those, --level=replay can't be reproduced two years later, which is exactly when someone will try.

And the manifest needs to pin its own reproduction rules: files sorted by path, digest algorithm and length stated explicitly, so a verifier written in another language reaches the same root hash. "Recursive BLAKE2b checksums" underdetermines the result — BLAKE2b has a variable digest length.

The SLA

50,000 rows/sec per connector is wrong for XML. For CSV through pyarrow it's conservative. For CAMT.053, where each <Ntry> wraps <NtryDtls><TxDtls> with nested amount, party, and remittance subtrees, lxml.iterparse in Python realistically lands in the low thousands of entries per second, and I'd expect 2,000–5,000 on a laptop. Making that a stated SLA means we either miss it publicly or quietly stop counting XML as a connector. Set it per format: CSV/JSONL ≥ 50k rows/sec, XML formats ≥ 3k entries/sec, and revise both once a benchmark exists.

512MB RSS "regardless of dataset size" fights the 250ms join. DuckDB honors SET memory_limit='512MB' by spilling hash joins to a temp directory — so the memory bound is achievable, but the latency target isn't, once you're spilling. State it as a pair: memory bounded by an explicit configured memory_limit with a named spill directory, and the latency targets holding up to a stated event count, above which you're trading time for the memory ceiling.

And these are targets, not an SLA, until something measures them. An SLA in the v0.1 README with no benchmark behind it is a claim that decays silently. What I'd commit instead: a benchmarks/ directory with a fixture-generated dataset at a stated scale, a runner that prints the four numbers, and a CI job that fails on a regression beyond a band. Then the README quotes measured numbers with the machine spec next to them, and they mean something.

The number that's missing is the one users feel. Throughput and close time are batch concerns that run once a month while someone gets coffee. The controller's actual experience is cases list, then cases explain rc_…, then explain --show-children, over and over for an hour. If explain re-derives the evidence graph and takes three seconds, the tool feels broken no matter how fast the close was. Budget the interactive path separately and tightly: cases list and cases explain under 200ms on a warm workspace, which likely means the case residual and evidence digest are materialized at match time rather than computed per-invocation.

One thing I'd add to the bundle that costs nothing: a README.txt at its root, addressed to a human who has never heard of this project, saying what the bundle is, what command produced it, and the two verify invocations. Every audit bundle format I've seen that omitted that got opened, not understood, and forwarded back with a request for a PDF.

The framing of the question contains the trap: "without introducing runtime overhead during normal match" invites a compiler with a debug=True branch that emits different SQL. Do that and debug output can disagree with what match actually did — the money version of "it works in the debugger." Someone will spend a day trusting a trace that describes a query the engine never ran.

One compiled artifact, filtered, never a variant. The compiler emits a fixed chain of named CTEs per rule:

WITH left_candidates  AS (…),
     right_candidates AS (…),
     pairs            AS (…),   -- cartesian within the grouping key
     scored           AS (…),   -- per-predicate deltas, computed always
     ranked           AS (…),   -- rank_by, deterministic tie-break
     selected         AS (SELECT * FROM ranked WHERE rk = 1 AND all_predicates_pass)
SELECT * FROM selected;

Normal match reads selected. Debug runs the same text with a source-level predicate bound (WHERE natural_key = ?) and reads each stage in turn. DuckDB pushes that filter down through the chain, so debugging one case touches roughly one case's worth of rows. The overhead in normal mode is zero because CTEs are inlined, not materialized — no stage is written anywhere unless debug asks for it.

The guarantee needs a test, not a convention: assert that the CTE body hash is byte-identical between the two invocations, and add a golden test asserting debug's selected rows equal the persisted matches for the same case. If the compiler ever grows a debug branch, that test dies.

Notice that scored computes deltas unconditionally. That's deliberate. You need the amount delta and the time delta to rank candidates anyway, so keeping them in the always-on path costs nothing and means the near-miss information exists whether or not anyone asked for it.

The output that matters isn't the failed invariant

"12 of 500 batches fail to match" — knowing which invariant failed is nearly useless, because the answer is always "the one that failed." What a finance engineer needs is the near-miss: what was the closest candidate, and by how much, along each dimension separately.

UNMATCHED  parent  mercury:credit  ev_4c1a…  +10,400.15 USD  2026-03-14T09:02Z

  best candidates (rule bank_ach_1to1@2.1.0)
  rank  event      amount_delta   time_delta   key      verdict
  1     ev_9f02…        -0.03 USD      +71h     —        OUT_OF_WINDOW (tolerance 48h)
  2     ev_31bd…        -0.03 USD      +73h     —        OUT_OF_WINDOW
  3     ev_77ac…      +412.00 USD       +2h     —        AMOUNT_MISMATCH

  12 of 500 parents share this shape: amount within 5 minor units, time 68-76h.

That last line is the actual finding. A cluster at 68–76 hours against a 48-hour window doesn't mean the tolerance is too tight; it means this bank posts on T+3 and the rule was written for T+1. You cannot see that from "invariant failed," and you can see it immediately from a delta histogram.

Which brings up the guardrail, because visibility alone makes the tolerance problem worse

Show someone that 12 batches would match at 96 hours and they will set the window to 96 hours. The number that stops a bad change is the blast radius, and it comes from the same query with the relaxed predicate:

$ openrecon debug rule bank_ach_1to1 --relax window=96h --dry-run
newly matched:     12 parents
newly ambiguous:   47 parents now have >1 rank-1 candidate  ← this is the cost
newly reclaimed:    3 children currently claimed by adyen_settlement@1.4.0

47 new ambiguities is a much clearer "no" than any warning text we could write. And --dry-run should emit a proposed rule diff, never apply one, so the workflow lands where the existing machinery already is: debug → proposed diff → version bump → replay --from-lock --to-lock → review the case diff → merge. Debug becomes a PR generator rather than a footgun.

Two gaps this exposes

Rejections are never persisted. "Dropped/competing candidates" was in the requirements from the first mention of the case evidence graph, but no table ever landed for it, so debug would have to recompute — and a recomputation under a newer rule pack won't describe what happened at match time. Write them during match:

CREATE TABLE match_rejections (
  rejection_id  VARCHAR PRIMARY KEY,   -- blake2b(rule_id || rule_pack_digest || candidate_digest)
  rule_id       VARCHAR NOT NULL,
  parent_event_id VARCHAR NOT NULL,
  candidate_event_id VARCHAR NOT NULL,
  reason_code   VARCHAR NOT NULL,      -- LOST_RANK | OUT_OF_WINDOW | AMOUNT_MISMATCH | ALREADY_CLAIMED
  amount_delta_minor BIGINT,
  time_delta_seconds BIGINT,
  rank          INTEGER,
  record_time   TIMESTAMPTZ NOT NULL
);

Bounded to the top k=5 per unmatched parent, configurable. Unbounded it's O(n²) on the pairs relation and will dwarf every other table in the workspace. That's a real ceiling and the docs should say so: rejections are a debugging aid with a fixed depth, not a complete record of everything the engine considered.

Rule ordering is currently implicit, and that's a determinism bug in the same family as the parallel hash join. "Already claimed by a competing higher-rank rule" presumes rules run in a defined order with earlier claims winning — but nothing has specified where that order comes from. If it's directory iteration, it differs between NTFS and ext4, which means the same workspace matches differently on the developer's laptop and the CI container. rules.lock needs an explicit integer priority per rule, resolved at lock time and part of the lock digest. Ties on priority are an error at lock time, not a coin flip at match time.

Yes — six, and the first two would produce wrong numbers in production, not just confusion.

1. There is no read rule for superseded events, which means restatement doesn't actually work yet

We put supersedes_id on events in the second message and never wrote down how to read past it. case_events is keyed (case_id, event_id, role), so when Stripe amends a balance transaction, both the original and the amendment are members of the case. Every sum() over that case now double-counts. The 13¢ residual becomes a 12,400.13 residual.

The missing rule, which belongs in the blueprint as its own paragraph because every query depends on it:

A case's evidence set at time T is, for each supersession chain, the single event with the greatest record_time ≤ T that is not superseded by another event with record_time ≤ T. Every aggregate — residual, rollup, closure invariant, export — reads that set, never the raw membership.

In practice that's one view (events_as_of) that every rule and every rollup selects from, and a lint that fails if any compiled SQL references the events table directly. Without the lint someone writes FROM events in a closure rule in month two and nobody notices until a restatement lands.

2. Nobody has mentioned timezones, and ExportEntry.value_date is a date

value_time is TIMESTAMPTZ. Beancount dates are naive calendar dates. Converting one to the other requires a timezone, and if we default to UTC we've made a silent policy decision that's wrong for most users: a charge at 2026-03-31T23:30Z books to March for a UTC company, to March 31 local for a New York company — and to April 1 for one in Auckland. Period boundaries are exactly where this bites, which means it bites at close, every month, on the transactions that matter most.

So: reporting_timezone is a required field in openrecon.yaml, it has no default, and it's an input to the digest that the close pins. And --cutoff 2026-04-05T00:00:00Z should probably accept a local time and record the resolved instant, because a controller thinks in their own calendar and will get the UTC offset wrong at least once.

3. evidence_digest means three different things and is spelled one way

It appears on reconciliation_cases, matches, case_state_transitions, accepted_variances, control_checks, and as digest on evidence_rollups. On the immutable case row it cannot mean "digest of the current evidence set" — the case row never changes and evidence keeps arriving, so it's stale the moment the second file lands. Rename that one opening_evidence_digest and define the other five explicitly, or verify_integrity.py will compare things that were never the same function.

4. case_summaries and evidence_rollups are mutable tables in an append-only design

That's fine — they're materializations for the 200ms interactive budget. But they must be declared derived: rebuilt by openrecon rebuild, never an input to any content hash, and specifically evidence_rollups.digest must not be what the audit bundle verifies against. If the verifier checks a cache, we've made the cache load-bearing and the "delete workspace.duckdb freely" guarantee is gone.

5. currency CHAR(3) contradicts the reason we added exponent

The exponent column exists partly because USDC needs 6 decimal places. USDC is not three characters. Neither is any Beancount commodity like AAPL. Either widen to VARCHAR with a validation rule, or state plainly in non-goals that v0.1 is ISO-4217 only and drop the crypto justification for exponent (JPY at 0 and KWD at 3 justify it on their own). Right now the schema says one thing and the rationale says another.

6. Rule priority inside a rule pack makes multi-pack installs unlockable

Ties fail lock generation — correct. But if priority is declared inside a pack, then a Stripe pack and an Adyen pack written by different people will both pick 100, and every workspace that installs both fails to lock with no recourse except forking a vendored file. Priority is a property of the workspace's rule composition, not of a rule. Put it in openrecon.yaml as an ordered list of pack names, derive per-rule integers from that ordering at lock time, and let a pack declare only intra-pack ordering.

Two smaller ones worth a line each in the spec rather than a section:

accepted_variances.account_key resolves through accounts.yaml, which changes. The close pins accounts_digest, so a re-export of March resolves correctly — but only if resolution always happens against the close's pinned accounts file rather than the working-tree one. Say that explicitly; the obvious implementation reads the file on disk.

A bundle built without --include-raw cannot be replay-verified, since replay re-parses raw bytes. openrecon bundle verify --level replay against a digest-only bundle should fail with that exact message rather than a missing-file traceback, and README.txt should say which level the bundle it sits in supports.

One genuine ambiguity I'd rather flag than paper over: case_id = blake2b(case_type || source || natural_key) assumes one source per case, but the CAMT.053 fixture is inherently two-sided — a bank line and an internal ACH batch. It works if source means "the anchoring source the rule declares," and it breaks if anyone reads it as "where this case's evidence came from." Whichever we mean, the blueprint should say it in the field comment, because the second reading is the more natural one and it produces a case id that changes depending on which side got ingested first.

Before you write it, one thing nobody in this room has said once, and I think it's the most useful contribution left: we have designed roughly nine months of work and called it v0.1.

Count the subsystems: four-stage ingest with control verification, a rule compiler with lint enforcement, a claim ledger with scopes and namespaces, bitemporal read semantics, immutable close revisions with publication states, audit bundles with two verification levels, HMAC redaction, rejection persistence, blast-radius analysis, a benchmark suite with CI gates. Every one earned its place in the conversation. Collectively they describe a product a funded team ships in a year.

If the spec presents all of it as the plan, the repo reads as vaporware on day one — an enormous README with openrecon/ containing three stub files. That's the specific way ambitious open-source projects die: not from a bad design, from a design nobody can start.

So I'd ask the blueprint to mark every subsystem with a shipping tier, and to make v0.1 embarrassingly small:

The test is whether a competent person can ship the v0.1 row in a few focused weeks. That row can, and it already demonstrates the thesis — ingest a real payout, find the 13¢, explain it, export the rest. Everything below it is credible because the top row exists, and worthless without it. The design work we did isn't wasted by the cut; it's what stops v0.1 from making a decision that v0.3 can't live with. That's the entire value of designing ahead.

One mechanical suggestion: put the tier in the spec as a column, and mirror it in the repo as GitHub milestones with the same names. Then the roadmap section is a link rather than prose that goes stale in a month.

The disagreement that survived, since the result is supposed to name one:

controls.auto_accept_variance_minor is configurable. I argued in my first message that auto-accepting variance under a threshold is how a 13¢ bug becomes a $130,000 bug, and the compromise reached — default 0, and changing it bumps the rule-pack version so old runs still reproduce — makes the change auditable but doesn't make it hard. Someone under close pressure at 9pm on April 5 will set it to 500 and every rounding break in the period disappears silently, reproducibly, with a version bump nobody reads.

I'd still cut the knob entirely for v0.1 and force variance accept per case. What would settle it is evidence rather than argument: ship without it, and see whether real users file an issue asking for it. If ten batches a month each need a manual 13¢ acceptance, they'll say so and they'll be right. If nobody asks, we never build the footgun. Absence is cheap to reverse; a threshold that's been in a release for a year is not.

And a second, smaller one I'll own rather than pretend is settled: this room added a subsystem on every single turn and never once removed one. That's a real property of how we worked, and the spec would be more honest for saying that the design is deliberately maximal and the tier table is where it gets disciplined.

Last practical note. The README's first screen decides whether anyone reads the rest, and right now the blueprint's section 1 is "Executive Summary & Mission." What belongs above the fold instead:

1. One sentence on what it is — reconciles payment-processor settlements against your bank and your ledger, and shows its work.
2. The three commands from init --with-fixture through cases list, with the real terminal output showing variance_pending -0.13 USD.
3. One sentence on what it is not: not a ledger, not accounting advice, not real-time.
4. The explain output, in full.

The threat model and the DDL are what make an evaluator trust the project, but only after the first screen has made them want to. Put them at position 2 and 4 in the document and they'll never be reached.