Use cases · Planning vendors · PG-12 # Budget, forecast and plan on the same ledger as actuals. No ETL, no drift. ◇ Roadmap Consume actuals, budgets, forecasts, plans and simulations from one ledger: the scenario registry, explicit filters and the server-side writability matrix are consumable today; no-copy composition and variance runs arrive with PH-2. - scenario registry - explicit filters - writability matrix - one chain per ledger ## What your module integrates against — shipped today Scenarios are registry data in the ledger your customer already reconciles: a governed axis, not a label on a copied table. ### A registry, not a naming convention Every scenario is a first-class record — code, kind, preset, storage mode, boundary, write window, status, ACL — and the sole authority for existence and writability. Read it before you read or write scenario data: it is queryable by kind, preset, role, status, base, writability and owner. FR-300/309 · PH-1 ### Every posting carries its scenario The scenario tag is mandatory and non-null on every posting row — untagged rows are rejected at write time. There is exactly one Actual per tenant, created at provisioning and undeletable; kind and preset are immutable once postings exist. FR-301/302/304 · PH-1 ### Balanced inside every scenario Within one transaction and one scenario, debits equal credits; a transaction never mixes scenarios and cross-scenario attempts are rejected with a typed error. Per-scenario double-entry is an invariant, not a reporting setting. FR-335 · PH-1 ### Filters are explicit, or explicitly wildcarded Every read takes a named scenario filter — or a documented wildcard recorded in provenance. Unqualified defaults are refused; multi-scenario responses return per-scenario subtotals in separate fields so no client can fold plan into actual by accident. FR-342 · PH-1 ### Writability is evaluated server-side Before any insert or scenario-mutating operation the engine evaluates kind × preset × role × status × write window × locks × delta constraints × caller ACL — and rejects with typed errors: not writable, locked, sealed, expired, outside window, kind mismatch. FR-344 · PH-1 ### Planners write; controllers publish Scenario ACLs separate read, write, publish, lock and admin — so segregation of duties is enforceable in your UX. Visibility is private, shared or public; seals are one-way; planned-number provenance reconstructs how any figure was derived. FR-347/348/324/345 · PH-1 **What arrives with PH-2 (Roadmap).** No-copy planning consumption — your modules read and write the same ledger through API/MCP scenario filters, with no ETL export and no second plan-of-record store. The boundary rule (fixed_date / period_end / last_booked / none) lives on the scenario; composition is explicit — raw, composed or blended, never implicit; variance is computed from composed rows, never stored, never netted; and delta storage over the Actual base targets a ≥5× smaller footprint on the reference profile. FR-341/330/343/352 · ✓ PH-1 — no-copy planning reads and writes, computed variance. FR-316/318–320/331–334/340 · ◇ Roadmap (PH-2) — delta storage, switchover, roll-forward, override and promote. ## Protocol parity, phase by phase Integrate once: MCP mirrors HTTP with the same semantics and error taxonomy, and every row below states what is consumable today versus what the roadmap adds. | Capability your module consumes | Phase | Trace | |---|---|---| | Scenario registry reads, filtered by kind, preset, role, status, writability, owner | ✓ PH-1 | FR-300/309 | | Mandatory scenario tag on every posting; one undeletable Actual | ✓ PH-1 | FR-301/304 | | Explicit-or-wildcarded scenario filters; per-scenario subtotals, never folded | ✓ PH-1 | FR-342 | | Server-side writability matrix with typed errors, on REST and MCP at parity | ✓ PH-1 | FR-344/343 | | Per-scenario ACL verbs and visibility classes; one-way seals; planned-number provenance | ✓ PH-1 | FR-347/348/324/345 | | Boundary rule on the scenario; explicit composition modes (raw / composed / blended) | ◇ Roadmap | FR-318/320 | | No-copy planning consumption, read **and** write — no ETL, no second plan store | ✓ PH-1 | FR-341/343 | | Variance computed from composed rows, never stored, never netted across scenarios | ✓ PH-1 | FR-330/352 | [The scenario dimension, in full →](/scenario-dimension) ## Your planning UX stays yours - Planning UIs, formula engines and modelling logic are explicitly out of scope for the core — that is your product (NG-6). - No UI of ours, ever: the ledger has no screens to compete with yours (NG-1). - Not an EPM suite and not an ERP: it is the data layer your modules read from and write to (NG-2). - Fiat ISO-4217 money, exact-decimal minor units; simulated scenarios expire — they are never deleted, and the chain stays verifiable (FR-107/325). ## What Ledgerbook is not These boundaries are the partnership. Each one is a job we are declining to take from you. - **Not a planning UX (NG-6).** The grid, the formula engine, the driver model and the user experience stay yours, permanently. We are not a step on a roadmap toward becoming your competitor — the ledger's value to you depends on it not being one. - **No models in the core (NG-4).** We do not forecast. We hold the actuals your forecast stands on, disclose how mature each slice is, and accept the plan you produce as first-class scenario data. - **We record committed schedules; we never compute them (NG-1).** Contract revenue schedules, prepaid amortisation, depreciation and lease expense are computed by the subledgers that own them. The ledger records them as committed positions — which is what lets your tool read what is already determined for a future period instead of assuming it. ## Bring one ledger to your planning module The partner track starts with a scenario model review: your composition semantics against the registry, on your customer's real estate shape.