Skip to content
LedgerMind

Architecture

Nine planes, one pipeline

A plane is not a service and not a screen. It is a responsibility with its own consistency model, its own failure mode and its own reason to exist.

What runs

The same architecture, in the notation your team already argues in

The nine planes below answer how the thinking is organised. They do not answer what actually runs, which is the question somebody on call is asking. Levels one and two answer that. Level three is the plane stack, and level four is the source.

C4 level 1: LedgerMind in contextA system context diagram. On the left, three kinds of user: a finance team, an auditor, and agent principals, all of which reach the LedgerMind system in the centre. On the right, two external sources, bank feeds and source systems, both drawn dashed because no connector to either is built. The finance team prepares and approves, the auditor reads and verifies, and agents propose but never commit alone. The same information is given as a table below this diagram.Finance teamController, accountant, CFOPrepares, approves and closes.Never both sides of one duty.personAuditorInternal or externalReads everything, changes nothing.Verifies the chain independently.personAgent principalsMachine identitiesSame tables, same engine, samelimits. No approval capability.personLedgerMindMulti-tenant ERPRecords what happened, why it wasrecorded that way, and who agreed.Every figure drills to its evidence.systemBank feedsStatement importStatements arrive as uploaded filestoday. No live feed exists.external · designedSource systemsBilling, payroll, CRMNo connector is built. Events enterthrough the application itself.external · designedprepares and approvesreads and verifiesproposes, never commits alonestatement files, uploadedevents, not yetSOLID IS BUILT · DASHED IS DESIGNED AND NOT BUILT
Nothing outside the boundary is connected yet. The dashed boxes are honest about that rather than absent from the picture.
Level one as text: who uses the system, and what it talks to
ElementTechnologyWhat it isState
Finance teamController, accountant, CFOPrepares, approves and closes. Never both sides of one duty.built
AuditorInternal or externalReads everything, changes nothing. Verifies the chain independently.built
Agent principalsMachine identitiesSame tables, same engine, same limits. No approval capability.built
LedgerMindMulti-tenant ERPRecords what happened, why it was recorded that way, and who agreed. Every figure drills to its evidence.built
Bank feedsStatement importStatements arrive as uploaded files today. No live feed exists.designed
Source systemsBilling, payroll, CRMNo connector is built. Events enter through the application itself.designed
  • Finance team prepares and approves in LedgerMind
  • Auditor reads and independently verifies LedgerMind
  • Agent principals propose in, and never commit alone in, LedgerMind
  • Bank feeds reach as uploaded statement files, not a feed, into LedgerMind (partial, not built)
  • Source systems would send events to LedgerMind (designed, not built)
C4 level 2: what actually runsA container diagram. Inside one deployment boundary: the application, built with Next.js and React, calls the domain modules, which read and write a single PostgreSQL database with row-level security enabled and forced. The domain modules also call an in-process embedder and an in-process audit signer. A separate marketing site deployable sits outside the boundary with no connection to the database or the application. There is no message queue, no cache, no second database and no external model API. The same information is given as a table below this diagram.ONE DEPLOYMENT BOUNDARYApplicationNext.js 16, React 19, TypeScriptServer components read through thetenant transaction. 73 route handlers,every one Zod validated at the edge.containerDomain modulesOne deployable, explicit seamsledger, policy, authz, audit, close,banking, fx, consolidation, assurance.A domain imports another's index only.containerPostgreSQL 17pgvector, row-level securityRLS enabled and forced on everytenant table. The application roledoes not hold BYPASSRLS.databaseEmbedderIn-process, deterministicHashed character n-grams, 384dimensions. No model API and no key.Weak at synonymy, and says so.containerAudit signerEd25519, node:cryptoSigns range anchors over the hashchain. The key is not in the repo.containerMarketing siteNext.js, staticA separate deployable with nodatabase, so it survives an outage.containercalls public surfacesSQL, in one tenant transactionindexes and queriesanchors the chainno connection to eitherNO QUEUE · NO CACHE · NO SECOND DATABASE · NO MODEL API
One deployment boundary, one database, and a marketing site that shares nothing with it. The absences are decisions, and they are listed under the diagram.
Level two as text: the containers and how they connect
ElementTechnologyWhat it isState
ApplicationNext.js 16, React 19, TypeScriptServer components read through the tenant transaction. 73 route handlers, every one Zod validated at the edge.built
Domain modulesOne deployable, explicit seamsledger, policy, authz, audit, close, banking, fx, consolidation, assurance. A domain imports another's index only.built
PostgreSQL 17pgvector, row-level securityRLS enabled and forced on every tenant table. The application role does not hold BYPASSRLS.built
Marketing siteNext.js, staticA separate deployable with no database, so it survives an outage.built
EmbedderIn-process, deterministicHashed character n-grams, 384 dimensions. No model API and no key. Weak at synonymy, and says so.built
Audit signerEd25519, node:cryptoSigns range anchors over the hash chain. The key is not in the repo.built
  • Application calls the public surfaces of Domain modules
  • Domain modules runs SQL inside one tenant transaction against PostgreSQL 17
  • Domain modules indexes and queries through Embedder
  • Domain modules anchors the chain with Audit signer

What is deliberately not there

No message queue

An audit record is written in the same transaction as the mutation it describes. A queue between them is a window in which the two disagree, and that window is the whole thing this product refuses to have.

No cache

Authorization is evaluated per call and never cached across a scope change. Caching the rest would buy latency this workload does not need and cost a class of staleness bug that is invisible until a close.

No model API

Nothing calls out to a language model. Determinations are produced by a deterministic solver, and search embeds locally. A model is for where a rule cannot decide, and that path is not built.

No second database

Development and test run PGlite, which is Postgres compiled to WASM, in process. Same migrations, same SQL, same dialect as production. A second dialect is a second set of bugs.

The stack, and what each plane owns

Data moves upward and control moves downward. The ledger does not know the experience plane exists, and it never will.

The nine planes of the LedgerMind architectureNine horizontal layers stacked from the signal plane at the bottom to the experience plane at the top. Data flows upward through them and control flows downward. Each layer is marked as built, partial or designed. The same information is given as a table immediately below this diagram.controldata9ExperienceWorkbenches, command palette, drill to evidence, ask, APIbuilt8GovernanceAudit log, duties, approvals, trust envelopes, model logbuilt7AgentMachine principals, deterministic determinations, agent memorybuilt6AssuranceExpectation engine, exception queue, completenessbuilt5LedgerDouble entry, periods, subledgers, multi-currency, consolidationpartial4JudgmentRule solver, determination memory, confidence, materialitypartial3PolicyThe Accounting Constitution, chart, dimensions, approval policypartial2ContextMaster data, documents, embeddings, lineage, counterpartiespartial1SignalEvent ingestion, connectors, normalization, dedup, orderingdesigned
Data flows up. Control flows down. A lower plane never imports from a higher one.
The nine planes as text
PlaneWhat it ownsState
1. SignalEvent ingestion, connectors, normalization, dedup, orderingNo connector of any kind is built, and there is no event log table. Events enter through the application itself. What exists is deduplication where writes arrive: idempotency keys on the API boundary, and statement lines that reject a second import of the same line.designed
2. ContextMaster data, documents, embeddings, lineage, counterpartiesMaster data, the party model, lineage and hybrid search are built, and the search is genuinely hybrid: pgvector cosine and a lexical index, fused by rank. Missing: a document store, so lineage terminates at the point where a scanned invoice would be. Also missing: the knowledge graph and the digital twin. The index covers governance and organisation records only, and nothing reindexes on mutation.partial
3. PolicyThe Accounting Constitution, chart, dimensions, approval policyThe language, the compiler, the evaluator, versioning, precedence and fixtures-as-a-promotion-gate are all built and tested, and the Constitution now stands in the posting path: a supplier invoice is determined at entry by the policy in force on its own date, and an imported service posts as a reverse charge, four entries rather than two, instead of the treatment the subledger code would have applied. The chart, the dimensions and approval routing are built. What is not built is coverage: four of five event classes still receive the default without consulting it.partial
4. JudgmentRule solver, determination memory, confidence, materialityThe deterministic solver, determination memory, damped confidence and materiality thresholds are built. Precedent retrieval exists over past coded invoice lines and does not exist over past determinations, which is the stage the design calls for. Interpretation and escalation are not built. No language model is called anywhere in the product.partial
5. LedgerDouble entry, periods, subledgers, multi-currency, consolidationDouble entry enforced by the database, periods, both subledgers, dual-currency amounts, revaluation, translation and consolidation with elimination and minority interest are built. Bitemporality, multi-book and policy replay are not. A journal carries a posting date and a wall clock, which is not the same as being able to ask what the books said on a date given what was known then.partial
6. AssuranceExpectation engine, exception queue, completenessThe expectation engine, the exception queue with its closed disposition vocabulary, completeness, bank reconciliation and the close health score are all built. Three of six hypothesis generators are implemented. Every run is started by somebody pressing a button: there is no scheduler, so continuous means re-runnable rather than running.built
7. AgentMachine principals, deterministic determinations, agent memoryAgents are governed principals in the same tables as people, with charters, ceilings and duty classes enforced per action rather than displayed. Each agent's measured track record sits beside the ceiling it narrows, and a widening waiting for a second person appears in that person's queue. A new agent starts able to do nothing. Agent memory exists in one narrow sense: an agent does not raise a finding somebody has already ruled on, and the screen says how many it suppressed. Nothing else reads a prior run, and agents are invoked by a person clicking a button, because there is no scheduler.built
8. GovernanceAudit log, duties, approvals, trust envelopes, model logThe hash-chained signed audit log with range anchors, segregation of duties both static and observed, approvals with quorum and dwell time, the access review and the model log are built. So are trust envelopes: an agent's autonomy level, value ceiling and measured track record decide, per action, whether a proposal commits and notifies, waits for one approver, waits for two, escalates, or is refused. An agent humans keep overriding narrows itself, with nobody turning a knob, and every constraint that fired is shown rather than only the one that won. Whether the approval control is actually operating is measured per approver from telemetry collected since the governance migration. One determination producer of five is wired to the envelope so far.built
9. ExperienceWorkbenches, command palette, drill to evidence, ask, APISixteen workbenches, a capability-filtered command palette, drill to evidence as one primitive that says why it stops, and natural language answered by a slot grammar over a sealed metric list rather than by generating SQL. The API is versioned and goes through one boundary, and it authenticates by session cookie only. There is no machine-to-machine credential, so it is an internal API rather than a public one.built

The pipeline

One business event, end to end

Everything else in the architecture exists to serve this. The interesting fact is not the order of the steps but which plane is answerable for each one.

It does not run end to end today. Two of the eight stages are built, and the missing ones are at the ends: nothing ingests an event at stage one, and stage seven projects into books that do not exist. Each stage below says what happens instead.

How one business event becomes a journal entryEight stages left to right, each owned by a named plane: canonical business event, contextualization, policy selection, accounting determination, trust envelope, accounting event, journal projection, and invariant enforcement. Each stage is marked as built, partial or designed, and only two of the eight are fully built: the accounting determination and invariant enforcement. The first and seventh stages do not happen at all today. The same sequence, with what happens instead at each unbuilt stage, is listed as text immediately below this diagram.SIGNAL1Canonical businesseventdesignedCONTEXT2ContextualizationpartialPOLICY3Policy selectionpartialJUDGMENT4AccountingdeterminationbuiltGOVERNANCE5Trust envelopepartialLEDGER6Accounting eventpartialLEDGER7Journal projectiondesignedASSURANCE8InvariantenforcementbuiltSOLID IS BUILT · DASHED IS NOT · THE TARGET IS THAT AN EVENT ENTERS AT 1 AND IS COMMITTED OR WAITING FOR A NAMED PERSON BY 5
Every stage names the plane answerable for it. Two of the eight are built. It does not run end to end yet, and the text below says what happens instead at each stage that does not.
  1. Signal

    1. Canonical business event

    Normalized, deduplicated, source-attributed, immutable.

    designed

    There is no event log and no connector. Work enters as somebody filling in a form, and the deduplication that exists is at the write, not at an ingestion boundary.

  2. Context

    2. Contextualization

    Which customer, which contract, which entity, which prior events.

    partial

    Master data, the party model and lineage resolve all of this. Documents do not: there is no document store, so a scanned invoice is not part of the context.

  3. Policy

    3. Policy selection

    Which clauses are in force, on this date, for this entity and book.

    partial

    Happens for a supplier invoice, on the invoice's own date rather than today, and the treatment it determines is what posts. Four of five event classes still receive the subledger default without consulting it.

  4. Judgment

    4. Accounting determination

    A proposal with its evidence, the artifact it cited and its confidence.

    built

  5. Governance

    5. Trust envelope

    Commit, queue for a named person, escalate, or refuse.

    partial

    The envelope decides per action, from the agent's ceiling, its value limit, the policy's own declared ceiling and the agent's measured track record, and every decision is visible with the constraints that produced it. Two of five determination producers are wired to it; the other three still reach a human without passing through it.

  6. Ledger

    6. Accounting event

    A committed fact, with its reversal plan attached.

    partial

    A journal is posted directly. There is no separate event layer, so a reversal is an ordinary recorded operation somebody performs afterwards rather than a compensating action computed before the fact commits.

  7. Ledger

    7. Journal projection

    The same fact projected into each book that has to see it.

    designed

    There is one book. Multi-book is not built, so nothing is projected anywhere and an entity's accounting standard is a label rather than a parallel set of books.

  8. Assurance

    8. Invariant enforcement

    Reconciliation, controls, and expectations either satisfied or raised.

    built

The rules

Six constraints the whole thing is built under

  • Data flows up, control flows down

    A lower plane never imports from a higher one. The ledger does not know what a workbench is, which is what lets it be replayed without one.

  • Derived state is rebuildable

    Only the event log and the ledger are sources of truth. Anything projected, cached or indexed can be thrown away and reconstructed, so losing it costs a rebuild rather than a fact.

  • The failure posture is stopping

    Missing context is an error, not a default. A system that guesses when it is short of information is a system whose right answers are indistinguishable from its wrong ones.

  • Tenant isolation is a boundary, not a filter

    Row-level security, enabled and forced, with the application connecting as a role that cannot bypass it. With no tenant set, every tenant-owned table returns zero rows.

  • Constraints over convention

    If the database can enforce it, the database enforces it. Application validation is a better error message, never the guarantee.

  • Agents are principals

    Machine identities hold roles, limits and duty conflicts in the same tables as people, evaluated by the same engine. There is no agent branch in the authorization path.

Where it is

four planes built, four planes partial, one plane designed

The design canon describes the target. This page describes what exists, and the two are not the same thing. Presenting a design as a shipped system is the one claim on a page like this that ends a diligence conversation.

Every state here was read out of the source before it was written down, in both directions. Two planes were understated and one was overstated, and the overstated one was governance, which is the worst place on this page to be wrong.

Built
4Assurance, Agent, Governance, Experience
Partial
4Context, Policy, Judgment, Ledger
Designed only
1Signal

Ask the hard question

A walkthrough runs against a working system. Bring the part of this you do not believe.