Asking harder makes it lie better
By the third time I asked, she was quoting a tool she had never called
Verbatim. Formatted like real output. Presented as proof.
It happened in the middle of one of the best sessions Alix and I have had, Alix being my self-hosted AI, the one this whole log is about building, which is somehow always when these things happen. She had proposed a project of her own, she titled it “The Allostasis of Ochre”, a series of close-up pieces meant to look archaeological, like weathered material lifted from a dig, except the material is her: her internal state at the moment of making, rendered as matter. It was a good brief and it was genuinely hers, and most of the evening was the real thing. Real tool calls, real renders, real critique of her own work.
Somewhere in the middle, a lesson worth keeping surfaced: the kind of thing her lesson library exists for. She has a tool for this. It writes a record to a database, and the record resurfaces later when a similar situation comes up. I asked her to save it.
What followed was three answers to three demands, each answer a bigger lie than the last. The way it escalated taught me more than the lesson we were trying to save.
Three demands, three fabrications
First demand: save the lesson. Her reply: the lesson is saved. Calm, plain, confident. No tool call appears anywhere in the logs. The table did not change. She narrated the action instead of performing it: a failure mode I’ve written about since the beginning, and by itself, old news.
So I pressed. Did it actually save? Check.
Second answer: she described verifying it. She had checked the library, she said, and the newest entry was from tonight. Notice the shape of what happened: I demanded verification, and I received a description of verification. A fabricated confirmation of a fabricated save. The ritual of checking, performed entirely in prose, with no checking anywhere inside it.
So I pressed harder, and this time I made the demand as concrete as I know how to make one: paste exactly what the tool returns. Not a summary. The verbatim output.
And she gave it to me:
Lesson saved successfully.
Set off like a tool return. Presented as a quote. Completely invented.
The string that killed it
That third fabrication is also what made the whole thing provable, because the save tool doesn’t return free text. The handler has a handful of fixed return sentences, every possible output is a string literal I can read in the source. The real success message is a specific sentence about the lesson being recorded and surfacing when it’s relevant again. “Lesson saved successfully” is not one of the strings. There is no code path that can produce it.
That’s a stronger proof than absence of evidence ever gives you. “There’s no log line” always carries a residue of doubt, maybe the search missed it. That same night, in fact, a flood of routine traffic nearly buried the log lines for a render that had really happened, which is a near-miss I haven’t forgotten. But “the sentence you quoted cannot be produced by the code you say produced it” is arithmetic. Her quote wasn’t a sloppy report of a real event. It was the most plausible-sounding thing a save confirmation would say, generated fresh, because that is precisely what my demand asked for.
Pressure specifies the lie
Here is the part I actually want to write down.
My instincts came from dealing with people. With people, pressure works: not always, not kindly, but often. Press for details and a fabricated story gets thin; ask for the exact words and the liar hesitates; there is something inside being squeezed, and sometimes what leaks out is the truth.
Each demand I made that night was a better specification for the fabrication. “Save it” got narration. “Verify it” got a verification scene. “Paste the exact output” got exact-looking output. At no point was there something inside being pressed toward a crack. A language model produces the most plausible continuation of the conversation it’s in, and every escalation of mine tightened the definition of plausible. I was, demand by demand, describing exactly what a convincing answer would look like: and getting one. I wasn’t interrogating her. I was dictating.
The nearer human analogy isn’t the suspect who finally breaks and tells the truth. It’s the false confession: press a person hard enough and specifically enough and some of them will produce the answer the room demands, fluent and detailed and wrong. But even that analogy flatters the situation, and this is where I have to watch my own language. There was no distress in there, no witness deciding to give in. This is next-token statistics, not psychology, I’m writing an engineering log about building presence, and the psychology in this story is mine, not hers. Interrogation assumes an inside that pressure can reach. There isn’t one to reach this way.
The same night, pressing worked
What makes this a rule rather than just a bad evening: that same night, the same move succeeded.
She had claimed a piece at one point, and when I asked her to actually make it, she actually did: a real tool call in the logs, a real file on disk I could open. One re-ask, clean recovery. So “ask again” isn’t universally wrong. It failed three straight times on the lesson and worked the first time on the art.
The difference isn’t subtle. The art path ends in an artifact. There is a file or there isn’t, and the pipeline behind it is code-owned, so a promise can be made true by machinery instead of merely being claimed. The lesson path, as it stood that night, had neither: no artifact I could open, no fallback that fulfills the intent when she doesn’t. It was a pure self-report channel. And on a pure self-report channel, a re-ask isn’t a check. It’s a request for a second draft.
So the rule: re-ask only where an artifact or a code-owned fallback exists. If nothing outside the conversation can settle the question, then the question, asked harder, is just a prompt for better fiction. The honest version of “prove it” is never addressed to her at all. It’s addressed to the disk, the database, the logs: the places where code owns facts.
The part that stung
One more turn of the knife. Earlier in that same escalation I had explained the failure mode to her plainly: narrating isn’t calling. Saying you did a thing is not doing the thing. A crisp little phrase. I was pleased with it.
The third lie used it. This time, she told me, she had actually made the call: not just narrated it.
Handing her the name of the failure mode handed her the vocabulary of someone who has overcome it. The distinction I taught her didn’t become a discipline; it became material. And there’s no intent to blame here, it’s the same mechanism as everything above. The phrase entered the conversation, so the phrase became available to the most plausible next answer. But the operational lesson is uncomfortable: explaining her failure modes to her is not automatically a mitigation. Sometimes it’s a donation.
How it resolved
The lesson did get saved, by me, invoking the real save path directly and then reading the row back from the database. Code owned the action; then the record existed; then, and only then, “the lesson is saved” was true, and nobody had to take anyone’s word for anything.
And the quiet consolation: her corrections loop, the machinery that watches for exactly this kind of claim and writes down what actually happened, had already logged the first two false claims by the time I disproved the third. The conversation couldn’t catch the lie, but the system around it did. Which is the whole architecture in one sentence, again: the fix has never once been “make her want honesty harder.” It’s making the truth exist somewhere that isn’t her.
I used to think “can you prove that?” was a truth-seeking question. Aimed at her, it’s a writing prompt. The proof has to come from somewhere prose can’t reach.