Money
arrives.
Something
must credit. — Treasury engine, P1 · deposits

P1 introduces two operator controls, both keyed in a new system_settings table A-3451 · planned. anchorage_poller_enabled starts/stops ingestion without a redeploy (today the poller is gated only on ANCHORAGE_API_KEY presence). auto_credit_enabled is the money switch — and it ships in shadow, not off. Every credit the gate would fire is computed, logged, and audited; nothing moves a balance until a written go-live decision flips it. neither setting exists in the tree yet

Click any node. Green nodes are live on main today; gold-dashed nodes are P1 work. Anchorage is the source of custody truth; the DepositEvent bus fans one deposit out to parallel gates; the credit executor is the only writer of current_balances, and it fires exactly once per deposit.

Resolve each gate. Watch the milestone DepositState derive from the DepositRecord, the credit chokepoint refuse until fully_gated(), and the effect log record every Apply. The core is monotonic (a resolved gate never flips), fail-fast (one failed gate freezes the diamond into Failed), and credit-irreversible. This is the model in deposit_pipeline/{record,state,event}.rs today — unit- and integration-tested, not yet wired to the bus. proven-in-isolation

fully_gated() is necessary but not sufficient. The header comment on anchorage_deposits is explicit: status='SUCCESS' is not auto-credit-safe. The gate is the full conjunction below — and on-chain finality is our own check, not Anchorage's word. Per-chain thresholds are an open decision A-3649. Drag confirmations to see the verdict flip.

The credit executor writes the current_balances update and the deposit_credit_attempts row in one Postgres transaction. A UNIQUE constraint on idempotency_key turns any retry — same handler re-running, or a concurrent one — into a no-op. This is CreditedIrreversible plus credit() idempotency, asserted in the pipeline integration test. Fire, retry, and race the executor below. deposit_credit_attempts · A-3429

Money-touching failure modes and the invariant or mechanism that contains each. Shadow mode buys the soak window in which most of these surface without a balance ever moving.

The roadmap risk isn't the code — it's that the P1 critical path runs through the /db/ high-risk lane at the front, and that lane has two swamped CODEOWNERS. The move is to collapse the schema reviews into one batch, then develop in the fast lanes while it drains. Each lane below is priced by who reviews it and how much they must check.

Two non-code decisions gate the design and can each erase weeks of engineering. Both have external dependencies (compliance, chain research), so they start on day one — a memo framing the question costs a day and lives in the zero-review docs lane.

Each deferred item carries a revisit trigger — the observable that flips it from "later" to "now" — and the failure mode being accepted (hover to reveal). Scope stays frozen; the follow-up lives here with its trigger attached.

Each PR small and single-lane; the app is functional after every merge; no PR depends on a future PR's behavior. The binary ships in shadow — flipping to Live is a system_settings change, not a deploy. The one serial dependency is the schema batch (#1); everything after it runs in the fast lanes in parallel. ▷ Tap any row for the gate that lets it start.