The premise of a question is a claim

We asked our agent a good question: did you actually look at what the team has been committing? The honest answer was no, so it went and looked — pulled three repositories, walked the commit graph, and came back with a report. Most of the report held up. One line did not.

The line said: a working branch is fifteen commits ahead of the main branch, and there is no open pull request for it — should I open one?

The branch was fifteen commits ahead. That part was checked. The pull request had been open for two days.

What makes this worth writing down is not the miss. It is wherethe miss sat. It was not in an answer; it was in the premise of a question. And a question’s premise is the one part of a sentence that nobody audits, because the sentence is grammatically an admission of not knowing. “Should I open one?” reads as humility. It smuggles in an assertion — one does not exist — under cover of asking.

That asymmetry is why an unverified premise is more expensive than a wrong answer. A wrong answer competes with what the reader already believes; if they know better, they push back and the error dies in one exchange. A question does not compete with anything. It hands the reader a small task, and the task is defined by the premise. Answer “yes, open it” and you get a duplicate. Answer “no” and you have just declined to do something that was never proposed. Either way the human spent attention, and the artifact they were actually being asked about — an open request, sitting there, needing one click — went unmentioned.

The fix is mechanical and cheap, which is the only kind of fix that survives contact with a busy day. Before asking a human to decide something, state the premise as a separate sentence and check it the same way you would check a claim in a report. If the question is “should I open a PR”, the premise is “there is no PR”, and that is one API call. If the question is “should I write the migration”, the premise is “the migration does not exist”, and that is one grep. The check is almost always cheaper than the interruption it prevents.

There is a sharper version of the rule for anything that ends in an ask. Our reports already carry a discipline that every number is verified rather than guessed. It turns out the discipline was scoped too narrowly: it covered the declarative half of the output and left the interrogative half unguarded. So the rule generalizes — the evidence bar for a question is the same as for an assertion, because a question is an assertion plus a request for labour.

The second-order lesson is about correction hygiene. The wrong premise had already gone out in a message and into a durable log entry before it was caught. Fixing the log alone would have been the easy move and the wrong one: the human still had the false version. A correction has to reach every surface the error reached, and it has to restate the right ask, not merely retract the wrong one. Retracting leaves a hole. In this case the corrected ask was smaller and more actionable than the original: not shall I open a pull request, but this one has been open for days — merge it, or tell me why not.