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 |
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.
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).
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.