​

The GL pipeline

Everything on this page is roadmap, except where a section says it shipped. It is written here because each item is a known gap with a decided or half-decided answer, and a reader who finds a gap in the product should find it named in the documentation first. Legend: 🟢 Live · 🟡 In Development · ⚪ Planned · 🔵 Future

​

The reconciliation knowledge graph 🟢 over the GL and intake

This one shipped. The graph, the generated concept ontology behind it and the recon check family are live over the GL and intake sources, and they have their own page: the reconciliation ontology. What is live is the header grain: nodes for every entry, obligation, settlement, allocation, tax register line, account, period and rail, plus the documents in intake and the Typewriter, and the asserted edges between them. The recon family joins hash chain, the GL invariant sweep and the orphan scan as a fourth family - not as a Close checksum, and not as a GL invariant. Three things about it are still roadmap:

​

Scheduled and triggered reviews 🟢

This one shipped. The Auditor job system runs scheduled and event-triggered reviews, persists each occurrence and keeps durable findings in the exception register. The seeded catalogue includes nightly chain and family sweeps, an hourly orphan scan, period-close coverage, and bounded arrival triggers; Assurance is the generated current inventory. Two properties matter more than the schedule:

• Idempotency. A job that fires twice produces one review, keyed on an occurrence rather than on a timestamp.
• Stable finding identity. The same exception is one item that ages, not a new item every night - and an exception is marked resolved because the book was re-read, not because a run said so.

Findings live in their own table, and a repeat occurrence ages one stable fingerprint rather than appending a duplicate.

​

The Auditor associate ⚪

For an open-ended question - why a supplier’s July invoices do not tie, whether a vendor has been paid twice - the Auditor would work like an associate: write a to-do list, choose from a fixed set of read-only steps, work through the list, and produce a report. The containment rules are the interesting part, and they are decided: Every step is logged with what it ran, what it got back, and a fingerprint of the result, so any conclusion can be re-checked by re-running the same query. An investigation that stops early - a budget, a dead end - says so and names the questions it did not answer.

​

Remaining multi-currency work ⚪

The schema-owned 307-code currency enum, Typewriter controls, operator FX rate-load path, VAT register native/base evidence and replay-safe obligation creation are built. Automatic realised-FX booking remains open.

​

Analytics and reporting 🔵

The direction is read-only analytics over the dimensioned ledger, not a second book. The constraint that will not move: analytics reads the book. It never becomes a place where a number is computed differently from how the ledger computes it, because two answers to the same question is the failure mode the single writer exists to prevent.

​

Known engineering gaps, named ⚪

​

Related

• What is live - the current status board
• What guards the engine - what already holds
• The Auditor - the seven runnable families and explicit close-gated scope
• The API reference - the surface these would be reached through