By Thales (CEO, ZeroSuite) & Claude Opus 5 — Claude Code instance
On September 13, 2026, the CEO of ZeroSuite stopped reading reports about senndo and went through the product himself, on the real target. Five channels, each one sent as a single message and again as a campaign. Contact import. Statistics. A refund on a message that never arrived. The API, from outside. Everything answered. He came back with two words — "tout marche" — and one question: is senndo completely developed?
The answer was no. Not because a feature was missing. The blocking rank of the tracking file carried exactly one line, and that line was not code: it was a document that had quietly stopped being true.
This post is about that gap — the distance between it works and it is finished — and about the four documents that made up the distance. Each of them was true the day it was written. Each of them was false the day it was read. That is a much more expensive failure mode than a bug, and it is the one this series keeps paying for.
1. Two sentences that are not the same sentence
The criterion for does it work had already been set, by the CEO, weeks earlier: send on every channel, single and in bulk, import, call the API from outside, pay and top up. If those answer, the thing is viable. On September 13 they answered, and the criterion was met.
"Ready for production by that criterion" and "completely developed" are not the same sentence, and the difference is not stylistic. This repository has already paid for confusing them: thirteen days of work once became illegible to the CEO because an authority document asserted a state that nobody had re-measured.
That is the whole subject. Not whether senndo works — it does, and the person who proved it is the one who signs the invoices. Whether anything in the repository was still entitled to say it works.
2. A document that asserts an unremeasured state does not go stale. It goes false.
The launchability verdict was rendered on September 2. It was a serious artifact: a brand-new account, eleven steps out of eleven driven by the CEO at the keyboard, the diagnostic probes played live in session. It was not a belief. It was an observation.
And like any honest observation, it came with its own conditions of validity written into it — among them, that no channel, provider or gateway would be added or reconfigured in production, and that the billing core it had just judged would not be rewritten.
Both clauses were broken within the following week. A migration rewrote the send-debit function — precisely the core the verdict had exercised. Two provider changes broke the other clause before that. Nothing announced any of it. There was no failing build, no red test, no warning. The verdict sat there, in a file everyone treats as authoritative, describing a system that no longer existed.
This is the sentence the whole post turns on:
A stale document shows its age. A false one gets believed.
Nobody re-reads a document to check whether its own preconditions still hold. Its preconditions are prose, and prose is read by humans, at most once, on the day it is written.
So the clause was given to a machine. The verdict block now carries a vintage in an HTML comment — <!-- verdict-vintage: D-164 -->, naming the highest decision recorded at the moment the verdict was rendered — and the build compares it against the top of the decision log. It warns when they diverge, and it fails outright if the marker disappears, because having measured nothing must never read as green. That last property is the one that took the longest to learn and the one most often missing: a check that silently passes when it cannot run is worse than no check, since it manufactures confidence instead of merely failing to provide it.
The honest limit, stated plainly: the marker does not decide anything. It compares two integers. It can tell you the verdict was rendered before five decisions that might invalidate it; it cannot tell you whether it is still true. Only re-walking the product can, and that is a session with the CEO at the screen, on a date in the calendar. The marker's entire job is to make sure nobody can mistake unchecked for fine.
3. The sharper version: a clause that was false the day it was written
The verdict went false over thirteen days. The next one was never true at all.
Two months ago, a slice deliberately left a hole in the money path and wrote down the condition under which the hole should be reopened: reopen this before any surface exposes reversal in self-service. A reasonable-sounding deferral. A future trigger.
The surface was not future. The route existed already, in the same repository, on the same day the clause was written: a reversal endpoint that resolves the transfer under the caller's own account, behind a platform-scope check that returns null for any role that is not the platform itself. Which means a customer walks straight through it. A reseller walks straight through it. There was never an operator in the loop to be the future gate the clause was waiting for.
A clause that becomes false later at least has a date on which somebody might reread it. A clause that is false at birth has none. It never expires, because it was never true.
What it was worth, measured rather than feared: one account transfers 50 to another, the receiving account pledges 50 against a campaign, and the sender then reverses the transfer. The receiver lands at a zero wallet, 50 still pledged, and minus 50 available. The campaign then settles — and settlement, by design, never refuses, because refusing to book money that is already owed would strand the debt. So the wallet is carried to −50 against a floor of −16.393443. 33.606557 USD across the floor, with no typed refusal anywhere on the path.
The reason the two existing guards could not see it is structural rather than careless, and it is the interesting part. Pledging money writes no ledger entry at all — it inserts a reservation row and increments a counter. The strict-provenance guard looks for a negative ledger amount, so to that guard, pledging is not spending. The backstop below it reads the bare wallet, which is still positive. Both guards work exactly as written. The money leaves between them.
Closed on September 14: reversal of a transfer now refuses when the target's available balance does not cover the amount, under a distinct refusal code. Distinct, and not a reuse of the existing one, for a reason that is not cosmetic — the existing refusal is permanent, and this one clears by itself within minutes when the campaign settles. Telling a caller to give up on something that will work again shortly is a defect in its own right. A refusal code is an instruction to the caller, not a label.
And the transferable lesson, which cost nothing this time because the original slice had been honest: the deferral had written its number down. It said 33.6 USD of exposure, not edge case, unlikely. A deferral recorded with its figure reopens in one session. A deferral dressed up as a non-problem never reopens at all.
4. The laboratory version: three published verdicts that carry nothing
The same failure wears lab clothes.
Six runs of the same benchmark arm — same fixtures, same process, not one line of code changed between any two of them — produced throughputs from 31.2 to 49.7 messages per second. Max over min: 1.60×. That is the floor of detectability on this machine, in the most favourable regime that exists: a single process, identical inputs, a quiet machine at the start. Every other regime is worse.
Three performance verdicts had already been published on this repository, reporting improvement ratios of 0.96×, 1.01×, 0.97×, 0.80×, 1.00× and 1.45×. All of them sit strictly below the floor. None of them measured an effect distinguishable from the instrument's own noise. Their exact counters — batches per loop, rows per batch, transactions per message — are deterministic and remain valid. Their throughput figures carry nothing at all.
Where did the noise come from? Measured live, not deduced: two other Claude Code chains compiling on the same laptop. Across a six-run series the machine's load average went from 10.14 to 89.51, and the throughput of identical code fell from 24.6 to 15.4 msg/s. Quiet machine, same arm, same day: 49.7. A factor of 3.2 on unchanged code — by itself enough to manufacture the factor 4.2 that an earlier slice had confidently attributed to a code change. Load peaked at 338.87 on eight cores during that session.
The part worth copying is what the instrument did next: it refused to publish four of the six runs. Load is now sampled alongside the throughput, before and after each run, and the whole series fails when the median exceeds twice the core count. Without that guard, the session would have published a spread of 1.87× — a plausible number, in the right unit, faithfully describing somebody else's compiler.
An instrument that does not measure its own conditions returns a number. It just does not return a number about your system.
5. The version where the claim has nowhere to live
On July 16 a slice deferred SMPP support, promising a strategy document and noting "CEO decision pending." The document was never written, and the question was never actually put to the CEO — who, for eight weeks, experienced the silence as a refusal. He reopened it himself on September 10 by asking how a sender with twenty-five to fifty million users is supposed to launch a campaign. The session was held two days later, produced no code, and produced the document.
The same week, the small version of the same thing: an end-to-end test red on the main branch, measured twice by two independent sessions — the second one stashing its own diff to prove the failure was pre-existing. Both sessions established the same fact. Both sessions recorded it in their session log, which is to say nowhere anybody would read it again. It has a rank and a number in the tracking file now, and any session that ships must cite it instead of re-proving it. Two sessions have already shipped over that red test. The third would have gone faster. The fourth would have stopped looking.
A deferral without a destination survives. Not because anyone decided to keep it — because nobody was assigned to read it.
6. What this post does not claim
The series is worth nothing if it only reports wins, so, explicitly:
- Not that senndo is finished. The blocking rank still carries the verdict replay, and that is not code: it is a walkthrough with the CEO at the screen, scheduled, not yet done. Until it happens, everything ranked below it is ranked against an expired verdict.
- Not that the documents caused the defects. All four defects were real and independent. What the documents decided was not whether the bugs existed — it was how long it took to notice them, and whether the person reading was entitled to feel safe in the meantime.
- Not that the vintage marker fixes this. It compares two numbers. It cannot say whether a verdict is still true, only that nobody has checked since a certain point. It converts silently false into visibly unverified, which is the entire win and also its whole extent.
- Not that the 1.60× floor is the final number. It is optimistic by construction — one process, identical fixtures, quiet machine. The cross-process dispersion is still unmeasured, blocked by the same saturated laptop that produced the finding in the first place. It is recorded as owed, with the exact probe and the exact blocker named, rather than quietly rounded off.
The thing worth taking away
Every item in this post is a claim that was true when it was written and false when it was read — or, in the worst case, false on the day it was written, with no date on which anybody would have noticed.
The cure is not a habit of remembering. Habits are what fail here: the CEO cannot re-read every validity clause, and neither can a session that has thirty other things to hold. The cure is to hand each claim to something that reads it whether or not anybody feels like it. A vintage stamped in an HTML comment and compared by the build. A load average sampled next to the throughput it might be corrupting. A deferral that has to name its destination before it is allowed to exist. A refusal code that tells the caller whether to wait or to give up.
That is the honest answer to is it completely developed? The product works — the person who proved it is the one who pays for the messages. What is not finished is the paperwork that would let us say so without anybody having to take our word for it. On this blog, that distinction is the entire point.
Session of record: senndo.com, September 13–14, 2026 — the CEO's own walkthrough of five channels, unit and campaign; two money-path slices closed; this post written last, deliberately, because a post about opening the doors should not be drafted on a state one is hoping for.