Compliance · pluggable layer
Compliance that plugs in — never hardcoded into the core
IFRS and jurisdictional depth belong in packs, not in ledger code: compliance enters through versioned, contract-bound modules that are sandboxed, effective-dated and installable with no network at all.
- contract surface at PH-1
- rules engine Roadmap (PH-2)
- every verdict is a provenance event
Ledgerbook AI keeps compliance out of the core by design. Rule packs and industry logic register against versioned, contract-bound modules — declared scopes, synchronous evaluation hooks, structured findings, sandbox isolation, deterministic verdicts — instead of being compiled into ledger code. At PH-1 the compliance-module contract ships as an interface, so integration work is not blocked on pack content; the rules engine, the IFRS baseline and the jurisdictional packs, findings and waivers, and the audit evidence package are Roadmap (PH-2), and they are labelled that way throughout this page. Where they land, verification runs synchronously on the write path — fail-closed or advisory per pack — and every verdict, waiver and module invocation is recorded as provenance, reproducible as of a belief instant.
Verified 2026-09-19 · source: product documentation §6.2 — contract surface PH-1 (interface only); rules engine, packs and evidence packages Roadmap (PH-2)
Phase legend: PH-1 shipped now · Roadmap arrives with PH-2. Labels are always present — colour is never the only signal.
A contract is not a product
Jurisdiction depth arrives as modules and data, not as a forked ledger. That is why the interface ships before the content — and why the phase label on this page matters.
The contract surface
The versioned compliance-module contract ships as an interface: registration and discovery, declared scopes (books, jurisdictions, entry classes), synchronous evaluation hooks, structured findings, an isolation boundary and deterministic behaviour — the same inputs always produce the same verdicts. A module's declared egress and credential needs sit in its registration manifest, and module invocations, verdicts, retries and failures are recorded as events.
compliance-module contract surface (interface only) · PH-1
Roadmap The modules and the packs
The rules engine, the IFRS baseline and the jurisdictional GAAP and tax packs are products built on that contract — and they are Roadmap (PH-2). So are finding lifecycles, waivers and overrides, and the audit evidence package. Interfaces landing first means integration work can start before the content exists; it does not mean the content exists.
rules engine, standard packs, findings/waivers, evidence packages · Roadmap (PH-2)
| Contract term | What the contract fixes |
|---|---|
| Registration & discovery | Modules register and the platform discovers them. Installation is configuration, not a code change — including in air-gapped deployments, from offline bundles. |
| Declared scope | Books, jurisdictions and entry classes a module claims. A module registered for one jurisdiction is never invoked for entries booked elsewhere. |
| Evaluation hooks | Synchronous hooks on the write path that return structured findings: rule id, version, severity, disposition — attached to the entry, not filed elsewhere. |
| Isolation | A sandbox with no ambient credentials and no ambient network by default. Declared egress reaches only declared endpoints, through broker-issued credentials; undeclared access is denied and reported as a contract violation. |
| Determinism | Same inputs, same verdicts — no hidden state, so a historical result is reproduced rather than argued about. |
| Versioned, effective-dated policy data | Rule definitions, pack versions and activation windows are chained configuration. No compliance rule is compiled into the core. |
In scope: the contract, the engine, the shipped packs and the audit exports. Out of scope, deliberately: rule-pack content beyond the shipped packs, policy-administration UIs and any rendering of findings — that belongs to integrators. The layer exposes data, contracts and events; it ships no application workflows.
Verified on the write path, not in a nightly report
Every posting is checked against the rules that applied to it — synchronously, with the result attached to the entry and the enforcement mode stated openly. The engine is Roadmap (PH-2).
Posting triggers synchronous verification against the active packs and the customer-defined rules for its book, scenario and jurisdiction scope — customer rules come in two forms, declarative rule packs and sandboxed rule modules, both versioned and signed. What comes back is structured rather than narrative: rule id, version, severity and disposition recorded on the entry — so “why did this posting pass?” has an answer with a version number on it. Nothing is verified in hindsight and then retro-fitted to the entry.
Deployments choose the semantics per pack. Fail-closed rejects the posting with the finding attached and no ledger effect — nothing enters the books. Advisory lets the posting proceed and keeps the finding, which then travels into audit exports. The mode is visible in every finding and every export, so no reader has to guess whether a rule could have stopped a posting.
Findings have a lifecycle — open, then dispositioned — and typed severities. Waivers and overrides are explicit artifacts: approvable, expiry-bounded, linked to the finding, and never a silent suppression. An expired waiver means the block comes back. Overrides respect separation of duties, and a blocked posting stays blocked until it is dispositioned.
Rules, packs and activation windows are versioned, effective-dated data. Activate a rule mid-period and a pre-activation posting re-verified as of its knowledge time still reproduces its original verdict; evaluate one entry under two pack versions and the verdicts differ exactly by the rule diffs between them. History is not re-scored when policy changes — it is re-read under the policy that applied.
0 rules
compiled into the core — rules, packs and windows are versioned data · product documentation §6.2 · Roadmap (PH-2)
≤ 100 ms
design budget: added p99 per entry for synchronous evaluation against the baseline pack at reference load · product documentation §6.3 · Roadmap (PH-2)
Decision (2026-09-19) — write-path module governance. Third-party modules on the write path run sandboxed under a per-module evaluation budget; operators hold a degrade-to-advisory switch (module verdicts stop blocking while the finding stream continues) and a break-glass path for module failure. Every switch flip is a dual-controlled, separation-of-duties-logged administrative event — never a silent config edit. All of it is Roadmap (PH-2).
IFRS first, then jurisdictions — signed, and installable offline
Packs are how standard depth arrives without the core changing: one maintained pack per supported standard family, each rule mapped to the authority it cites.
The product ships at least one maintained pack per supported standard family, starting with an IFRS baseline and followed by jurisdictional GAAP and tax packs. Each pack maps its rules to citable authority and to a book, jurisdiction and effective window — so a finding can cite the rule id, the authority reference and the pack version that produced it.
Pack updates are versioned artifacts and they must be signed. The loader verifies signatures against a published trust root and refuses unsigned, tampered, rolled-back or downgraded versions; trust-root fingerprints are published, so a disconnected site can verify what it installs. A refused install is a recorded event, not a quiet failure.
Compliance scopes bind to the legal entity — jurisdiction, functional currency, reporting regime — and to the book, with consolidation-level scopes kept distinct from entity-level ones. Reassigning an entity is an effective-dated, audited change: postings after the effective date evaluate the new packs, while earlier postings re-verify under the old packs as of their time. The entity registry is defined data (identifiers including LEI and vLEI, effective-dated lifecycle), never a free-text entity string.
Air-gapped deployments install packs from offline bundles with no network access, and signature verification passes against the published trust root — the same offline discipline as the deployment itself.
| Standard family | What it adds | Status |
|---|---|---|
| IFRS baseline (first) | Rules mapped to citable IFRS authority — the baseline every supported deployment starts from | Roadmap (PH-2) |
| Jurisdictional GAAP & tax packs | Country-level rules mapped to book, jurisdiction and effective window; new jurisdictions added as mapping data, not code | Roadmap (PH-2) |
| Statutory & taxonomy extracts | XBRL GL journal-level, SAF-T with filing calendars, and an auditor-oriented ISO 21378-shaped extraction from the same data — unmapped identifiers fail loudly, never vanish | Roadmap (PH-2) |
| Regulatory identifiers | LEI and vLEI as first-class entity and counterparty identifiers; ISO 20022 party, purpose and remittance semantics survive into postings and exports instead of flattening into memo text | Roadmap (PH-2) |
The same contract carries industry logic
Compliance rules are not the only thing that should never be hardcoded. Vertical logic — revenue recognition, billing mappings, industry taxonomies — plugs in through a domain-extension contract of the same shape.
Beyond packs, the domain-extension contract lets industry logic live outside the ledger: registration and discovery; a declared scope over entry and account classes, domains and event hooks; synchronous or deferred evaluation hooks with structured outcomes; sandbox isolation; deterministic verdicts; and installation from offline bundles. The core embeds no industry logic — a vertical is a module, not a fork.
| Domain module (illustrative) | What the module decides | What the ledger still owns |
|---|---|---|
| SaaS revenue recognition | How a billing event becomes a schedule — deferred slices, recognition postings, contract modifications | Double-entry balance, immutability, provenance, and the audit trail on every posting |
| Healthcare billing | How claim and coding vocabulary maps into accounts and dimensions, and what a billing structure must satisfy | The same: the module describes the business, never the ledger's invariants |
Scope keeps it honest. A module registered for SaaS revenue recognition is never invoked for an unrelated entry; when a matching entry is booked, the module's structured outcome is recorded on that entry as a provenance-carrying verdict. Two runs over the same inputs produce identical verdicts, and a module that attempts undeclared network or credential access is denied and reported as a contract violation.
domain-extension contract surface (interface only) · PH-1; full domain-module tooling · Roadmap (PH-2)
Evidence a third party can rebuild without ledger access
Audit is the test of everything above: if a number cannot be reproduced from an artefact, compliance is a description rather than a control.
Primitives that exist now
- Chain-hashed history with an independently runnable offline verifier — tamper-evidence you check yourself, not vendor assurance.
- OCEL 2.1 JSON export of the lifecycle, with OCEL 2.0 accepted inbound.
- Typed corrections carrying reasons — reversal, adjustment or restatement, never an edit.
- Approvals bound to content hashes, void the moment the content changes.
- A sealed evidence bundle for completed reconciliation runs: manifest, signature over the manifest, byte-reproducible archive verifiable offline.
chain verification, OCEL 2.1 JSON export and the sealed reconciliation bundle · PH-1
Roadmap The compliance evidence package
For any ledger, period and belief instant, the layer will produce a self-contained package: sealed close checkpoints, the sealed-to-now delta, typed corrections with reasons, approvals bound to content hashes, rule verdicts, chain roots and inclusion proofs — sufficient for a third party to reproduce the figures with no ledger access at all.
For SOX and ICFR consumers the package additionally carries control-testing evidence rebuilt from stored policy evaluations: for a sampled population, each entry's evaluated tier and control type, its rule verdicts, approval bindings and any waived or overridden findings — a workpaper set with population, sample basis, evidence per control and exceptions, reproducible from the package alone.
audit evidence package including the control-testing rebuild · Roadmap (PH-2)
Compliance layer FAQ
How does compliance plug into a ledger?
The core stays domain-independent. Rule packs and industry modules register against versioned contracts — declared scopes, synchronous hooks, structured findings, sandbox isolation — and install from offline bundles. PH-1 ships the contract surface as an interface; the rules engine, the IFRS baseline pack and findings with waivers are Roadmap (PH-2). No compliance rule is compiled into the ledger's core.
What is the difference between fail-closed and advisory rules?
Fail-closed blocks: a failed blocking rule rejects the posting with the finding attached and no ledger effect, so nothing enters the books. Advisory lets the posting through and keeps the finding, which persists into audit exports. The mode is set per pack and stated in every finding and export — so nobody has to guess whether a rule could have stopped a posting.
Which packs ship, and can they be installed in an air-gapped site?
At least one maintained pack per supported standard family: an IFRS baseline first, then jurisdictional GAAP and tax packs, each rule mapped to citable authority and an effective window. Packs are versioned artifacts, installable offline, and must be signed — the loader verifies against a published trust root and refuses unsigned, tampered or downgraded versions. All of it is Roadmap (PH-2).
Do you hold SOC 2 or ISO 27001 attestations?
Not yet. SOC 2 Type II and ISO 27001 alignment are targeted inside PH-2, so nothing here should be read as a claim that an attestation is held. What exists today is the substrate an audit runs on: chain-hashed history, offline verification any third party can run, typed corrections carrying reasons, and approvals bound to content hashes. The evidence package itself is Roadmap (PH-2).
Tell us which regime you file under
IFRS, a national GAAP, a vertical billing model — bring the rules that apply to you and we will walk the contract surface with you, labelled PH-1 or Roadmap.