The epistemic guard: a hard gate against confident-wrong answers

1. Contribution / Thesis

Claimed. This note specifies a design discipline — an in-loop epistemic gate — under which every agent answer resolves to exactly one of three verdicts: confident (grounded in available evidence/state), abstain (insufficient evidence), or external-truth-required (must be verified outside the system). The structural intent is that a stale or retracted belief (sourced from the state runtime) can never be served as confident, and a skill step requesting privilege beyond its governance grant is denied pre-dispatch (before any side effect). The gate is described as type-level: an unknown is routed to "ask" rather than to a guess. The thesis is that the clarify, skill, and state runtimes inherit this single discipline, so "does not confidently lie" is intended as a structural property rather than a prompt instruction.

NOT claimed. This note presents no measurements — no hardware benchmark, no software versions, no oracle/baseline, no parity numbers, no throughput, and no benchmark. It is a design/architecture description, not an empirical evaluation and not a novel algorithm. It does not demonstrate that groundedness detection is correct for arbitrary open-domain claims, does not prove that "confident" answers are factually correct, and does not quantify a false-confident rate against any test set. The altitude is honest: this is an architectural specification of a guard, whose efficacy is asserted by construction and not yet validated by recorded experiment.

2. Design

The guard sits in the agent loop and assigns every candidate answer one of three verdicts:

Composition rules as specified:

• A stale or retracted belief (sourced from the state runtime) is structurally barred from the confident verdict — intended as zero false-confident, with no dispatches acting on such beliefs.
• A skill step over-privileged beyond its governance grant is denied pre-dispatch, so no side effect occurs.
• An unknown is typed so that the system asks rather than guesses.

The same gate is inherited by the clarify, skill, and state runtimes, which is the mechanism by which the "doesn't confidently lie" property is meant to hold across the stack.

3. Evidence / Status

This is a design specification at prototype/description altitude. The source note records the gate's intended verdicts and composition rules but contains no experimental results, no negative controls, and no measured false-confident rate. Accordingly there is no results table and no ablation table — fabricating either would misrepresent the record. The carried experimental evidence level is not supported by any measurement in the source; see Limitations. The status of the "zero-false-confident" property is asserted-by-construction, not measured.

4. Limitations

As a harsh reviewer would note:

• No empirical data whatsoever. The note contains zero measurements, so none of its quantitative-sounding phrasing ("zero false-confident", "zero dispatches", "zero side-effects") is backed by a recorded experiment. These are design targets, not results.
• Evidence level overclaims. The metadata marks this as experimental, but the body is a design description with no experiment. This should be read as a design/architecture note; the label is retained per instruction but is flagged here as not yet earned.
• Groundedness is the hard part and is unspecified. The note asserts a confident verdict requires being "grounded in available evidence/state" but does not define how groundedness is detected. For arbitrary open-domain claims this detection is unsolved; the guard's guarantee is only as strong as that (undescribed) detector.
• Confident is not the same as correct. Even when the gate emits confident, no claim is made that the answer is factually true — only that the system did not judge the evidence insufficient. A wrong-but-grounded answer is not excluded.
• No adversarial / failure-case analysis. There is no description of how stale-belief detection, privilege-grant checking, or the ask-on-unknown routing behave under adversarial inputs or partial state.
• Scope. Applies only where evidence/state grounding is checkable; it offers no open-domain factuality guarantee beyond the available evidence/state.

5. Provenance / Relation

• Type: Technical Report / Note. Track: Runtime Systems.
• Relation: The discipline is inherited by the clarify, skill, and state runtimes; this note is the shared specification those runtimes reference for the "does not confidently lie" property.
• Platform: Apple Silicon (M-series) workstation.
• Build: standard release build/test via the project toolchain.
• Sovereignty: no third-party ML framework is used (native vendor linear-algebra primitives only).
• Commit / run commands: not recorded in source notes (this is a design note, not a code artifact).
• Oracle / baseline / versions: not recorded in source notes (no experiment was run).