Eight Principles Behind the Document Substrate
A principle is only worth stating if something enforces it. Each one below has a single line, a short reason, and the mechanism in the Document Substrate that makes it true, so you can check it.
The first two, validation and verification, are the ones the rest depend on.
1. Garbage in, garbage out. Validation is the quality gate.
Validation asks: is this file complete and usable by our rules? It is the check on the way in.
A model given a garbled scan, or a bank export with missing transactions, writes an answer that reads well and is wrong. Nothing downstream repairs bad input.
How the Document Substrate enforces it.
- Code, not a model, puts each document in its slot and checks presence, period and consistency across documents.
- A missing document is reported as missing. A transaction export does not fill the bank statement slot, because it has no opening or closing balance.
- The result is a chase list for the client, before anything is generated.
- A check that cannot run returns "needs review", never a pass.
2. Doer to reviewer. Verification is the accuracy layer.
Verification asks: is this figure true to its source? It is the check on the way out.
If every figure is either shown to be true or flagged, people stop doing the reading. They review the machine's reading instead, starting with what it was least sure of. The confident items are still checked, by code.
How the Document Substrate enforces it.
- Every value read from a document is traced to its page. A figure that is not on the page is marked and left for a person, not passed silently.
- Sixteen of twenty-two document types have arithmetic checks in code: a statement must foot, invoice lines must add to the subtotal, dates must fall in the period.
- Anything that needs a person goes into one review queue, each item with a plain-language reason.
- A reviewer's correction survives re-processing and is recorded as their judgement.
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.
A completeness verdict, a total or a figure in a client letter has to come out the same way every time. A model cannot guarantee that, however capable it becomes.
How the Document Substrate enforces it.
- Models do three jobs: reading documents, answering questions about them, and writing the wording of a draft letter.
- Code adds every total. No model decides whether a file is complete.
- The workpaper and letter take their figures from code. A draft letter that states any other figure is rejected.
- Every prompt is versioned, and changes are tested against evaluation suites. For redaction, the pass mark is zero leaks.
4. Personal details never leave the building.
The protection has to be built into the processing, not written into a policy.
The documents most worth reading with AI are the ones most full of personal details. A vendor's promise not to keep data is only a promise. The protection a firm can check is that the model never receives the details.
How the Document Substrate enforces it.
- Before the model that answers questions or drafts the letter sees the text, names, addresses, IRD numbers, bank accounts and company numbers are found in three passes and replaced with placeholders. Reading the original document is the exception: the service that turns the file into text, and for some document types the service that reads the figures, receive the original file, and the redaction model reads the names it replaces.
- Real values are encrypted in a vault. The search index, extracted figures, prompts and logs hold only placeholders.
- Real values are restored after the model has finished, only for a person allowed to see that document.
- A last check runs on every prompt before it is sent.
- Two known gaps are documented: filenames are not redacted, and the draft client letter shows real names because it is addressed to the client.
5. Ledger, not spreadsheet.
Every entry has a source, and every change has a reason.
In a spreadsheet anyone can overwrite a cell, and six months later nobody can say who changed a figure or why.
How the Document Substrate enforces it.
- Every extracted figure keeps its source page.
- Every correction keeps the original, the new value, who changed it and why.
- Every restore of a real value writes a permanent audit record.
- Excel is used only for export. The system never posts to the firm's accounting system; a reviewer decides what goes there.
6. One install per customer.
Your documents live in accounts you own, not in a database shared with other firms.
Shared software keeps customers apart with code. "Your install, your database, your keys" is easier to defend, and easier to leave.
How the Document Substrate enforces it.
- One install per customer, in the customer's own cloud accounts, managed by Orbital.
- Each client of the practice has its own document group, kept separate by the database itself. Questions across clients have to be allowed explicitly.
- The hosted model keeps no data, and no customer data is used for training.
7. Small firms first.
Bespoke software used to be too expensive for small firms. It no longer is.
Two firms doing the same kind of work have different needs, so off-the-shelf software rarely fits. The code is now the cheap part. The expensive part is working out what this firm's jobs need, and that is a conversation.
How the Document Substrate enforces it.
- The general parts are built once and reused: reading documents, redaction, tracing figures, the review queue, the tests.
- A new install pays only for what is specific to it.
- A practice can add a check or a new document type without a developer.
8. Expertise is captured, not generated.
Models are bought. What "complete" means for your jobs, and every correction your reviewers make, belong to you.
How a firm does a job is not in any training set. It is in people's heads, and the first written version is always wrong, so it has to be revised. Written down, it is the firm's substrate.
How Orbital captures it. Every engagement starts with a Map. I follow one real job from inbox to sign-off, starting from the firm's own workpapers, checklists and letters, then run short sessions with the people who do the work. Two questions do most of the work: what does a defensible answer depend on, and what do new staff get wrong? A person confirms every answer. You receive a practice manual seed, a completeness specification for each job and an architecture note, paid for on its own.
How the Document Substrate keeps it. Expertise goes into versioned files the firm can read: document types, checks, workflow rules, the practice manual and their tests. Every reviewer correction is recorded (this field, the model said X, a person said Y, because Z) and becomes a permanent test case.
Workflows fit the Document Substrate to each firm
A workflow defines a job or engagement. It has three parts.
- Slots. The documents the job needs, each named. For a rental property: the bank statement, rent summary, loan statement, rates bill and invoices.
- Rules. Checks that run in code over the figures read from those documents: do they agree, is a month missing, is anything counted twice. No model takes part, so the same documents always get the same verdict.
- Outputs. A report on screen and a workpaper in Excel or Word, stamped DRAFT until every slot is filled and every rule passes.
The Document Substrate is the same for every firm. The workflows, and the practice manual that explains each rule, are what change from one firm or industry to the next.
The eight work together. Validation and verification are one discipline, and keeping the model out of the defensible parts is what makes both hold. Redaction makes it possible to work on real client files. The ledger makes the record worth keeping, and one install per customer makes it safe to hold. Small firms are who it is for, and captured expertise is where every engagement starts.
The Document Substrate in detail · Explained simply · Worked examples across six professions · Project detail