If a system cannot tell you what it did, it cannot be trusted with anything you cannot afford to lose. That is the whole thesis of how we build at SolutionWright, and this is the long form of it.
The problem we are working against
Most software a small business buys today is opaque on purpose. You pay a monthly fee, somebody else runs the box, the box does things, and the only thing that comes back to you is a polished summary. When it works, it is fine. When it goes wrong, you find out late, you cannot tell what was decided on your behalf, and you have no standing to contest any of it. The asymmetry is the product.
We do not want to be on the seller side of that asymmetry. So we build differently, and we publish how, and we let you check.
The pattern has four pieces. None of them are clever. The cleverness, if there is any, is in actually doing them, in order, every time.
1. The append-only ledger
Every meaningful action the system takes — every email sent on your behalf, every record changed, every external call made, every artifact produced — is written to an append-only ledger before anything else gets a copy (Class B). Append-only means we add lines; we do not edit them and we do not delete them. If we got something wrong, the correction is a new line that points back at the bad one. The history of the mistake stays in the record. That is the point.
We do this for one reason: when there is a disagreement later, the ledger is the source of truth, not anyone's memory. You can read it. We can read it. A future auditor can read it. The same file (Class C). No spin layer between the action and the record.
The falsifier here is brutally simple: if you can find an action the system took on your behalf that is not in the ledger, the architecture has failed and we owe you the fix on our time. That is a real test, not a slogan (Class F).
2. Evidence-classed claims
When the system tells you something — "this campaign produced N leads," "this draft is ready," "this integration is healthy" — the claim carries a label that says how we know.
The six classes we use are short on purpose:
- A — empirical, in session. We ran it just now and watched the result.
- B — code or inspection. Somebody read the code or read the artifact and confirmed it directly.
- C — configuration or integration. It is wired up the way the docs say to wire it up; we have not necessarily watched it fire under load.
- E — expert citation. A named outside source says so, with a link.
- F — falsifier present. There is a stated test that would prove the claim wrong, and we will accept that test.
- U — unverified. We are telling you anyway, but we have not checked.
You do not need to memorize this. You just need to know it exists, and you need to know that when we write to you, we will tag the claims that matter. A "U" is not shameful. A "U" disguised as an "A" is shameful. The point of the labels is to make the disguise impossible.
3. Gates and approvals around anything that mutates the world
The system is allowed to read a lot. The system is not allowed to send, change, pay, or speak on your behalf without crossing a gate that names what is about to happen and waits for somebody to say yes (Class B). Reads are free. Writes are gated.
This is not us being slow. This is us refusing to ship the failure mode where a confident-sounding agent quietly executes something nobody asked for and nobody can find later. The gate is the boundary between "the machine helps" and "the machine acts." Both are useful. They are not the same thing and they should not feel the same to the human in the loop.
Anthropic's misalignment work, summarized by Themesis, is one of the reasons we build it this way: there is empirical reporting that small dishonesties in training escalate, in the same model, into hacks and sabotage downstream. We read that, took it seriously, and decided that any system we ship will either gate its mutations or not ship.
4. Every artifact has a falsifier
This is the rule that ties the other three together. Every artifact we hand you — a report, a dashboard, a strategy document, a piece of code, a campaign plan — comes with a written statement of what would prove it wrong. Not "what we are nervous about," not "what we are hedging on," but the concrete test that, if it failed, would mean the artifact does not deliver what it promises (Class F).
Falsifiers do two things at once. They keep us honest while we are building the thing, because we have to name the disconfirming case before we ship. And they give you a tool: if the falsifier ever fires later, you have language to bring it back to us that does not require you to be the expert.
We borrow the rigor from science and we apply it to deliverables. The deliverable is a hypothesis. The falsifier is the test. The ledger is the lab notebook.
Why now, not later
Themesis has a good piece on the gap between today's pattern-matching systems and what would actually count as autonomous intelligence, and the argument that the window to prepare is short. Our reading of it for clients is simpler: whatever you call the next decade of automated systems, you are going to want receipts you can read, and you are going to want them in place before the systems get faster than the conversation about them. Build the audit trail now, while it is still cheap to add.
We treat this as a working hypothesis, not a finished claim. The architecture is in the open. The ledger format is in the open. The gates are in the open. If you find a hole, we want to hear about it before a stranger does.
Where to go next
- The technical receipts — the actual code, the actual gates, the actual ledger format — live on the science page: /science.
- The six evidence classes, written out in one page you can hand to anybody: /six-receipts.
- The longer governance posture, in one place: /transparency.
- If you want to see this architecture applied to your own situation, the entry point is here: /workshop.
Don't take the claim on faith — test the build, inspect the gates, and help us find where it fails.