Capability map
This tab is the long form of the seven guarantees. Each page takes one mechanism and answers five questions in the same order:- What it guarantees. The promise, stated so it can be falsified.
- How it works. The mechanism, in enough detail to reason about.
- Where it is enforced. The module, so the claim can be checked rather than believed.
- The test that would fail if it broke. Named, so the guarantee has a regression behind it.
- What goes wrong without it. Usually an audit finding or an executed attack, because most of these controls exist because something failed first.
This curated mechanism map is not the machine-readable capability count.
GreatBook’s registry v1.14.1 carries 116 stable business outcomes across 26 domains: 98 current, seven experimental, one queued, two deprecated and eight forbidden.
Forty-six outcome records are available through 32 shared typed tools; the live transport contract separately contains 50 tools and 18 resources (17 MCP Apps plus the JSON skill registry).
Those are the live public MCP inventories at registry
1.14.1; they do not establish successful use through ChatGPT or Claude.
See Capability lifecycle and anti-drift for that contract.The ledger
The engine that holds the book of record. Everything else in GreatBook is upstream of it.The general ledger
One writer, one path, one transaction.
Every business event becomes a balanced journal entry or it does not exist.
The 18 GL invariants
The preconditions the writer enforces before any write.
Each one refuses.
Immutability and the hash chain
Posted entries are never edited.
A correction is a reversal, and the chain proves nothing moved.
Money is Decimal, always
Float is rejected outright in the posting path.
One conversion boundary, one rounding rule.
FX as of the transaction date
A historical transaction is valued at its own date’s rate, and quarantined rather than posted at par.
The dual IFRS + TT200 chart
An IFRS core with a Circular-200 projection that can be re-mapped without touching a posted entry.
Dimensions, not sub-accounts
Per-party and per-order detail lives on the line, so the chart stays small.
GL mechanics
The deep dive: how an entry is actually formed, and which accounts each document and transaction type moves. Where the pages above state a guarantee, these walk the code path and the posting rules.How a journal entry is formed
The request shape, the eighteen checks in order, the two hash chains, and what the caller still owns.
Posting rules: the map
Three rule surfaces, one law: recognise, or refuse - never guess.
Payables and input VAT
The three-leg VAT split onto
1300, the AP obligation, GRNI clearing and landed cost.Receivables and revenue
Invoices, output VAT, receipts, and the factoring distinction the Close list polices.
Payments, rails and treasury
Every movement belongs to a rail, and each rail reconciles against its own source.
Inventory, costing and payroll
The one-way costing chain, the
627 overhead pool, and one person’s cost in one bracket.Adjustments, FX and consolidation
The four note shapes, revaluation, and why a reversal is not an eraser.
What guards the engine
Five layers: the gate, the 18 GL invariants, the database, the chains, the 104 Close checksums.
Sub-ledgers and close
Seven operational sub-ledgers, every balance derived rather than stored, and the reconciliation surface that ties them together at close.The seven sub-ledgers
Settlement, costing, payroll, loans, VAT, adjustment notes, consolidation.
All posting through the one engine.
Nothing stored that can be derived
A stored balance can drift from reality.
A derived one cannot.
This is the failure class the whole finance layer is built against.
Fiscal periods and closing
An entry outside an open period never reaches the database, and a close is a checklist with an honest verdict.
The Close checksums
104 reconciliation tie-outs, each tagged with the phase it is reachable in and the layer that owns a failure.
They report; they do not refuse.
The exception system
What the nightly sweeps leave behind: a durable register, a bounded waiver, and the rule that only a sweep may resolve anything.
Controls
The rules that decide who may move money, and what stops everyone else.Two gates, three people
Strict separation of duties, and the honest account of why the rule used to be decorative.
The posting mandate
The trust boundary of the money path, defeated four times by an adversarial reviewer and rewritten five.
Idempotency and durability
Re-running is safe, a crash mid-flight loses nothing, and one document posts once.
Tenancy, RLS and derived identity
Org-scoped row-level security, read-only database sessions, and an actor the browser cannot choose.
Documents and reporting
Where documents come from, how a signed PDF becomes authoritative, and what comes out at the end.The 146-document registry
One record per document type, generated from the ontology, shared by the Clerk, the Typewriter and the renderer.
Composition and the render seam
What you approved is what you saw, because preview and PDF are the same bytes from the same path.
Statutory reporting
Trial balance, P&L, balance sheet and the TT200 projection, all built from one posted-lines base.
The two things called “checks”
Two different mechanisms in this system are both spelledcheck somewhere in the code, and this documentation never conflates them.
The canonical phrasing when both appear together is “18 GL invariants + 104 Close checksums”.
A broken tie-out is a finding for a human, not a rejected transaction, so one noun for both would oversell one and undersell the other.
Related
- The seven guarantees - the short form of this whole tab
- Two layers on the same documents - the division these mechanisms are tagged against
- How it fits together - where each mechanism sits in the stack
- The agent org - who drives these mechanisms, and what they may not do