USE CASE · BLUEPRINT
The Next Build Starts From the Knowledge Layer.
The clearing case study ended with “the knowledge stayed in the vault.” Here is what that means in practice: the same team's next build — a securities custody core with double-entry accounting, corporate actions, and encumbrances — starts not from a blank page but from an inherited project vault: domain primitives, proven patterns, and pre-configured agents, available from minute one.
The Problem
Securities Never Disappear. The System Must Prove It.
A custodian is a bookkeeper of securities: at any moment, every security sits in a specific section of a specific custody account, and no operation may “lose” or “create” one. Every posting is a balanced debit and credit; the per-issue balance is a domain invariant checked at commit time — not discovered in a nightly reconciliation.
The target is a reference custody core on the same principles as the clearing build: a pure domain core with no framework imports, sealed hierarchies for the five operation classes, and events through a transactional outbox. The difference this time: the project doesn't start from zero.
Knowledge Inheritance
The Clearing Build's Project Vault Is the Custody Build's Starting Capital
In Flexor, a project's knowledge is a versioned asset. The post-trade vault attaches to the new project as an underlying layer: everything shared is inherited, everything specific is overridden above it. No copy-paste, no drift — a fix in the shared layer is seen by both projects.
- Value objects: Money, Quantity, Isin/SecurityId, PartyId, BusinessDate, DayCount, typed identifiers
- The post-trade ubiquitous language — a shared vocabulary across clearing and custody
- The sealed-projection pattern: each type projects itself into universal engine concepts
- Transactional outbox: ports, relay, and atomicity tests from an accepted delivery
- The dependency rule and container SPI (framework as adapter)
- Decisions D1–D3 with their rationale — the “why it's built this way” context
- Custody accounts and account sections — new aggregates
- Double-entry ledger postings and their balance invariants
- Custody vocabulary: deposit, withdrawal, transfer, encumbrance
- Corporate-action model: coupons, dividends, conversions, buybacks, meetings
- Position reconciliation protocol against the upstream depository
- A new PRD with its own requirements and decisions
One edit to the vault manifest → sync → both layers materialized for all three agents.
Five Operation Classes. One Sealed Hierarchy.
As in the clearing build, each operation class projects itself into a universal engine concept — a balanced set of ledger postings. The ledger, its invariants, and the statements are written once and work for every operation class, present and future. The compiler guarantees exhaustiveness: you cannot add an operation class and forget it in the engine — the code won't build.
Deposit, withdrawal, transfer between accounts and sections
Account and section lifecycle, profiles, appointments
Statements and reports — read-only projections of the ledger
Pledge and blocking as section states, not row flags
Coupons, dividends, conversions, buybacks, holder meetings
Invariant holds: Σ debit = Σ credit · issue position unchanged. Violations aren't exceptions — they're unrepresentable states.
A Plan Calibrated by Facts, Not Optimism
The estimates below extrapolate from measured reality: the clearing build shipped a v1.0.0 of comparable scope in one day — on an empty knowledge layer. The custody build starts on a non-empty one.
One line in the vault manifest attaches the post-trade project vault from the clearing build; a new custody vault sits on top. The PRD is written in an already-existing vocabulary — half the ubiquitous language exists before the first line of code.
Ledger, postings, balance invariants, custody accounts with sections; deposit, withdrawal, transfer. Value objects come ready-made; the sealed pattern follows the clearing precedent. First end-to-end operational-day run.
Pledge and blocking as section states; coupons, dividends, conversions, and buybacks as operations that generate posting cascades. The outbox arrives with its atomicity tests — the event bus works from day one.
Position reconciliation against the upstream depository, informational operations as read-only ledger projections, and execution of the securities leg of the clearing engine's settlement obligations. Self-contained tests and an animated showcase — the delivery standard set by the first build.
After this build, the shared layer gains a double-entry ledger and a corporate-action model. Build number three — whatever it is — starts even higher up the ladder. That's the Flexor economics: every project is cheaper than the one before.
The Clearing Build Proved Speed. This One Proves Compound Interest.
A normal project ends with code and a tired team. A Flexor project ends with code plus a knowledge layer that makes the next project faster. The post-trade domain model was paid for by the clearing build — the custody build gets it for free.
The transactional outbox arrives in the new project not as “an idea from a blog post” but as a proven contract: ports, relay, and atomicity tests from a delivery accepted against written criteria.
Claude Code, Cursor, and Codex are already configured; the rules already have enforcement; stack discipline is already active. Day 0 of the new project is a day of work, not a day of setup.
Clearing and custody speak the same language: Isin, PartyId, BusinessDate are literally the same types. The DvP link between the two systems is not an integration project — it's an import from the shared layer.
Status note: this page is a blueprint. The domain model, architecture, and trajectory are designed; timing estimates are extrapolated from the clearing build's measured delivery speed. The list of inherited artifacts is the factual content of that accepted delivery.
Read the Case That Left the Knowledge Behind
A clearing and collateral engine for five trade types — v1.0.0 shipped the same day the project started.
Read the Clearing Case StudyYour second project starts where the first one left its knowledge.
We'll map which parts of your delivery would compound across projects — and what a governed knowledge stack saves you on build number two.
Request a Demo