C1 — Balance Equations

In double-entry accounting, every transaction has two equal and opposite impacts. Debits equal credits. The books must balance — and if they don't, you know immediately that something is wrong, and exactly where.

Nexsus takes that same discipline and applies it to everything: your data, your schema, even the vocabulary the system uses to name things. Underneath every record is a set of mathematical equations that must hold true at all times. Every write is checked against them before it lands. If it would break one, it is rejected — and the substrate names the exact equation that failed. This is the control system that lets an AI agent — or several — build and rewrite a database by conversation, and never leave it in a broken state.

The one law: the Closure Equation

∀ (source, relationship, target) ∈ references : target ∈ substrate

In plain English: nothing can point at something that isn't there. Every reference — a record to its model, a field to its definition, a link from a sale to a customer — must resolve to a real, declared row inside the substrate. Every other balance equation is a specialisation of this one rule, applied to a different layer of the system.

If you're a database person, you'll recognise the shape: referential integrity. The difference is scope. A foreign key protects references between rows. In Nexsus, the schema itself lives inside the substrate — every field definition, every model shape, every relationship type is a governed, versioned citizen of the same system. The schema is data — so the schema is governed by the same mathematics as the data.

The chart of accounts

In accounting, nothing is posted without an account in the chart of accounts. Nexsus works the same way: behind the Registry you see on the dashboard sit three governed catalogues — which kinds of row may exist, which kinds of link may exist, and which models may exist, each with an owner and a purpose. Before a model can be created, it must be registered. Before a record can be filed, its model must exist. The catalogue is not paperwork — a record with no registered home simply cannot be written.

The laws, layer by layer

The equations stand guard over seven layers of the system. A few, concretely — using a tiny CRM with a Customer model and a SalesTransaction model:

• Identity. Every record has one 40-digit identity code, guaranteed unique and well-formed. Reuse a code, or write CUST-42 where a code belongs — rejected. Essential columns — identity, content, status, both ends of every link — can never be blank.
• Schema. A model's shape must reference real, declared fields. Every row must declare a kind the system currently recognises. No mystery rows.
• Structure. Nothing can claim membership of a model that isn't there — no homeless fields, no homeless data.
• Data. Every column you fill must be one the model declared (send a discount_pct the model never defined — rejected, naming the offending key). An enum field only takes its declared values (refunded when the field allows pending / paid / cancelled — rejected). Even display labels are governed: name a model Invoyce for {customer} and the misspelling is caught before it can save.
• Relationships. A link can only join records that exist, and its kind must be a recognised relationship that matches the link itself. Attach a sale to a customer who was never created — refused.
• Catalogues. A new model needs its catalogue entry first, and the catalogues stay clean: exactly one active definition per kind.
• Audit. Nothing is ever hard-deleted. Try to delete a churned customer and their order history — refused: records are superseded and archived, never erased. History is permanent.

How they're enforced

Every single write is validated against the full equation set before it commits. If it would break a law, you get back the specific law — as a stable error code (P-0001 … P-0013), an API contract your code or your agent can act on, not a mystery 500.

At the centre is a discipline called Six-Way Reconciliation: before any record lands, six independent views of it — from its identity, through its content and its search vectors, to the sentence it renders of itself — must all tell the same story. Any disagreement, and it's rejected. Six witnesses, one verdict.

All of this is enforced inside the database engine itself — not in application code that a bug, a bypass, or a stray script could skip. The platform continuously audits that every protection is standing on every workspace — and a workspace that isn't fully protected doesn't pretend: it reports itself as degraded, honestly, until it is.

The technology, grounded

None of this is exotic. The store is PostgreSQL — battle-tested, transactional, auditable; history is append-only with the current state one query away. Numbers and dates are first-class, queryable values — and one of the equations guarantees that what you aggregate always agrees, provably, with what was recorded. Search is three vectors per record: one structural — computed deterministically, no AI involved — and two semantic — 1024-dimension embeddings from Voyage AI's voyage-3-large, stored and searched with pgvector and HNSW indexes. The surface an AI talks to is a Model Context Protocol server — Python, built on FastMCP over the official MCP SDK, JSON-RPC 2.0 over streaming HTTP, per-customer OAuth with the standard discovery handshake — Docker-deployed on Railway, with every token scoped to its own workspace at the database level.

The arch

Think of the equations as the stones of an arch. No single one carries the weight; keyed together — the Closure Equation as the keystone — they turn the downward force of every write into something the structure carries. And an arch tightens under load: the heavier the traffic of writes, the more firmly the stones lock. More data doesn't loosen this system — it proves it.

Why this matters for AI agents

Agents are stateless, they forget between sessions, and increasingly there's more than one of them on the same job. A shared memory is only trustworthy if it can't be corrupted — if no agent can leave it half-written, and every agent reads exactly what the others committed. Try it yourself with two agents on one workspace:

In Nexsus, start a research subject: 'EV battery thermal runaway'. Record the key finding and its source.

What do we know about EV battery thermal runaway? Add a mitigation and link it to that finding.

The second agent — a different AI, no shared chat history — reads the first one's record exactly, adds its own, and links them; the link is only allowed because both endpoints exist. And when any agent attempts a write that would break an equation — linking to a customer that doesn't exist, setting a value outside the allowed set, hard-deleting a shared record — the substrate rejects it by name.

That's the difference between a pile of notes an AI hopes is consistent, and a memory layer that is provably consistent. That's why Nexsus is built on balance equations.