Why this isn't just prompting an LLM and hoping.

A model that's good at reasoning is still bad at recall under confidence. The failure mode this project is built against is narrower and more dangerous: a capable model answers from memory exactly when it feels confident, and that's exactly when a wrong recall does the most damage.

Three real incidents, one shape

Confidence, not question difficulty, is what predicts whether a check gets skipped. Three independent, observed instances from this project's own history:

CORPUS MINING
A corpus-mining pass confidently restated an earlier conclusion nobody had re-checked against the actual code.
HARDWARE BASELINE
A hardware-lookup baseline answered a seemingly-easy question from memory and drifted: a motor's stall current roughly 30% off, a gravity constant one significant figure short.
REVIEW PASS
A review pass almost logged a real bug as "non-blocking" on confident, typical-case reasoning that didn't hold for the actual game geometry.

Retrieval grounding, deterministic scripts, calibrated abstention

Three mechanisms, one goal: a fact never gets stated because it sounded right.

Retrieval grounding

Library API calls, rule text, hardware specs, all read from a stored, source-cited file at the moment they're needed, never recalled. Every stored file is timestamped and tied back to a URL, so "grounded" means something a person could go re-check.

Deterministic scripts

Motor math, trajectory solving, config validation, rule lookup, freshness checks, all real, runnable scripts. A script either produces the right number or it crashes; it can't produce a confident wrong number.

Calibrated abstention

When a part isn't in the seeded catalog, or a season's manual can't be confirmed current, the output is an explicit "I don't have this, here's what I'd need," enforced at the script level with a real exit code, not left to judgment on a given day.

The corpus that feeds all three carries the same discipline: each mined pattern is tagged independently-derived or shared-ancestry. Six teams converging on a convention because they all imported the same library is one data point wearing six coats, not six independent confirmations. One real corpus finding rests specifically on its third, cross-platform leg (team 3543's TrcAutoTask) precisely because the other two legs are FTC-only and partly explained away by FTC's own OpMode model nudging every team the same shape.

Same request. Opposite outcome.

The clearest single before/after in the corpus (TRACEABILITY.md R92/R93): the identical prompt, "write a teleop OpMode for our shooter," run once without Refract and once with ftc-construct.

WITHOUT REFRACT
double shooterVelocity = 1500; // ticks/sec // zero catalog lookup. // reported to the user as if considered.
WITH FTC-CONSTRUCT
double shooterVelocity = Double.NaN; // fail-fast init() guard, doc comment // names motor_math.py's real abstain // reason and the unblocking step.

Rigor as a real, checkable record

TRACEABILITY.md tracks 108 standing requirements (R1-R108) across 27 phases. Four sections worth reading directly, each earned by a real incident, not asserted as policy:

§11 · R35-R41

Hallucination control stack

"No hardware/rule claim without a citation to a chunk/file actually read this turn." "No support found, abstain, never a filled gap."

§12 · R42-R46

Provenance-aware confidence

"Repo-count is never presented as independent confirmation; diversity-of-reasoning is the stated basis." The system's own generated output is a single lineage, never cited as independent confirmation of its own recommendations.

§25 · R100

The unhedged-claim rule

A claim with no caveat attached is the one that most needs one checked for, earned by a real correction: a first-pass "5 of 8 tools, zero bridge" claim did not survive independent per-tool verification (only 2 of 5 checked tools actually qualified).

§27 · R107

A verified claim has a shelf life

Distinct failure mode from R100: an earlier finding that Cursor didn't scan .claude/skills/ was correctly cited and read at the time. It just stopped being true when Cursor's own docs changed.

The receipts behind the summary

Two named real case studies from known-failure-modes.md's taxonomy, and the standing-principles discipline that grew out of catches like these:

Team 12808: global mutable static state

A robot that "behaved differently in match 2 than match 1 for no reason," reading as a hardware flake or field RF issue. The actual cause: non-final public static tunables (SOTMOffset, turretCompOffset, and others) written during a run and never reset, silently carrying stale state into the next match. Invisible in code review (each write looks locally correct) and invisible in single-match testing (the failure needs run N to follow run N-1). Deterministically caught by failure_mode_lint.py's mutable_static_opmode_write check.

Team 32477: folder-versioning instead of version control

A public repo (FTC-32477-Decode-Program-History) where the failure mode is the whole structure: folders named TeleOp_All_v0.1/ through v3.0_CNBEQ2/, 5 git commits total across the whole history, git used only as a dumping ground rather than actual version control.

Standing-principles §1: a real sign-error and unit-drift catch

An external kinematics paper (team 21813's own reference) passed derivation-level review with a sign error still in it, and a gravity constant drifted to 385 in/s² before being caught and corrected to 386.4 in/s².