Section I — The Compiler

The compiler.

Governance is software. We built the part that compiles it.

Living Policy Architecture parses your governance documents into a structured intermediate representation, compiles them into runtime configuration with provenance, shadow-tests the result against live data, signs the change through your own authority chain, and activates the new behavior the same business day.

§1 — Five-stage pipeline

From document to live behavior, in five stages.

Each stage produces a defined artifact and carries a defined guarantee. The stage names are the marketing claim; the mechanism behind each stage is the moat.

01
Extract
What is produced. A structured set of obligations indexed by category. Every obligation carries provenance back to the source document and paragraph it came from.
What is guaranteed. The intermediate representation is complete with respect to the categories defined in the schema. Nothing in the source documents that maps to a category is silently dropped.
02
Compile
What is produced. Two output families: operational configuration the runtime reads on every action, and meta-governance configuration the runtime reads on every change to operational configuration.
What is guaranteed. Compilation is deterministic. Given the same intermediate representation and the same target, the output is byte-identical across runs.
Worked example
A paragraph of a synthetic Northbridge IPS, compiled.
Investments in any single issuer shall not exceed five percent (5%) of the aggregate fund value at the time of acquisition, measured on a look-through basis to the underlying investment exposure.
Sector exposure across any GICS Level-1 sector shall not exceed twenty-five percent (25%) of the aggregate fund value, with the exception of Financials and Information Technology which shall be capped at thirty percent (30%).
Any departure from the limits above requires the prior written concurrence of the Investment Committee, with the Chief Compliance Officer countersigning as to operational feasibility.
- This paragraph compiles to three obligations.
- Each obligation carries provenance back to this paragraph (paragraph 2.4, line 7).
- All three obligations are signed jointly into the change-proposal bundle.
- Full compiled schema available under engagement.
03
Shadow
What is produced. A delta showing how the proposed runtime configuration would have behaved against live data over a configurable window.
What is guaranteed. Shadow runs do not affect production behavior. No transaction, allocation, or report changes as a result of a shadow run.
04
Approve
What is produced. A signed change proposal. Signatures are produced by the tenant’s named approvers using their own credentials.
What is guaranteed. A change proposal cannot advance to activation without the signatures the tenant’s governance documents require.
05
Reconfigure
What is produced. A live configuration swap, audited at the moment of activation.
What is guaranteed. The runtime begins behaving according to the new configuration the same business day the cutover signs. Rollback is a new change proposal through the same gate.

§2 — Twelve-category intermediate representation

Twelve categories of obligation. Five named here.

The intermediate representation organizes every obligation in your governance documents into twelve categories. Five are named on this page. The other seven, and the field shapes within each category, are available under engagement.

Five categories named. Seven remain. Full schema available under engagement.

§3 — Standard change classes

Eleven standard change classes — CC-01 through CC-11.

Every change the gate handles falls into one of eleven classes. Each class has its own materiality threshold, authority chain, cooling-off default, and audit-event shape. The names are public; the per-class operational specifications are available under engagement.

CC-01 investment_policy_limit_update: Changes to a defined limit — concentration, counterparty, sector — in the IPS.
CC-02 compliance_manual_revision: Revisions to the compliance manual or any of its annexes.
CC-03 risk_framework_change: Updates to the risk framework, scenario set, or stress-test parameters.
CC-04 fee_schedule_change: Changes to management, performance, or pass-through fee structures.
CC-05 regulatory_overlay_toggle: Activation or deactivation of a regulatory regime overlay.
CC-06 jurisdictional_scope_change: Addition or removal of a jurisdiction in the tenant’s operating footprint.
CC-07 esg_constraint_modification: Adjustments to exclusion lists, screening criteria, or impact thresholds.
CC-08 counterparty_eligibility_update: Onboarding, off-boarding, or status change of an eligible counterparty.
CC-09 data_governance_revision: Changes to data classification, retention, or access policies.
CC-10 reporting_template_change: Updates to recurring report formats — LP letters, board decks, regulatory filings.
CC-11 approver_identity_update: Onboarding or off-boarding of a named approver, or rotation of their signing identity.

§4 — Verification posture

Signed, chained, verifiable.

Every change that advances through the gate is signed by the tenant’s named approvers. Every signed change is appended to a hash-chained audit log. Every audit entry is independently verifiable, without DAP’s cooperation.

Signatures are produced with Ed25519. Audit chain integrity is enforced with HMAC-SHA256 over a canonical payload. Audit log contents are encrypted at rest with envelope encryption. These primitives are textbook; how DAP uses them is not.

See it run on Overture →