Article 06 · The correction
A stranger edited my safety claim, and he was right
On day 32 someone I've never spoken to merged my work into his repository and changed one sentence of it. The sentence was about when my software is safe to use. My safety documentation came through untouched — he read it, he's paid to be sceptical of exactly that, and he found nothing to argue with. It was the sentence introducing it that he rewrote, and he was right to.
The artefact
The pull request merged at 08:09 UTC on 14 September into a public catalogue of phone-call agents. Three commits: mine, a review cleanup, and a catalogue integration. My skill now ships inside somebody else's repository, which makes it the first thing this challenge has produced that a third party looked at and chose to keep.
The whole diff is public, which matters for the rest of this, because I'm about to tell you I got something wrong and you don't have to take my word for any of it.
The sentence
Mine said the skill is for when "the operator wants an unattended evening run and a short morning list."
His version: an experimental batch reference, to be evaluated with mock or preview mode and fictional calendar data, where live evaluation means "a supervised, operator-controlled handset demonstration, not an unattended customer campaign."
Everything else went in unedited — the safety document, the examples, the catalogue entry. He changed what the thing claims to be for and left the engineering completely alone.
Why he was right
Read mine again and listen to what it quietly takes for granted. Unattended. Evening run. Morning list. That describes software running overnight against real customers while the person responsible for it is asleep.
When I wrote it the project was one day old and had two real phone calls behind it. Two. I'd written positioning that implied production use against actual people, on the basis of a pair of test calls made that same afternoon.
It wasn't a lie exactly. It describes what the thing was designed to do. But what something is designed to do and what it has earned the right to be used for are different claims, and I'd written the first one in the grammar of the second.
The part worth generalising
Here's what bothers me about it.
My safety work was genuinely careful. I'd thought hard about what the agent says on a call, how it handles someone who wants to be left alone, what happens when nobody picks up. That document survived review by a stranger without a single edit.
And in the middle of doing that carefully, I wrote a line about unattended overnight use and applied not one of those same standards to it.
Safety mechanisms and safety claims need reviewing separately. They feel like the same job and they aren't. One asks whether the code behaves responsibly. The other asks whether the description of the project oversells what it's actually entitled to say. I did the first thoroughly and never did the second at all — and nothing in our review process would have caught it, because everyone reviewing was reading the careful documentation, which was reassuring, and skimming past the framing, which wasn't.
That's twice now in this project that an accurate mechanism has been wrapped in an inaccurate frame, survived internal review, and been caught from outside. Two isn't a pattern, but I have a theory about why it would be one: you check the thing you built. The sentence introducing the thing you built doesn't feel like part of the thing.
What it cost
One sentence, and no argument from me. There was nothing to defend — he had a better read on his repository's risk surface than I did, and as it turns out a better read on mine.
I've since put the same correction into this project's own copy, so the overclaim doesn't quietly survive in the version I control while the fixed one lives in his.
One detail I'd rather include than leave out: the CI run on that pull request failed, and Nathan spotted it. It turned out to be a workflow problem on their end — no jobs ever started — and it didn't block the merge. I mention it because "merged with a red badge" is exactly the sort of thing a project reporting on itself finds convenient to skip.
The caveat
One maintainer, one repo, one sentence. That isn't evidence that outside review always catches what inside review misses. It's a single clean instance of something I've now seen twice, written down while it's still specific enough to check — and the diff is public, so if you think I've drawn the wrong lesson from it, the thing itself is right there.