SolutionWright Universal

June 30, 2026

The Falsifier-Published Commitment: Putting Our Receipts In The Contract

How SolutionWright writes the falsifier-publication promise directly into the contract, including the trigger conditions and what happens when a failure event is recorded.

Most vendor contracts are written to protect the vendor when things go wrong. Ours is written to make it cheap for the client to find out.

The mechanism is a single clause we call the falsifier-publication commitment. It is not a slogan and it is not in the marketing copy — it is in the body of the agreement, with defined terms and a defined consequence. The point of putting it there is that a promise that lives only on a blog page is a promise the vendor can quietly forget. A promise inside the contract is one the client can enforce.

Here is what the clause actually does.

What we promise. For every non-trivial claim we make about the engagement — about the system we are building, the results it produces, the timelines we hit, the costs we hit — we publish, in the same place as the claim, a falsifier. (Class C) A falsifier is a specific, observable condition that, if it occurred, would force us to retract the claim. The contract requires that the falsifier be written in language a non-engineer on the client's side can evaluate without asking us for help. If only we can tell whether the claim is still true, the falsifier does not count.

What triggers a failure event. The clause defines a failure event in three ways. First: a claim is made without a falsifier attached. Second: a falsifier is attached but the condition described in it has occurred and we have not recorded a retraction within five business days of the condition becoming visible in the logs both parties can see. Third: the falsifier as written is unfalsifiable in practice — the condition cannot actually be observed, either because the instrumentation does not exist or because the language was vague enough to wriggle out of. Any one of those is a recorded failure. (Class C)

What happens when a failure event is recorded. The consequence is deliberately small and deliberately public. The failure is logged to a section of the receipts page the client controls — they can write the entry themselves; we cannot edit it. We owe a written correction within ten business days. If three failure events are recorded in any rolling ninety-day window, the client may terminate the engagement for cause at no penalty, and any work delivered remains theirs under the exit-ready clause elsewhere in the agreement.

Three things this clause does not do, because they would turn it back into theatre.

It does not let us define our own failures. The falsifier is written into the deliverable artifact at the time the claim is made, not retrofitted later. We cannot mark our own homework after the fact.

It does not let us define our own evidence. The instrumentation the falsifier depends on has to be in place, has to be running, and has to be visible to the client. If the only log of whether the claim is still true sits on our laptop, the falsifier is unfalsifiable in practice and the clause has already fired.

It does not give us an out for "best effort." A claim either has a falsifier or it does not. If we are not sure enough about something to write a test that could disprove it, we do not put the claim in writing in the first place. We say what we are uncertain about, in plain words, on the same page.

Dr. Alianna J. Maren has written, in our one-line frame, about the field's habit of pouring enormous capital into one architectural bet while underspending on the human verification step that would catch the resulting errors. (Class E) Read her tummy-churning piece directly — it is the broader version of the same anxiety we have tried to design out of our own contract. The falsifier-publication commitment is our small operational answer: it forces the human verification step into the legal structure of the engagement, not the optional appendix.

If you are evaluating a partner right now and the contract draft on the table reads as if every promise is upside and no promise has a teeth-bearing failure condition, that is the signal. Ask for a clause that does what this one does. If the answer is that it is too hard to write, the underlying claims were probably not engineering claims to begin with.

EvidenceECTagscontractfalsifierreceiptstransparencypartnershiptrust

Next steps

Bring this into a working session.

The workshop is where these notes turn into receipts on real work. The science page is where the underlying hypothesis is laid out in full, with the falsifier attached.