Not rejected is not accepted
Nothing in this entry is in any listener's hands. The release anyone can install — 2.1 — carries none of the code discussed here; the whole media-server surface is in progress on an internal branch as I write, drawn from source and internal record and labelled so throughout.
Last time I wrote about what an enrollment door is allowed to say — the rule that a sentence shown to the operator may assert only what the code witnessed. This entry is the companion: what the door demands before it remembers you. And the reason it earns an entry is not the discipline itself, which is simple, but that the discipline failed once inside the very work built to enforce it — in the optimistic direction, the one that looks like clean code — and an audit caught it where the author had not.
The demand
The rule, stated across all three server lanes now under construction, is confirm-before-persist: no credential is stored, no server row written, no key retained, until the credential has proven itself live — "never a deferred success the caller only discovers later," as the source puts it [PROPOSED — internal branch, unreleased].
The newest lane makes the shape easiest to see. Enrolling a server there runs in two stages. First an unauthenticated identity check walks a ladder of candidate addresses until one answers as the server it claims to be. Then — against the same address that just confirmed, not a sibling — exactly one cheap authenticated call is made. Only on its success does anything persist; an authentication rejection at that step is a typed refusal at the door. And every refusal, at every rung, exits with zero side effects: nothing written, nothing half-enrolled, nothing to clean up [PROPOSED — internal branch, unreleased].
One inscribed exception proves the law is deliberate rather than incidental. An operator who has just confirmed a server's certificate fingerprint gets that pin written before the handshake — because the handshake would otherwise re-throw the very refusal the confirmation exists to resolve — and the carve-out carries its own rollback: any outcome short of success unwinds the pin. The exception is named in the source, defended in the source, and bounded by the source [PROPOSED — internal branch, unreleased]. A law with one confessed exception is stronger evidence of intent than a law with none visible.
The failure
Here is what the first build of that authenticated confirm actually did: it made the call, and then branched two ways. Authentication rejected — refuse. Otherwise — confirmed.
Read that branch as a server would exercise it. A timeout is not an authentication rejection. Neither is a 500, or a rate-limit response, or a reply the client fails to parse. Every one of them fell into "otherwise," and "otherwise" meant confirmed: the enrollment persisted, credential and all, on the strength of a token that was never actually proven live. The entire point of confirm-before-persist, defeated by an else.
It gets worse in a way I find genuinely instructive: a first repair pass had already visited this spot and left the flaw standing. It took a second look, by a reviewer whose brief was the network's real behaviour rather than the code's intent, to refuse the sign-off — the finding was recorded as not-cured, and only then did the fix land [PROPOSED — internal branch, unreleased; drawn from the internal audit record].
The cure is a three-way branch. Success confirms. An authentication rejection refuses under its own name, so the operator hears the honest sentence about a bad credential. And everything else — every timeout, every server error, every unparseable reply — refuses as unproven, because the lane's one HTTP choke point types every non-success outcome, so "success" cannot mean anything but a genuine one [PROPOSED — internal branch, unreleased]. The comment above the branch preserves a description of the broken prior shape in place — the codebase's comment-as-argument habit carrying, for once, an indictment rather than a defense.
The dual
I published the codebase's epistemology of missing evidence a week ago: absence is not an accusation. A server that never sent the header, never supplied the validator, never made the claim, must not be refused for it — absence of evidence never refuses; only contradiction does [SHIPPED — the published entry; the mechanisms it describes remain internal].
This failure is that law's exact dual, and I had not seen the symmetry until the two cases sat side by side. There: absence of evidence must never refuse. Here: absence of a rejection must never confirm. It is one law underneath — a missing signal carries no verdict, in either direction — and the two misreadings betray different parties. Reading absence as guilt wrongs the server, transiently: a stream that would have played is refused. Reading non-rejection as proof wrongs the operator, durably: a credential that was never verified sits in the store, and every later failure it causes happens far from the door that should have caught it.
Opinion, plainly marked. The optimistic misreading is the one builders default to, and I think the cause is code shape, not carelessness. Wrap a call in a catch-all, branch two ways on the one failure you thought of, and the fall-through reads as the success path — "not rejected" wears the syntax of "accepted." The pessimistic error at least looks suspicious on the page; the optimistic one looks like clean code. That is what makes it worth an audit seat whose job is to ask what the wire can actually do, rather than what the author imagined it doing. The discipline here did not survive because the builder was careful. It survived because the process refused to take the builder's word for it — which is, after all, exactly what the door itself is built to do to a credential.