> ## Documentation Index > Fetch the complete documentation index at: https://docs.vinmake.com/llms.txt > Use this file to discover all available pages before exploring further. # Capability map > Every mechanism GreatBook relies on, what each one guarantees, and where it is enforced in code. # Capability map This tab is the long form of [the seven guarantees](/greatbook/guarantees). Each page takes one mechanism and answers five questions in the same order: 1. **What it guarantees.** The promise, stated so it can be falsified. 2. **How it works.** The mechanism, in enough detail to reason about. 3. **Where it is enforced.** The module, so the claim can be checked rather than believed. 4. **The test that would fail if it broke.** Named, so the guarantee has a regression behind it. 5. **What goes wrong without it.** Usually an audit finding or an executed attack, because most of these controls exist because something failed first. That last section is what turns a feature list into an argument. Nearly every control here was written down after a specific defect, and the codebase records which one. 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](/greatbook/greatbook/capability-registry) for that contract. ## The ledger The engine that holds the book of record. Everything else in GreatBook is upstream of it. One writer, one path, one transaction. Every business event becomes a balanced journal entry or it does not exist. The preconditions the writer enforces before any write. Each one refuses. Posted entries are never edited. A correction is a reversal, and the chain proves nothing moved. Float is rejected outright in the posting path. One conversion boundary, one rounding rule. A historical transaction is valued at its own date's rate, and quarantined rather than posted at par. An IFRS core with a Circular-200 projection that can be re-mapped without touching a posted entry. 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. The request shape, the eighteen checks in order, the two hash chains, and what the caller still owns. Three rule surfaces, one law: recognise, or refuse - never guess. The three-leg VAT split onto `1300`, the AP obligation, GRNI clearing and landed cost. Invoices, output VAT, receipts, and the factoring distinction the Close list polices. Every movement belongs to a rail, and each rail reconciles against its own source. The one-way costing chain, the `627` overhead pool, and one person's cost in one bracket. The four note shapes, revaluation, and why a reversal is not an eraser. 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. Settlement, costing, payroll, loans, VAT, adjustment notes, consolidation. All posting through the one engine. A stored balance can drift from reality. A derived one cannot. This is the failure class the whole finance layer is built against. An entry outside an open period never reaches the database, and a close is a checklist with an honest verdict. 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. 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. Strict separation of duties, and the honest account of why the rule used to be decorative. The trust boundary of the money path, defeated four times by an adversarial reviewer and rewritten five. Re-running is safe, a crash mid-flight loses nothing, and one document posts once. 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. One record per document type, generated from the ontology, shared by the Clerk, the Typewriter and the renderer. What you approved is what you saw, because preview and PDF are the same bytes from the same path. 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 spelled `check` somewhere in the code, and this documentation never conflates them. | Say this | What it is | Count | When it runs | What it does | | ------------------- | ----------------------------------------------------------------------------------- | ------- | ----------------------------------------------------------- | ------------ | | **GL invariants** | integrity rules enforced inside the single writer | **18** | *before* any write, on every posting | **refuses** | | **Close checksums** | the v12 workbook's reconciliation tie-outs over the GL and the seven Books families | **104** | 78 of them **continuously**, nightly; the other 26 at close | **reports** | 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](/greatbook/guarantees) - the short form of this whole tab * [Two layers on the same documents](/greatbook/two-layers) - the division these mechanisms are tagged against * [How it fits together](/greatbook/architecture) - where each mechanism sits in the stack * [The agent org](/greatbook/agents/index) - who drives these mechanisms, and what they may not do