Overture — the investment management runtime.
In production. The platform on which the compiler has been most fully exercised.
Overture executes investment-policy obligations under the same governance gate Living Policy Architecture writes for every runtime. Twelve agents in three sub-supervisors decompose the work. A nine-state governance gate routes every change through the tenant’s own authority chain. A hash-chained audit log makes every action independently verifiable.
Twelve agents in three sub-supervisors.
Intelligence ingests and normalizes. Analysis decomposes risk, return, and exposure across the portfolio. Governance gates every action under the tenant’s authority chain. Names are public; system prompts, tool registrations, and orchestration topology are not.
Overture — twelve agents in three sub-supervisors
data_integrityharmonizer
risk_attributioncredit_pe_analystpredictive_riskdeal_sourcingstress_testingreport_builder
compliance_officeraudit_trailexecution_guardrailmodel_governance
Tenant isolation at the database.
Overture’s data layer enforces tenant isolation at the database with Postgres row-level security. Audit entries are hash-chained on write. Semantic retrieval uses 1024-dimension Voyage embeddings, HNSW-indexed, cosine-distance.
Tenant isolation is at the database layer. Not the application layer.
These choices are deliberate. Tenant isolation at the application layer is a single forgotten WHERE clause away from a cross-tenant disclosure. Tenant isolation at the database is enforced regardless of what the application code does. Encrypted-at-rest, hash-chained-on-write, and signed-on-change are not features that need to be remembered; they are properties of the runtime.
Every change advances through nine states.
A change proposal in Overture begins as a draft and either advances to live behavior or terminates as rejected or withdrawn. Each state has an entry condition, an exit trigger, and an audit event. Eleven standard change classes share the same nine-state shape; each class carries its own materiality threshold and cooling-off default.
draft
Entry: the change proposal is created.
Exit: when the proposer submits for routing.
Audit: a creation event is recorded.
routing
Entry: when a proposal is submitted from draft.
Exit: when the gate identifies the authority chain required for this change class.
Audit: a routing event is recorded with the chain identified.
shadow
Entry: when routing completes successfully.
Exit: when the shadow run finishes and the delta is recorded.
Audit: a shadow event is recorded with the delta summary.
signing
Entry: when shadow is complete and the proposal is presented to approvers.
Exit: when the required signatures are collected, or when an approver rejects, or when the proposer withdraws.
Audit: signature events are recorded as each signature is added; a transition event is recorded on exit.
cooling_off
Entry: when all required signatures are collected.
Exit: when the configured cooling-off window expires without a signature withdrawal, or when a signature is withdrawn.
Audit: a cooling-off-start event; a cooling-off-end or signature-withdrawn event.
activating
Entry: when cooling_off ends without withdrawal.
Exit: when the configuration swap completes.
Audit: an activation-start and activation-complete event.
live
Entry: when activating completes successfully.
Exit: only by a new change proposal — rollback follows the same gate.
Audit: a live event is recorded; the configuration becomes the new baseline.
rejected terminal
Recorded as a terminal event with the rejecting approver and reason.
withdrawn terminal
Recorded as a terminal event with the withdrawing party and reason.
Eleven standard change classes. Each one has its own materiality threshold and cooling-off default.
An interactive walk-through of a sample change — fabricated, neutral — mounts here in the next release. Actual gate behavior varies by change class and tenant configuration.
Same policy. Different regime. Same business day.
A single investment-policy document can be compiled against any of the regimes Overture supports. The source text does not change; what changes is what the runtime enforces. The illustrative comparison below is generated from a synthetic Northbridge IPS against four regulatory regimes.
| obligation | SEC | ESMA | CSA | FCA |
|---|---|---|---|---|
| concentration limit | ≤ 5% per issuer | 5 / 10 / 40 (UCITS) | ≤ 10% (NI 81-102) | 5 / 10 / 40 (UCITS) |
| eligible counterparties | qualified institutional | professional client | accredited investor | professional client |
| reporting cadence | quarterly N-CSR / N-PORT | annual KIID / semi-annual | monthly NAV / quarterly | annual / semi-annual |
Why the speed matters.
Jurisdictional reconfiguration is the work that most often gets deferred — re-papering a fund family for a new regulatory regime is a months-long, multi-vendor exercise. Living Policy compresses it to one signed change, executed the same business day the cutover signs.
Reconfiguration speed — legacy versus Living Policy
Three-tier voice router.
Overture accepts spoken instructions through a three-tier router — utterance capture, intent classification, and gate-aware command synthesis. Every command issued through the voice surface is materialized as a change proposal through the same nine-state gate. The voice surface does not bypass governance; it is a channel into it.
Five rows from a hash-chained log.
Every action in Overture writes an entry to a hash-chained audit log. Each entry references the hash of the entry before it. Tampering with any row deterministically breaks the chain at that row. A verify_chain() read recomputes the chain end-to-end; tampering is detected immediately.
| # | prev_hash | payload | ts | entry_hash |
|---|---|---|---|---|
| 001 | 0x0000…0000 | change_proposal_created | 2026-05-21T09:14:02Z | 0x4b9c…a217 |
| 002 | 0x4b9c…a217 | routing_resolved | 2026-05-21T09:14:03Z | 0x8d12…ff64 |
| 003 | 0x8d12…ff64 | shadow_run_complete | 2026-05-21T09:18:47Z | 0xc1a4…720b |
| 004 | 0xc1a4…720b | signature_added | 2026-05-21T10:02:11Z | 0x77e9…3d8a |
| 005 | 0x77e9…3d8a | activation_complete | 2026-05-21T14:46:30Z | 0xa603…1c52 |
Fabricated five-row snapshot. verify_chain() semantics shown; real chain state is tenant-private.