Platform

Four layers, and the order matters

Most ERP platforms are a collection of modules sharing a login. This one is a ledger, a data model, an agent layer, and a proof mechanism — assembled in that order, because each depends on the one beneath it being right.

See it on your data

Connect read-only and we will show you your own trial balance reproduced, plus what the agents would have coded.

1 / 3
Works alongside your current ledgerAuthority levels 0–4Correctness suite published

The four layers

Built bottom-up, not bolted together.

The ledger, first

A double-entry engine with invariants enforced at write, real period control, and append-only history. Everything else is built on the assumption that this is correct, so it is the part we publish tests for.

One business graph

Customers, vendors, contracts, invoices, projects, and payments as one model rather than six systems joined by a nightly sync. This is what makes dimensional reporting and agent context possible.

Agents that initiate

Role-based agents that start work without being asked, operate at an authority level you set, and hand you exceptions rather than busywork.

Proof, continuously

A shadow ledger reconciling against the books you already keep, so nothing about adopting this requires trusting us on faith.

QuickBooksQuickBooks190NetSuiteNetSuite190StripeStripe190RampRamp190GustoGusto190ShopifyShopify190SalesforceSalesforce190PlaidPlaid190Business graphone model, all systemsDepartment P&LEntity roll-upProject marginShadow ledgerAgent contextUniversal search

Financial core

The part that has to be right.

Front office

Pipeline and delivery on the same records.

Operations

The operational surface.

Platform & data

What everything else reads from.

Trust & controls

How you know it is correct.

Why the order matters

Almost every platform in this category was assembled by adding modules to an accounting system, and it shows in the seams: a CRM with its own idea of what a customer is, a project tool with its own idea of a department, and a reporting layer that reconciles them monthly by hand.

Building the ledger first and the data model second means the front office and the agents inherit a single definition of every object. That is unglamorous architecture and it is the reason the AR agent can know a customer is mid-renewal, the close agent can know which subledger has not tied, and project margin can include a vendor bill that arrived this morning.

A module list tells you what a system contains. The order it was built in tells you whether the parts actually know about each other.

You do not have to adopt it in that order

The architecture is bottom-up; the adoption path is not. Most customers start at the top — integrations, reporting, and the AP agent on top of the ledger they already have — and only consider our ledger after a shadow ledger has been reconciling for months.

That is the intended path rather than a concession. It means the riskiest decision comes last and comes with evidence, and it means a company that never wants to switch ledgers still gets most of the value.

What we deliberately do not build

Manufacturing, MRP, warehouse management, a payroll engine, and deep local statutory filing across many jurisdictions. Those are named on the comparison pages with what to use instead, because finding out in month four is worse for everyone.

See it on your own books.

A read-only connection is enough to show you a real tie-out and real agent output within a week.