BondGovernance — Infrastructure for Secured Bonds

§ Trust · Architecture & Data Trust

Deterministic. Traceable. Modular. Compatible.

The four architectural properties that make BondGovernance safe to admit inside a regulated data perimeter. The trust boundary is drawn around the customer, not around the vendor.

§ 01

Why this page exists

Regulated finance can only admit an AI-adjacent vendor when four architectural properties are demonstrable up front: the logic is deterministic, every value is traceable to its source, the system is modular enough to reason about, and customer data never has to leave the customer's own control plane. This page describes how BondGovernance is built against those four properties.

Current security controls are documented on Security. The forward-looking certification and in-house AI path is on Roadmap & Vision.

§ 01

Deterministic

Same input → byte-identical output

§ 02

Traceable

Append-only provenance on every value

§ 03

Modular

Extraction · Rules · Delivery are separable

§ 04

Compatible

EU data boundary · BYO tenant target

§ 02

Trust boundary

The trust boundary is drawn around the customer, not around BondGovernance. Customer documents, identity records and the append-only audit ledger remain inside the customer's own tenant. BondGovernance receives only the extracted evidence required for the deterministic engines to produce a governance decision, and returns that decision back across the boundary.

  • No customer content is used to train third-party models.
  • Model inference is isolated behind a deterministic gateway; every model-derived value carries provenance and never bypasses the audit trail.
  • Bring-your-own tenant is the target enterprise posture; see the Roadmap.
Customer trust boundary and BondGovernance serviceCustomer documents and identity remain inside the customer perimeter. BondGovernance receives only extracted evidence and returns governance decisions.CUSTOMER TRUST BOUNDARYRegulated entity · own Azure tenantProspectus / covenantsIssuer filings · IP recordsCollateral evidenceIdentity · roles · SSOAppend-only audit ledgerBONDGOVERNANCE SERVICEDeterministic governance engineExtraction adapters (per source)Rule engines · cross-checksWriters · delivery · SDK / APINO CUSTOMER DOCUMENTS STORED · NO MODEL TRAINING ON CUSTOMER DATAEVIDENCE ONLYDECISIONS · CROSS-CHECKS
§ 03

Deterministic logic

The governance engines are pure functions. They contain no wall-clock time, no randomness, and they never throw. Errors are returned as an explicit { severity, message, source } envelope. Cross-check ordering is driven by explicit enums rather than locale-dependent string sorting, so a decision produced today reads byte-for-byte the same when it is replayed a year from now.

The model extracts. The engine decides. This is the single most important line in the architecture.

W1

Ingest

Normalise + Zod validate

W2

Extract

Domain adapters

W3

Cross-check

Ordered enum, not locale sort

W4

Decide

Pure rules over evidence

W5

Deliver

Provenance-bound output

§ 04

Modular layers

The platform is stacked in four layers with hard interfaces between them. Each layer is independently testable and independently versioned, and can be swapped without cascading through the rest of the system. That property lets an enterprise security team review one layer at a time, instead of accepting a monolith on trust.

L4DeliveryWriters · SDK-JS · SDK-Python · API · webhooks
L3Governance & EventsRule engines: covenant · collateral · IP · systemic · operational
L2ExtractionPer-source domain adapters · dictionary v1 · deterministic normalizer
L1Trust planeAuth · RLS · append-only audit · secret vault
§ 05

Traceability

Every extracted value, every cross-check, every rule decision and every delivered report is written to an append-only ledger with a stable source reference. A regulator, a trustee or a credit committee can take any output and walk it back to the exact document page, rule id and engine version that produced it. Replay is the default, not a feature we had to add.

SeqEventSourceSev
#0001extract.covenant.icrprospectus.pdf#p14ok
#0002check.icr.headroomrule:icr-headroomwarn
#0003decide.wave4.verdictengine:wave4ok
#0004deliver.report.investorwriter:investor@v1ok
Append-only · hash-chained · replayable
§ 06

Compatibility with EU regulation

The architecture is aligned with the control expectations of MiFID II, DORA, GDPR and the EU AI Act. Data residency defaults to the EU data boundary. Third-party model calls are opt-in per tenant and can be pinned to a customer-managed inference endpoint. Processor obligations, retention and sub-processor disclosure are formalised in the Data Processing Agreement.

  • MiFID II Art. 16(6): record-keeping satisfied by the append-only ledger.
  • DORA: deterministic replay supports ICT operational-resilience testing.
  • GDPR: the customer remains controller; BondGovernance operates as processor.
  • EU AI Act: model outputs do not make governance decisions on their own.
§ 07

Architecture review

Enterprise architecture, security and procurement reviews are handled directly by the trust team: trust@bondgovernance.com. NDA is available on request; detailed engineering diagrams, threat models and sub-processor lists are shared under NDA.