ProServIQ · Professional services, with the IQ to prove the answer
Bring us an idea, or a problem where a wrong answer is expensive. We build the product or system that solves it — and a second, independent instrument beside it that checks every answer it gives. When the two disagree, you hear about it before your customers do.
The name, decoded
How it works
01
An idea for a product, a process that needs building, or a system you already run and are not sure of. You do not need to know how it should be built — only which answer would be expensive to get wrong.
You get
One conversation, free, and a straight answer on whether we can help.
02
The product or system that solves it, from a specification agreed in writing before any code. A fixed fee, weekly written notes on what we find, and nothing kept back by us at the end.
You get
Software you own outright, as source.
03
A second instrument, written separately and sharing no code with the first, answers the same question by a different route. Every result comes back established, divergent or unestablished — never a confident guess.
You get
The checker, and the written argument for why the answer is right.
Already running the system? Start at step three: we build only the check, run it against your real inputs, and report every place the two disagree. Compare the ways to work with us →
What we have built
Built the way we build for clients: the software that answers the question, and a second instrument that checks it — so any figure it gives can be defended later.
Ways to work with us
01
We build a second instrument for a computation you already run, and report where the two disagree.
You receive
the checker, its method, and a register entry you may publish or keep
2–4 weeks · fixed fee
02
A solution whose correctness argument is written alongside it, by a checker that shares no code with the thing it checks.
You receive
the solution, its checker, and the argument connecting them
6–12 weeks · fixed fee
03
A refusal layer ahead of your data, because a dropped record and a stored-but-wrong record are indistinguishable downstream.
You receive
the gate, its refusal log, and what it declined and why
3–5 weeks · fixed fee
A crash announces itself. A wrong answer does not. It arrives on time, in the right format, inside the expected range, and is acted on.
The only way to catch one is to compute the answer a second time, in a way that could not have made the same mistake.
What we will state in writing
A computed answer earns belief only from an instrument that could not have made the same mistake.
The second instrument, across five systems
What a second instrument catches
Published check 0032 · a parsing case, not a product
Two functions in one system both claimed to read an amount off a document. On an ordinary input they differed by a factor of one hundred. Both had shipped. Both had passing tests.
A separate instrument recomputes the answer and records disagreement. That is step three above, in every domain we work in.
Why nothing caught it
Divergent · 100× on one input · sign lost on another · one grammar now, and the unit is in the type system
The machinery
Eight techniques, all running in production, none of them specific to a domain. Each one exists because something got past the first instrument — and each is written down here with what it cost to learn.
01
The primary engine compiles rules from data. The checker implements the same specification directly — plain tables, whole-number arithmetic, no rules engine, no solver, no shared constant. It is written to be able to disagree.
How we know
The checker imports nothing from the engine it checks. Zero edges, enforced by a test that reads the import graph.
A mirror that imports the original verifies nothing. Independence has to be structural or it is decorative.
02
The risk model carries a formal certificate: an SMT solver proves that a bound holds across the entire input space, and returns a named counterexample when it does not. Loosening a parameter breaks the proof rather than quietly widening the model.
How we know
Runs in CI as an UNSAT certificate. A failure names the exact inputs that break the bound.
Tests sample a space. A proof settles it. For a claim you intend to put in writing, sampling is not enough.
03
Values that differ only by scale are branded distinct types at compile time and identical at runtime. Passing one where the other belongs is a build error, not a plausible number on somebody’s screen.
How we know
The brand is mutation-proven: weakening it makes the guard assertions themselves fail to compile.
The hundredfold error earlier on this page is exactly this class. It is the cheapest whole category of bug to delete permanently.
04
The rules a computation ran under are compiled from files and digested to a hash. Every stored result records that hash, the engine version and the inputs — so a result from two years ago can be replayed under the rules it was actually computed under, not today’s.
How we know
A provenance-only edit moves the hash. That is correct, and it is why archived rulesets are kept.
A system that cannot reproduce its own past answers cannot defend them. Most cannot.
05
Every rule carries a validity window. A rule repealed in 1993 is applied to 1992 and refused for 1994, rather than being deleted — because a historical computation still needs the rule that governed it.
How we know
Auditing this found 93 repealed rules reporting themselves as still in force, with their repeal dates sitting unparsed on the page they came from.
Most systems model the current rules and silently lose the ability to explain any earlier answer.
06
Records are addressed by a path that contains the tenant. There is no query-time filter to forget, because there is no query-time filter.
How we know
A key that omitted the tenant was found by seeding one client under two accounts — a case no fixture built, because every fixture used its own identifier.
A filter fails open: one missing clause leaks a customer’s whole book. A key fails closed.
07
Derived artefacts are written so that two machines produce identical bytes, and each records the digest of the source it was derived from.
How we know
Two platforms had been emitting different bytes for the same input through newline translation alone — which would have made “rebuild and compare” useless as an acceptance test.
If you cannot rebuild it and get the same thing, you cannot prove what produced it.
08
Every result reports established, divergent, or unestablished — and the third travels all the way to the screen with the reason and the remedy attached.
How we know
Seven defects in one audit were the same shape: a three-state fact flattened to two at a response boundary. Fixing them at the producer exposed five more nobody had reported.
A system with two outcomes has to file “could not tell” under one of them, and it always files it under the reassuring one.
None of this is a research prototype. It is the machinery behind an instrument we run every day — and it is the same machinery we build into someone else’s system.
See it in the instruments →Interactive · check 0031
Every state below was produced by the real solver before this page was built. Nothing here is illustrative.
Controls
Staff
Constraints
Hover a constraint to see the cells it governs. C8 can be switched off.
14 days · 3 shifts · 7 staff
INFEASIBLE · 0.089s
| Tue01 | Wed02 | Thu03 | Fri04 | Sat05 | Sun06 | Mon07 | Tue08 | Wed09 | Thu10 | Fri11 | Sat12 | Sun13 | Mon14 | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Early | · | · | · | · | · | · | · | · | · | · | · | · | · | · |
| Late | · | · | · | · | · | · | · | · | · | · | · | · | · | · |
| Night | · | · | · | · | · | · | · | · | · | · | · | · | · | · |
No solution exists
Coverage requires four shifts on each weekend day. One shift per person per day makes that four DISTINCT people. Everybody is owed one full weekend off, so nobody can staff both. Two weekends therefore require eight distinct people, and the roster has seven.
Pre-computed · CP-SAT · states generated from the model, not written by hand · read the method
Every check we publish: the question, the two instruments, and what came back — including when the answer was that we could not tell.
2026
Start here
Tell us what the software should do — or which answer you are unsure of — and who acts on it. A person replies within two working days with whether we can build it, and how we would prove it right.
Or write to contact@proserviq.com