Logging the Absence of Clarification Before an Approval

A gap event is not a comment field. Comments are unstructured, they get skipped, and they are impossible to aggregate. A gap event is a small, fixed-schema record with a short list of what was left unclear. Keep it to under a minute of reviewer effort or it will not happen.

Two design choices matter more than the rest. First, missing_questions must be a list, not free text, so you can cluster and count them later; a one-line comment about "unclear scope" is worth nothing at scale. Second, confidence should be captured on every decision, including clean ones, so you have a baseline. Without a baseline, a rising gap count is ambiguous: it could mean more confusion or better reporting.

The sanity of the record depends on the input state being pinned. A decision audit trail is only replayable if it stores "the exact text or JSON the model read, pinned to a specific content revision rather than a pointer to the current version," along with the policy version, the threshold in force, and any human override, per Sanity's glossary entry on decision audit trails. Your gap event inherits the same discipline: it must reference the exact artifact version the approver saw, not the request as it looks a week later.

This is the same principle behind a well-built decision log. A decision log is "a structured record of your decisions: what you chose, why you chose it, who was involved, what alternatives were considered, and what outcomes were expected," and it exists because the reasoning behind a choice fades unless it is written down, per monday.com's decision log guide. The clarification gap log is the decision log's missing half: it records the reasoning that did not happen.

Not every missing clarification should block an approval. If it did, nothing would ship. You need a rule that decides, at the moment of approval, whether the gap is tolerable, must be logged and proceed, or must halt the request.

The rule I recommend is a two-axis classification: reversibility and blast radius. The StackAI approval workflow design guide states the risk-based rule of thumb plainly: require approval when the agent's next action is "irreversible, costly, regulated, or high blast radius." Extend that to gaps: a gap that sits on an irreversible action is a stop, a gap on a cheap corrective action is a log-and-go.

A worked example makes the arithmetic concrete. Suppose your approval queue sees 400 requests a week. Historically, 12% arrive with a missing field that the approver has to chase, so 48 requests a week. Each chase costs an average of 18 minutes across reviewer and requester, which is about 14.4 hours a week. If your gap log shows that 70% of those chases are the same three fields, you have a data-capture problem upstream, and fixing the request form removes roughly 10 hours a week of rework while making the gap count fall on its own. The log pays for itself the first time you can say "these three fields cause most of our clarification debt" with numbers.

The complementary rule covers the opposite failure. Reviewers who never record a gap are not necessarily seeing clear requests; they may be rubber-stamping. The Promptessor guide to HITL approval workflows flags the risk directly: "Approval fatigue can make human oversight meaningless," and it recommends recording what the reviewer saw alongside the decision. A reviewer with a zero gap rate and a median decision time of four seconds is a finding, not a role model.

One gap event is an anecdote. A thousand gap events with timestamps become a control chart. The insight most teams miss is that you should track two distinct numbers, and they move in opposite directions.

Gap count (gaps per 100 approvals) measures how often people approve without understanding. Gap age (median time from a gap being recorded to its resolution) measures whether anyone ever goes back. A team with a falling gap count and a rising gap age is not improving; it has stopped reporting. A team with a rising gap count and a falling gap age is getting more honest and more responsive at the same time, which is the healthy trajectory.

Compute the signal on three slices: by request type, by approver, and by week. The per-request-type slice tells you where to fix the form. The per-approver slice tells you who needs context or training. The weekly slice tells you whether a process change helped or a new bottleneck appeared.

-- Weekly clarification gap rate and age, per request type
SELECT
  request_type,
  date_trunc('week', decided_at)              AS week,
  COUNT(*)                                    AS approvals,
  COUNT(gap_id) FILTER (WHERE gap_id IS NOT NULL) AS approvals_with_gap,
  ROUND(100.0 * COUNT(gap_id) FILTER (WHERE gap_id IS NOT NULL)
        / COUNT(*), 2)                        AS gap_rate_pct,
  ROUND(percentile_cont(0.5) WITHIN GROUP (
        ORDER BY resolved_at - decided_at) / 3600.0, 1) AS median_gap_age_hours,
  ROUND(AVG(confidence), 2)                   AS avg_confidence
FROM approval_events
WHERE decided_at > now() - interval '12 weeks'
GROUP BY 1, 2
ORDER BY 1, 2;

Set alert thresholds empirically, not from a benchmark you read somewhere. Run the query for four weeks with no thresholds at all, then set the alert at roughly 20 to 30% above your own median gap rate. The Galileo guide to production HITL oversight makes the same argument for escalation: "derive escalation rate targets from your own task distributions, not generic industry figures." Your gap rate is a property of your request intake, your evidence packs, and your reviewer training, so it deserves your own baseline.

For agents specifically, the gap signal doubles as an autonomy gate. The Elementum writeup on HITL agentic AI lays out a three-tier model (human-in-the-loop, human-on-the-loop, human-out-of-the-loop) and argues that how much oversight a workflow needs depends on its risk profile. Gap rate is an empirical proxy for that risk. A request type that consistently shows low gap rate and high confidence over several weeks is a candidate for exception-only review; one that shows a widening gap spread stays under full review.

The compliance theater trap. When gap logging becomes mandatory, reviewers will enter the minimum that clears the form. You get a wall of "assumption: standard" entries and a dashboard that says everything is fine. The counter is structural, not motivational: make the gap list a set of choices pulled from the request's own missing fields, and require evidence_seen to be true before the decision commits. If the reviewer did not open the evidence, the gap is real whether or not they wrote it down.

The slowdown objection. Someone will argue that gap capture adds friction to a flow you built to be fast. The StackAI guide names this misconception explicitly and points at the real cause of slow approvals: "The delay usually comes from poor routing and incomplete context, not from the mere existence of a human step." Note the word incomplete context. A gap log is a measurement of how often context is incomplete. The fix is better request intake, and the log tells you which intake fields to fix first.

There is a third, subtler failure: instrumenting only the approve path. If gaps are only recorded on approvals, your data conflates "we proceeded without understanding" with "we refused to proceed." The Permit.io guide stresses that every action should have a reviewer or approver so the audit trail answers who authorized what and why. Your gap event should answer the same for refusals: what was missing that made you say no?

Start narrow. Pick two request types, one high-risk and one routine, and run the gap log for two weeks.

Week 1: instrument only. Add the gap fields to the approval pause, capture confidence and evidence_seen, and do not act on the data. Tell reviewers the data is for calibration, not performance review. The second part is not optional; if reviewers believe gaps are being scored against them, you get the compliance theater trap.

Week 2: review together. Pull the per-request-type query and read every gap where confidence was 1 or 2. You will usually find two kinds of finding: a missing field on the request form (fix the form) and a policy that nobody actually understands (fix the policy).

Week 3 onward: set the signal. Publish a weekly gap rate and median gap age per request type and per approver. Do not rank approvers by gap count; publish the distribution and discuss outliers in one-on-ones. Ranking punishes honesty, and honesty is the entire raw material of this system.

If you want help designing the instrumentation or reading the first month of signals, a free consulting call is a reasonable place to map your existing approval flow onto these fields. And if the approval flow itself is agent-driven, running every model behind a single endpoint makes plumbing the pause and the gap event far simpler: Quanta Inference exposes text, image, video, audio and embedding models through one OpenAI-compatible API, so the approval hook lives in one place rather than one per provider.