How Orbital Thinks: Eight Principles Behind the Document Substrate
A principle that is not enforced by something is a slogan. Each of the eight below is stated in one line, then followed by the mechanism in the Document Substrate that makes it true, so a reader can check whether the claim holds rather than take it on trust.
Two of them, validation and verification, are the pair everything else hangs off. They answer different questions and they fail differently, so they are worth separating carefully before the rest.
1. Garbage in, garbage out. Validation is the quality gate.
Validation asks: is this data acceptable and usable according to our rules? Does it conform to the expected format, the schema, the internal consistency checks, the firm's policy on what a complete file looks like? It is the gate on the way in.
The failure it prevents is the oldest one in computing. A model given a garbled scan, a bank statement export that quietly omits transactions, or a rental job with no property schedule will produce output that reads fluently and is wrong. The problem was never the model. The input was garbage, and no amount of capability downstream repairs that.
How the substrate enforces it. Before a job runs, a pure code engine assigns each document to the slot its confirmed type belongs in and checks presence, period and cross-document consistency. A slot that is missing is reported as missing; a transaction export does not satisfy the bank statement slot, because it states no opening or closing balance and can never be shown complete. The result is a chase list a person can send to the client before any money is spent on generation. A check that cannot run returns "needs review", never a silent pass. The first real end-to-end run on a practice's files returned "incomplete" for two true reasons, and that was the correct answer.
2. Doer to reviewer. Verification is the accuracy layer.
Verification asks: is this data true, accurate and genuine, and does it match a trusted source? Not "is it well-formed" but "is it right". It is the check on the way out.
This is the principle that changes what people do all day. If every figure the machine produces can be shown to be true to its source, or flagged when it cannot, then the accountant, the property manager or the reviewer no longer has to do the reading. They review the machine's reading, and they start with the items the machine was least sure about. Confidence-based routing is what makes the shift honest: the confident items are still checked, but they are checked by code, and the person's attention goes where it is needed.
How the substrate enforces it. Every scalar a model reads from a document is re-located in the page text and stored with its page and character span. A figure that is not on the page is marked unsupported, never passed. Eighteen of twenty-two document types carry arithmetic checks that run in code: a statement must foot from opening to closing balance, an invoice's lines must add to its subtotal, dates must sit inside the period. A reading that fails gets exactly one repair attempt, accepted only if it introduces no figure absent from the page. Everything that still needs a person lands in one verification queue, with a plain-language reason. A reviewer's correction is keyed to a stable identity so it survives re-processing, and a mark that says "confirmed by a person" is recorded as their judgement, not as the system's verdict.
3. Keep the model out of the parts that have to be defensible.
The model reads and suggests. Code checks and decides. A person signs.
The usual framing of "what AI can't do" is a capability question: where is the frontier? For work whose output has to be defended to a partner, a regulator or an auditor, the sharper question is what the model must not do, regardless of how capable it becomes. A completeness verdict, a sum, a figure in a client letter: these have to come out the same way every time from the same inputs, and a probabilistic component in that seat cannot give you that.
How the substrate enforces it. Models run in exactly two places: reading and suggesting at ingest, and drafting the narrative of a reporting letter. No model call determines completeness or does arithmetic. Where a total is needed, code sums the stored figures, kept separate per currency. The workpaper and the draft letter are produced by fixed renderers with no model in the mapping, so the letter cannot state a figure the workpaper does not carry. Where the documents do not state a figure, the letter says so instead of inventing one. Every prompt is versioned in git and stamped on every trace, and a set of deterministic evals gates each change in continuous integration; on the redaction suite, the pass mark is zero leaks across every case.
4. Personal details never leave the building.
Any business that handles customer data has one thing it cannot get wrong: leaking it. The protection has to be built into the processing, not written into a policy.
The documents most worth putting AI to work on, bank statements, tax returns, invoices, agreements, are the ones most full of personal details. A firm cannot send those to a cloud model as they are, and a vendor's promise not to retain data is a promise, not a mechanism. The only protection a firm can verify for itself is one where the model is never given the details in the first place.
How the substrate enforces it. Redaction runs in three stages before any model call: pattern rules for anything with a fixed shape or checksum (IRD numbers, bank accounts, company numbers, credit cards), a small model pass on every page for what only context reveals (people, organisations, addresses), and an independent detector as a final check. Each real value is encrypted into a vault and replaced with a placeholder, scoped per document so the same placeholder can never mean two different people. Everything downstream, the search index, the extracted figures, the prompts, the transcripts and the traces, holds only placeholders. Real values are restored once, server-side, after the model has finished, only for a person already authorised to see that document, and every restore writes an audit record. A check on every outgoing prompt fails closed if it finds a personal detail. The hosted model sits behind a gateway with zero data retention as a second layer, not the first. On the redaction test suite, the pass mark is zero leaks across every case. Two edges are documented rather than hidden: filenames are not redacted, and the draft client letter shows real names because it is addressed to the client, with each showing recorded.
5. Ledger, not spreadsheet.
A spreadsheet is a general-purpose grid for data, calculation and analysis. A ledger is a record organised by account, where every entry has provenance.
Most small firms run on spreadsheets and group chats, and the spreadsheet is where the work goes to lose its history. Anyone can overwrite a cell. A formula can be broken by a paste. Nobody can say, six months on, who changed a figure or why. The value of a system of record is exactly the thing a spreadsheet does not have: an entry that cannot be silently changed, with a reason attached to every change.
How the substrate enforces it. Records are kept the ledger way. Each extracted figure carries its source page and span. Each correction keeps the original, the replacement, who made it and why. Each reveal of a real name or account number to a person writes an immutable audit row. Excel was assessed as the calculation engine and rejected; it is used only at the export boundary, where the finished workpaper is handed over in a form the practice's tools already read. The ledger itself is not Orbital's either: the system never posts to it. The workpaper and letter are drafts a reviewer settles, and the reviewer decides what goes to the client or the accounting system.
6. One install per customer.
Your documents live in accounts you own, not in a shared tenancy with other firms.
Multi-tenant software pools every customer's data in one database and relies on code to keep them apart. For a firm handling other people's financial records, that is a harder security story to tell than "your install, your database, your keys, and nobody else's data in it". It is also a simpler story to leave: the accounts are yours.
How the substrate enforces it. The substrate is instantiated one install per customer from a shared foundation, in the customer's own cloud accounts, and managed by Orbital. Within an install, each client of the practice has its own document group, queries are scoped to that group by default, and row-level security in the database enforces the separation. Cross-client questions are gated explicitly. The hosted model sits behind a gateway with zero data retention, and nothing in a customer's data is used to train anything.
7. Small firms first.
Practices, property managers, professional services, councils and co-ops under-bought software because bespoke was never affordable. It is now.
Configurable off-the-shelf software does not do what a specific firm needs, because two firms doing nominally the same work do not have the same operational needs. The alternative used to be a bespoke build priced out of reach of anyone but a corporate. What has changed is that the code is the cheap part. The expensive part, working out exactly what this firm's jobs require, is a conversation, and a conversation is affordable at small-firm scale.
How the substrate enforces it. The general parts are built once and reused: reading scanned and photographed documents, redaction, grounding, the review queue, the eval harness. A new install pays only for what is specific to it, and a new document type is one schema file and one registry entry. The definitions view lets a practice add a check or teach the system a bespoke document type without a developer, and the practice manual holds the firm's own account of how each job is worked, versioned, with a test that fails the build if the manual and the checks disagree.
8. Expertise is captured, not generated.
Models, prompts and frameworks are commodities. What "complete" means for your jobs, and the record of every correction your reviewers make, is the part nobody else has.
The model supplies intelligence: reasoning through an unfamiliar problem from whatever context it is handed. Expertise is different. It is accumulated, situated competence in one specific domain, answering the way a senior at this firm would. One firm's rental property engagement is its own small world: its own document types, its own tolerances, its own sign-off habits. None of that is in any training set, so no model can be prompted into it. It lives in the head of a practitioner who has never written it down, and the first written version is always wrong, so the process has to expect iteration.
How Orbital captures it. Every engagement starts with a Map, and the Map starts from artefacts the firm already produces rather than a blank page: the workpaper, the checklist, the letter that went to the client. I shadow one real job from the shoebox to the sign-off. Then short, time-boxed sessions with the people who do the work, built around two questions that unstick most experts: what would a defensible answer to your recurring questions have to be grounded in, and what does a junior get wrong in their first six months? A structured interview keeps asking the next question so the expert never has to compose from nothing, and a person confirms every answer before it is written down. The output is a practice manual seed in the firm's own words, a completeness specification per job, and an architecture note. It is the first paid deliverable and it stands on its own.
How the substrate keeps it. Expertise goes into versioned artefacts, not ad hoc prompts: document types, checks, workflow rules, the practice manual, and the test cases that hold each of them to account. Every correction a reviewer makes is recorded as this document type, this field, the model said X, a person said Y, because Z, and becomes a permanent test case. A capture path is only as good as its worst gap, so every human decision in the system writes a record. The expertise accumulates in files the firm can read, and it stays with the firm.
These eight are not independent. Validation and verification are the two halves of one discipline; the model boundary is what makes both defensible; the privacy boundary is what makes the work possible on real client files at all; the ledger discipline is what makes the record worth keeping; single instances are what make the record safe to hold; small firms are who it is for; and captured expertise is where every engagement begins and what every correction adds to.
The Document Substrate · Explained simply · Every domain has its substrate · Project detail
Email: info@orbital.co.nz