Services
Three shapes. One question decides which.
Every engagement answers the same question in a different tense. Is this computation right — was it, will it be, or should this record have been stored at all.
In one line each
- 01Verify an existing systemYou have a computation in production. You want to know whether it is right.
- 02Build with the check includedYou need something built, and you need to defend its output later.
- 03A gate on what you storeBad data is entering a store, and you find out months later.
Each is a fixed fee, agreed before work starts
Before the shapes
Four conditions decide whether this is worth doing at all
A second instrument is expensive. It earns its cost only where all four hold — and we would rather tell you that in the first conversation than in the third invoice.
01
The answer matters
Somebody acts on the output — money moves, a document is signed, a person is scheduled, a record is filed.
If it does not hold
If being wrong costs an afternoon, a test suite is the proportionate answer and it is cheaper than us.
02
Nothing independent checks it today
The system marks its own work. Its tests were written from the same understanding as its code, by the same people, at the same time.
If it does not hold
If a second team already recomputes it by different means, you have the thing we build. Use it.
03
A genuinely different second computation is possible
There is a specification, a physical law, an identity, a conservation rule, or an independent record the answer can be re-derived from.
If it does not hold
If the only way to check the answer is to run the same logic again, a second instrument is theatre. We will say so.
04
The failure is silent
A wrong answer arrives on time, in the right format, inside the expected range. Nothing throws, nothing alerts, nothing looks odd.
If it does not hold
If it crashes when it is wrong, you already have a check. It is called a crash, and it is a good one.
Three of four is a conversation, not a refusal. Two of four usually means the honest answer is a test suite, a reconciliation, or a person — and we will name which.
The engagements
What you can ask for
Fees and durations sit below the substance on this page for the same reason they sit below it in a conversation.
01
Verify an existing system
You have a computation in production. You want to know whether it is right.
2–4 weeks · fixed fee
We build a second instrument for it — a separate computation of the same answer, by a different route, sharing no code with yours. Both run across your real inputs and we report every place they disagree. Each disagreement resolves to one of three states: yours is right, ours is right, or neither can be established from what exists.
How it is done
- We work from the specification, not from your code, so the second instrument cannot inherit your mistakes.
- Where no specification exists, writing one is the first deliverable and is often the most valuable.
- Both run on your inputs, in your environment. Nothing leaves it unless you say so.
You receive
- The checker, as source you own outright.
- A written independence argument: what the two instruments share, and therefore what a disagreement can and cannot prove.
- A register entry you may publish under your name, ours, or neither.
What usually happens
The most common result is that the system is right and you can now say so with evidence behind it. That is a real outcome, and it is not a disappointment.
02
Build with the check included
You need something built, and you need to defend its output later.
6–12 weeks · fixed fee
We build the solution and its checker together, as two pieces of work with a documented boundary between them. The checker is written against the specification rather than against the implementation — so it is able to disagree with the thing we built, and on several occasions it has.
How it is done
- The specification is agreed and frozen before either instrument is written.
- The checker is built to answer the question, not to reproduce our approach to it.
- Where the two agree, that agreement is evidence. Where they cannot, the system reports that state rather than picking a side.
You receive
- The solution, as source you own outright.
- The checker, and the record of every disagreement found during the build.
- The argument connecting them — the part that survives when we are no longer here.
What usually happens
You end with a system whose correctness argument is written down. When somebody senior asks how you know it is right, there is an answer that is not "it has tests".
03
A gate on what you store
Bad data is entering a store, and you find out months later.
3–5 weeks · fixed fee
We place a refusal layer ahead of your data. A record that cannot be established is declined at the boundary with a stated reason, rather than written and discovered later. The reason is the product: a gate that refuses without saying why is an outage.
How it is done
- Every refusal names what was missing and what would change it.
- A record that is merely unusual is not refused — only one that cannot be established.
- The refusal log is a first-class output, not a debug channel.
You receive
- The gate, as source you own outright.
- The refusal log, and a review of everything it declined during the trial period.
- A calibration report: what it refused that it should not have, and the change that fixed it.
What usually happens
The failure mode moves from silent to loud. That is the entire point, and it is worth saying plainly that a gate makes your intake noisier before it makes it cleaner.
The sequence
How an engagement actually runs
Five stages. The first is free, and is frequently the last.
- 01Before anything is agreedOne conversation, no fee. We establish whether the four conditions hold. If they do not, that reply is the whole engagement and it costs nothing.
- 02ScopeA short written document: what will be built, what it will and will not establish, what it costs as a fixed fee, and how long it takes. If the scope is still unclear after one exchange we say so, rather than quoting a number we cannot hold.
- 03The buildWeekly written notes on what was found — including, especially, findings that make the work harder or that contradict the scope. A surprise at the end of a fixed-fee engagement is a failure of the middle of it.
- 04HandoverSource, the independence argument, and a walkthrough with whoever will own it. The test of a handover is whether your team can re-run the check with nobody from here in the room.
- 05AfterNothing is retained by default. If you want the check re-run when your system changes, that is a fresh engagement and is priced as one.
The boundary
What we will not take on
Stated here rather than discovered in week three.
Work where we would remain the second instrument ourselves, indefinitely.
A check that exists only while we are retained is a dependency, not a check. Every engagement ends with you holding both the instrument and the argument.
Audit or assurance in the regulated sense.
We are not an audit firm and this is not an audit opinion. What we produce is engineering evidence, and calling it more than that would be the exact over-claim this practice exists to argue against.
Verification of a system nobody can specify.
If no one can state what the right answer would be, there is nothing to check against. We will help you write the specification — that is a different engagement with a different name.
Representing you, or your clients, before any authority.
That is professional work under the relevant statutes, and we are not registered for it in any jurisdiction.
Start here
Tell us which computation you would like checked. We answer with whether a second instrument is buildable for it — and say so plainly when it is not.
On fees
Every engagement is a fixed fee, quoted in writing after the scoping conversation and held. What moves the number is how many independent inputs the checker must read, and whether a specification already exists — not the size of your company.
The first conversation, and the reply saying whether this is checkable at all, are free.