Confidence as Control Flow

Overview

The degradation ladder needs triggers. Several of them reduce to one number: is the system confident enough?

Module 2 required that number to be a parameter with a business owner. This topic is about what it should actually be measuring — because the obvious choice is the worst one.

The structural claim

“Answer if confident, otherwise hand off” looks like a tuning decision. It is control flow, and it is the most load-bearing branch in the system.

Move the threshold and everything moves: deflection rate, confident-error rate, handoff volume, cost per resolved ticket, and how much human capacity the design consumes. Module 2’s three accuracy numbers are all functions of it. That makes it architecture — a decision expensive to change later, because the whole operating model is calibrated around wherever you set it.

Which produces two requirements, both from Module 2 and both worth restating:

It belongs to whoever owns the consequences. Informational answers: the support owner. Actions that move money: whoever owns the financial exposure.

It must be a parameter, not a constant. Exposed, observable, and changeable without a deploy. A threshold hardcoded in a prompt is a business decision buried where nobody can audit or adjust it.

Do not threshold on self-reported certainty

The central caution, and the one most designs get wrong.

Asking a model how confident it is produces a fluent number that is not a calibrated probability. It is generated text shaped like a percentage. It correlates with correctness somewhat, inconsistently, and in ways that shift between models and prompts. Treating it as a probability — “we only answer above 0.8, so we are 80% right” — is the “it looks right” failure wearing a decimal point.

Better signals, roughly in order of reliability:

graph TD
  A["<b>Structural checks</b><br/>did retrieval return anything<br/>above a score · is a citation<br/>present and real"] --> E["Threshold<br/>decision"]
  B["<b>Agreement</b><br/>two passes, or two paths,<br/>reaching the same answer"] --> E
  C["<b>Retrieval score</b><br/>how well the corpus<br/>actually matched"] --> E
  D["<b>Self-reported certainty</b><br/><i>weakest — use as one<br/>input, never alone</i>"] --> E

  classDef best fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  classDef mid fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef weak fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  classDef out fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  class A best
  class B,C mid
  class D weak
  class E out

Four candidate signals. The olive one is deterministic and cheap; the terracotta one is what everybody reaches for first.

Structural checks are the best signal because they are deterministic and nearly free. Did retrieval return anything above a relevance floor? Is there a citation, and does it point at a document actually retrieved? Does the answer’s claim appear in the source? A system that answers with no supporting retrieval is not confident; it is improvising, and you can detect that without asking it anything.

Agreement — running two passes, or two different paths, and comparing — is genuinely informative and costs double. Worth it on consequential paths, hard to justify on routine ones.

Retrieval score is cheap and partially informative: a weak best-match is good evidence the corpus does not contain the answer, which Module 4 argued is the likelier failure anyway.

Self-reported certainty has a place as one input among several, never as the gate on its own.

Calibration, honestly

Whatever signal you choose, its relationship to correctness has to be measured rather than assumed. The method is straightforward and nobody does it: take your golden set, record the signal and the outcome for each case, and look at how often answers above your threshold are actually right.

That gives you the number you can defend — “above this threshold we are right 94% of the time, measured on 300 cases” — which is a completely different claim from “the model said it was confident”.

Two honest caveats. Calibration drifts: a model update, a prompt change or a corpus change can shift the relationship without changing the number, which makes this a Module 6 drift concern with the threshold as the thing being monitored. And the tooling here is immature — treat this as a discipline to build rather than a solved problem, and expect to revisit it.

The threshold is a dial on a trade-off

Worth making explicit for the conversation you will have.

Raise it: fewer confident errors, more handoffs, lower deflection, more human cost. Lower it: more deflection, more confident errors, and Module 2’s tightest constraint is the one you are spending.

There is no correct setting, only a chosen point on a curve — and the curve is measurable. The most useful artifact you can bring to that conversation is not a recommendation but the curve itself: at this threshold, these three numbers. Then the owner chooses, and the choice is recorded with their name on it.

What the gate actually reads

The numbers it controls: ≥ 90% correct on 300 questions, confident errors ≤ 1%, unnecessary handoffs ≤ 15%.

The composite signal, with the deterministic parts carrying the weight:

1. Retrieval floor — if no retrieved chunk scores above a threshold, do not answer. Deterministic, cheap, and it catches the most common real failure: the documentation does not cover this.
2. Citation check — the answer must cite a document that was actually retrieved in this interaction, and the cited passage must support the claim. Structural.
3. Agreement, on the action path only — for anything that moves money, a second pass must reach the same conclusion before the plan is presented for confirmation. Double cost, confined to where blast radius justifies it.
4. Self-reported certainty — recorded, used as a tie-breaker, never the gate.

Why this ordering matters here specifically. Module 6 established that the ticket corpus is attacker-writable and that injection is mitigated rather than solved. A gate that asks the model how sure it is, in a context an attacker may have influenced, is asking the compromised component to vouch for itself. The structural checks are not susceptible to that in the same way.

Calibration and ownership. The threshold-to-correctness relationship is measured on the golden set and reported with the agreement figure. Maya Ortiz owns the informational threshold; Dev Raghunathan owns the action threshold. What they receive is the curve — at each candidate setting, the deflection rate, the confident-error rate and the handoff rate — and they pick a point.

The drift hook. Threshold calibration is re-measured whenever the model version, the prompt or the corpus changes, and a shift is a Module 6 regression signal in its own right. A threshold that was right in March and unexamined in September is a number nobody owns any more.

Feeds the workbook

Your uncertainty policy needs the confidence behaviour per action: what signal, what threshold, who owns it, and how it is calibrated. If your policy says “if confidence is low”, name the signal — otherwise the implementer picks one, and they will pick the weakest.

Check your understanding

1. Which structural checks could serve as a confidence signal in your design, with no model call at all?
2. Your gate reads only self-reported certainty, and the corpus is attacker-influenced. Describe the specific weakness.
3. Produce the three numbers you would put in front of the threshold’s owner. Which one will they care about most?

---

→ Thresholds decide when to trust the model. The next topic asks how much you need it in the first place. — Hybrid architectures