Reading width
Wide uses the full column for everything, text, diagrams, code, and exercises. Narrow keeps the standard reading width.
Text size
Scales the body text. Headings and code blocks keep their size.
In this section
Calibration: Knowing When AI Output Is Likely to Be Wrong
Two calibrations, both yours
The previous sub established that you cannot ask a model how confident it is and get an answer worth having. That leaves two calibrations, and both belong to you.
Calibration about the task. Before you delegate, how likely is this particular request to produce a wrong answer? This is predictable from properties you can see, and the next section lists them.
Calibration about yourself. How often does your own judgment of a generated artifact turn out to be right? Most analysts have never measured this and most assume it is higher than it is.
The two combine into the only reliable practice available: knowing which requests are risky, and knowing how much your own review is worth on the risky ones.
Five conditions that predict trouble
Every one of these is visible before you read the answer.
1. Your request contained a relative time. "Around the alert", "recently", "in the last few days". These require a conversion from relative to absolute, the conversion is invisible in the output, and an off-by-one-day window still returns rows. This single condition accounts for a large share of silent windows.
2. The question was about your estate rather than about the world. "Is this suspicious", "is this normal", "should I be worried". Established in the previous sub: unanswerable, and answered anyway in generically true terms.
3. The answer is a negative or a zero. No evidence, no other hosts, no prior occurrence, zero rows. Absence cannot be established from a sample and an empty result is not a finding.
4. The artifact combines sources. Any join, correlation, or "cross-reference these two". The combining step is where key uniqueness matters and where the error is invisible in a count.
5. The output contains a specific figure you did not calculate. A count, a duration, a percentage, a ranking. Generated rather than measured.
Worth Knowing
Why these are worth more than a confidence score
They are properties of the request and the artifact, not claims by the system about itself. You can check them without trusting anything, they are visible in under ten seconds, and they map one-to-one onto the six failure modes. A confidence score is a sentence the model produced; these are facts about what you asked for.
Knowing your own hit rate
The second calibration is uncomfortable and it is worth acquiring, because every decision about how much to verify depends on it.
The method is simple. Over a week, when you review a generated artifact, write down your judgment before you check it: sound, or unsound and why. Then check properly. Count.
Most people find three things, and they are consistent enough to predict.
Your hit rate is lower than you expect on plausible artifacts. Everyone catches the obviously broken ones. The interesting number is your rate on the ones that look fine, and it is usually well under what feels true, because the cases you remember are the ones you caught.
Your false-positive rate is not zero. You will flag correct artifacts as suspicious. This matters more than it sounds: an analyst who distrusts everything has stopped getting value from the tool, and the review has become theatre in the other direction.
Your rate varies by category, and predictably. You are good at spotting wrong queries in tables you know well and poor in tables you use rarely, which is the same estate-knowledge boundary from the previous sub applied to yourself.
Worth Knowing
What to do with the number
Not to feel bad about it. To allocate. If you catch most errors in identity queries and few in endpoint ones, the endpoint queries are where you spend the extra thirty seconds, and knowing that is worth more than a general resolution to be careful.
The fluency trap
One effect deserves separating out, because it operates on your calibration rather than on the artifact.
A better-written answer is judged more likely to be correct, and the two are unrelated. A response with clear structure, appropriate hedging in the right places, and a confident closing sentence reads as more reliable than a terse one. None of those properties is evidence about the claim.
This matters specifically because fluency is increasing. Each generation of these systems produces better-organized, better-hedged, more professional-sounding output, and none of that improvement is in the direction of being right about your estate. The signal that feels like reliability is getting stronger while its correlation with reliability stays where it was.
The practical form of this is worth recognizing in yourself. If your reason for accepting an answer is that it was well-argued, you have been persuaded rather than convinced, and the distinction is that a persuasive answer changes your belief without providing evidence.
The five conditions against a real request
Take a request an analyst made on the Northgate brute force and score it before reading the answer.
"The alert on r.scott fired around 23:00 on the 2nd. Show me what happened with that account recently, and tell me if it looks like the attack worked."
Condition 1 fires twice. "Around 23:00" and "recently" are both relative, and the second is worse than the first because it has no anchor at all. The window that comes back will be a guess, and any window that misses 22:14 to 22:55 excludes the entire attack while still returning ordinary sign-ins.
Condition 2 fires. "Tell me if it looks like the attack worked" is a judgment about this estate. The answer will be about what successful brute forces generally look like.
Condition 3 is live. If the response says the attack does not appear to have succeeded, that is a negative claim, and it will mean the query it wrote did not surface a success rather than that none occurred.
Condition 4 is absent. No correlation across tables is required.
Condition 5 is likely. Any summary of "what happened with that account" will contain counts, and those counts will be generated.
Four of five, on a request that reads as completely reasonable. That is the point of the list: this is not a badly phrased request, it is how people actually ask, and the conditions fire on ordinary language rather than on carelessness.
The rewritten version costs nothing: "Show me every authentication for r.scott@ne.com between 2026-03-02T18:00Z and 2026-03-03T06:00Z, including result codes, sorted by time." Absolute window, no judgment requested, no figures to generate. Green rather than red, and it produces the evidence the original question wanted.
Worth Knowing
The habit this builds
Scoring the request rather than the answer moves the check earlier, where it is cheaper. Five conditions read off your own sentence take about five seconds, and they tell you whether the answer needs thirty seconds of verification or a different question entirely. Analysts who do this well are not more suspicious than everyone else; they are suspicious at a different point.
Recalibrating when the tool changes
One practical note, because it catches people out.
Every calibration in this sub is about a specific tool at a specific time. When the model behind it changes, and it will without announcement, your hit rate and your sense of which requests are risky are both based on a system that no longer exists.
The failure modes do not change, because they follow from the mechanism. The distribution across them does. A new model might be markedly better at time windows and no better at negative claims, which shifts where your attention should go without shifting anything you would notice from using it casually.
The cheap response is to re-run the twenty-request evaluation from the previous sub after any significant change, and to treat a sudden improvement in fluency as a reason to check more rather than less. An answer that got noticeably better-written did not necessarily get more correct, and the fluency trap is strongest immediately after an upgrade.
The pre-flight, as something you can use
The five conditions are only worth anything if you can run them at speed. Here they are as a card, in the order that finds the most problems soonest.
BEFORE YOU RUN A GENERATED QUERY ~30 seconds
1. EMPTY RESULT? Delete the narrowest filter and re-run.
Still empty? Wrong table.
2. FILTERS vs REQUEST Read your own words next to the clauses.
Every constraint you stated -> a clause?
Every variable name -> what the filter does?
3. TIME BOUNDARY Widen it a day each way.
Answer changes SHAPE? The window was the analysis.
4. JOIN PRESENT? Count both sides. Joined rows > larger input
means the key is not unique.
5. FIGURE TO REPORT? Which query produced this number?
"The summary did" is not an answer.
Copy that somewhere you will see it. It is the whole of the technique, and everything after this module is practice at running it faster.
The three phrases that cost the most
Two of the five conditions are triggered by how the request was worded rather than by anything the model did. Three phrases account for most of it, and all three are how people naturally speak.
YOU SAY YOU GET SAY INSTEAD
─────────────────────────────────────────────────────────────────────
"around the alert" a window that may miss it "between 18:00Z
and 06:00Z"
"recently" / "lately" an anchor from today, not an absolute date
from the incident range
"is this suspicious?" a true statement about "show me every X
accounts in general for this account"
Rewriting the request is cheaper than checking the answer, and it removes the failure rather than catching it. That is the highest-leverage habit in this module.
A working heuristic
Everything above compresses into something usable at speed.
Green. Translation, no relative time, no join, no figure to repeat. Read it against your intent and use it. This is most requests and it should feel fast, because treating every request as dangerous is how the habit gets abandoned.
Amber. Any of the five conditions present. Run the specific check that condition implies. One check, thirty seconds, not a general review: relative time means widen the window, a zero means prove the query can return rows, a join means count both sides, a figure means find the query that produced it.
Red. The request was about your estate, or the answer is going into a report, or the decision that follows is expensive to reverse. Do not verify the artifact. Go and get the evidence yourself, and use the generated answer as a hypothesis to test rather than a result to check.
The Reasonable Mistake
The category people get wrong
Red is not "the important alerts". It is defined by whether the answer depends on your estate or is expensive to reverse, and plenty of routine alerts qualify while plenty of dramatic ones do not. An analyst who reserves care for incidents that feel serious will apply it to the wrong ones, because the alert that turns out to matter rarely announces itself in advance.
Everything you have read here can be practiced against the same estate: graded SOC scenarios, forensic cases, Splunk and AWS query drills, a free-run KQL and SPL console, and the response playbooks.
Open the Practice Hub →