The setting was wrong, the system was fine

A one-line fix we didn't make

We went looking for a fault in our media server's hardware video encoding, and the evidence looked damning before we started.

A stored setting named the wrong graphics device. It pointed at the discrete card — inside a container we had deliberately built without any access to that card, so the dedicated card stays free for bulk conversion work and gaming. A comment in the service definition agreed, naming that same device as the integrated one. Two sources, same story: misconfigured, and every conversion silently falling back to the slow path.

The repair was a one-liner. We didn't make it, because we hadn't yet watched the thing fail.

So we forced a conversion and read the encoder process's own command line out of the process table. It said h264_vaapi, on the integrated graphics device. Hardware encoding was working perfectly, on exactly the hardware we intended, and had been the whole time.

Agreement is not corroboration

The trap here is worth naming, because it is subtle and it is everywhere.

Two sources agreed. That felt like verification. It wasn't — because they weren't independent. The comment had been written from the setting, or both from the same assumption on the same afternoon. When sources share an ancestor, agreement between them carries no information at all. It only feels like it does.

Two sources agreeing tells you nothing if one was copied from the other.

The device numbering, it turned out, is not stable across restarts. Something that was true when the comment was written had quietly stopped being true, and the comment kept asserting it with a straight face. We fixed the comment and left the setting alone, since the running evidence said the setting was inert.

Assertions and artifacts

We have written before about grounding a model in real tools rather than asking it nicely not to guess. That was the right first move, and it was incomplete. Giving a system real sources doesn't remove invention; it relocates it, to the seam between what a source says and what gets summarized from it. The failure becomes checkable rather than impossible — a real improvement, and not a cure.

The stronger move is to change what the output is.

An assertion is a claim you must trust or independently verify. An artifact carries its own checkability: a proof, a diff, a compiler error, a running process's argument list. A compiler is hard to fool not because it is wise, but because code is self-exhibiting — the claim and the evidence are the same object. Nobody has to believe the encoder process. It isn't testifying. It is simply what it is, and it would have read differently had we been right about the fault.

That reframes the goal. Not "how do we get a trustworthy answer," but "what could this produce that is incapable of being persuasive?"

The fork that wasn't a fork

There is a tempting way to state the underlying problem. Formal systems — provers, type checkers, queries — cannot assert what they can't derive, but they are narrow and brittle and need the world formalized first. Statistical systems are broad and fluent and unsound. Sound and narrow, or broad and unsound. Pick.

Presented that way it looks like a law. It isn't. It's an artifact of two assumptions that were choices: that the system is one component, and that its output is an assertion. Drop either and the fork dissolves. Let the broad thing propose and the narrow thing dispose, and the composite is both — the generator's errors never reach anyone as accepted output. That is what a test suite is. That is what happened above.

Not every fork dissolves, and believing they all do is its own failure. Some are theorems: you cannot decide halting in general; no learner beats every other across all problems. The distinction is worth a habit. Ask what the fork rests on. If it follows from a counting argument, an information bound, or a diagonalization, it is real and you should choose. If it follows from an assumption about architecture or interface — one component, one output format, one place knowledge lives — someone chose that, and it can be unchosen.

Consequence is the ground

The deepest version of this isn't about machines.

Human reasoning confabulates too, and it was never repaired from the inside. What made human knowledge reliable was built around the mind, not within it: citation, peer review, double-entry bookkeeping, rules of evidence, version control. Every one is external machinery for making claims checkable precisely because the thing producing them cannot be trusted to check itself.

What those have in common is that being wrong costs something, and the cost arrives whether or not you went looking. Reality is not grounding because it is real. It is grounding because it pushes back. A prediction that is never tested isn't grounded even when it happens to be true.

So the practical discipline is small and dull and works. Don't ask whether the answer sounds right — it always will. Ask what the system could be made to produce that couldn't lie about itself, and then go read that instead.

We nearly fixed a healthy machine on the strength of two documents that agreed with each other. What stopped us was four seconds of reading what the machine was actually doing.