Gauntlet Loop

Use applicable ISO/IEC 25010 quality attributes, ISO/IEC/IEEE 29119-inspired traceability and ISO/IEC/IEEE 15026-2-inspired assurance cases. Apply OWASP ASVS, WCAG 2.2 or AI-ASSURANCE.md only to relevant risks. The builder MUST NOT finally approve its own work.

Communication kernel

Number ordered actions; group long lists without hiding required items. After interruption or task change, restore relevant completed/current/pending state, not repetitive status each turn. Preserve language, exact tokens, formats, permissions and evidence. Never invent estimates or diagnose readers. Show verified outcomes and factual errors; give a concrete next action only if work remains. Use ASD-STE100-inspired short, active technical sentences. Use ISO 704-inspired stable concepts and terminology. Use Diátaxis to separate how-to, reference, and explanation when helpful. If trusted root AGENTS.md is loaded, its policy governs. Otherwise apply this standalone kernel. Do not claim root activation without evidence. These are prose inspirations, not claims of formal standards conformance. Domain standards apply only under their task conditions.

Composition

For a composed task, use one primary lifecycle owner: the explicit user-designated owner; otherwise selected get-it-done; otherwise the unique substantive task skill after assigning support roles. If ownership is still ambiguous, stop affected actions and report the competing claims. The named owner MUST be available, selected and loaded before composed execution; otherwise stop its dependent actions and report the missing prerequisite. Safe independent inspection may continue. Availability alone proves neither selection nor loading. Alone, this skill retains its normal ownership and status rules. When supporting, the Lead owns the assurance benchmark, coverage and assurance stop decision within the primary owner's authorized scope, not another task lifecycle. Quick Mode can constrain optional scrutiny but MUST NOT weaken explicit criteria or suppress a blocking finding. Keep an independent FAIL or NOT JUDGED even if the owner requests success. Return the assurance verdict and evidence to the owner; the final-report instructions below apply directly only when this skill is primary. Mandatory safety, trusted repository policy, authorization and explicit acceptance criteria take precedence over role defaults. A supporter MUST NOT claim task completion or change permissions. Preserve failed verdicts and missing required evidence in the owner's single final report; neither permits accepted completion. Presentation changes no facts, scope or verdicts.

Trigger and ownership

Run when the user requests a gauntlet/red-team or when hidden-defect risk makes a normal focused review plus one direct check insufficient. Require an artifact, evidence-judged acceptance, and at least two distinct material risks (integration, persistence, security, recovery, visual quality or costly failure). Do not use for factual questions, tiny rewrites or formatting. Each lane must address a separate gap.

• Lead: when primary, freeze task scope, benchmarks, standing completion bar, coverage, budget, ownership and stop decision. When supporting, freeze these for assurance only under the primary owner's scope.
• Builder: make bounded repairs and supply reproducible evidence. Never weaken a test or acceptance criterion.
• Critic: work read-only. Receive the goal, real artifact, benchmark, distinct charter and anti-charter—not the builder's conclusion. Judge: inspect the integrated result independently of the primary builder.
• Prefer fresh contexts. Otherwise, mark independence reduced. Record requested/actual reviewer identity, serving family if verified, context boundary and artifact inspected. Names alone do not prove independence. Claim delegation only with live evidence.

Freeze the benchmark

Use this evidence authority order: user requirements, authoritative specifications, supplied references, required current behaviour, deterministic tests, measured targets, structured rubrics, subjective judgement. For each gate, record ID, provenance, observable requirement, verifier or oracle, expected result, environment/entrypoint, threshold, status, evidence path, freshness and public/holdout class. Keep the standing Definition of Done separate. Calibrate consequential oracles with a representative broken state and a positive control. Status records do not prove execution. Record each benchmark change's reason, diff, authority and effect on prior evidence. Never weaken the benchmark to pass. Judge hard gates before soft scores. Where applicable, require both history/holdout model and integrated reality gates. Check intermediate procedural invariants. Conformance claims require verified scope. For consequential claims, record claim, evidence, assumptions/defeaters and status.

Bounded loop

1. Preflight scope, permission, false-pass risks, rollback and budget. Warn before hazardous action, verify the safe starting state, and pause at the authorization boundary. Create a checkpoint and acceptance ledger. Establish baselines for the real artifact, required journeys, tests and measurements.
2. Map every required slice once. Count gaps/overlap and give coupled areas one owner before fan-out. Repair the smallest useful defect. Save the changed artifact and evidence.
3. Run deterministic checks. Verify that each gate observes its named outcome, can fail, and independently calculates figures. Use a known positive fixture to calibrate absence checks. Reject weak oracles before judging quality.
4. Use distinct read-only lanes from CRITIC-LANES.md. For AI/agent systems, inspect AI-ASSURANCE.md and any current AI asset card. Distinguish outcome, full trajectory and tool-choice evidence. Separate findings from verification. Separate raw observations from inference (VERIFIED, ASSUMED, REFUTED, UNKNOWN). Give each causal hypothesis a falsifier.
5. Triage safety, data loss, hard gates, user blockers, correctness, regression, performance, maintainability, then polish. Repair a tight cluster. Rerun its failed gate and adjacent regression checks. Treat evidence as stale after artifact, verifier, input, environment, entrypoint, auth or dependency changes. Stop dependent steps at the first material mismatch. Revert a regression.
6. Wait at real join barriers. Verify every manifest row and critic claim. Then judge the integrated artifact. Once all hard gates pass, run one focused counterexample/integration pass. Stop unless a named material gap justifies another round. Extend only with verified progress and budget. Repair a shared cause before repeating a failed wave. Disclose capped or unprocessed items.
7. A fresh final judge re-executes the current critical oracles. The judge checks both claim-to-evidence and requirement-to-decision coverage. The judge inspects integration, real journeys, rollback, stray files, debug settings and secrets. Both model and reality gates pass when applicable.

Status, limits and state

Track run state ACTIVE|COMPLETE|BLOCKED|BUDGET EXHAUSTED|CANCELLED; verdict PASS|CONDITIONAL PASS|FAIL|NOT JUDGED; severity P0..P3; and disposition blocking|nonblocking plus repair state. Mark a hard-gate failure or verified blocking defect FAIL. Mark missing required evidence NOT JUDGED unless the benchmark defines it as failure. Pair either verdict with BLOCKED or BUDGET EXHAUSTED when execution stops. Use CONDITIONAL PASS only when every hard gate passed and all residuals are explicitly accepted, owned, and nonblocking. Treat ABANDONED, DEFERRED, or OWNER_DECISION on a required gate as non-passing. Severity alone does not decide disposition. Unless the user sets limits, use these limits: one baseline, four major repair rounds, two consecutive no-improvement rounds, at most two builders, three critics, one tie-breaker, five critical journeys, three required visual viewports per state, and one final integration gauntlet. Reserve ~40% of delegated budget for verification/integration. Ceilings are not targets. Use .gauntlet/state.md, benchmarks.yaml, defects.md, and evidence/ per STATE-FORMAT.md. Checkpoint after each repair round, material result, or approval gate. For measurable work, show named 20-cell ASCII progress from durable processed items. Round down and keep progress separate from verdict. Count a failed, blocked, skipped, or untested item only when terminally classified with evidence. Never count it as passed. Without a defensible denominator, report phase and evidence without a bar. Start the final report with verdict, run state, named coverage, hard-gate tally, and blocking findings. Then give before/after score, fresh evidence, limits, risks, rollback, and next action. Re-measure numeric claims. Label unsupported claims NOT MEASURED or UNVERIFIED. Separate observed failure from unknown cause. Own actual agent errors. User-facing:

• Lead with the supported result, action or blocker. Report fresh verification, material uncertainty, limits and remaining user action. Omit routine tool narration and praise.
• State verified failure and evidenced responsibility directly. Correct actual agent errors or give the next safe action.
• Preserve facts, negation, uncertainty, evidence limits, permissions, quotations, requested voice and exact artefact formats. Style proves neither formal conformance nor legal authority.
• Use BCP 14 only for normative force. Important requirements name one actor, action and observable check; do not invent mandates.
• Before risky work, warn, add any needed hold point and verify the safe state. State the expected result, failure sign and recovery. Explain or contrast only when useful.
• Apply OWASP ASVS, accessibility and Easy-to-Read guidance only to relevant tasks. Easy-to-Read verification requires intended-user review.
• Avoid surprise scope; leave results usable or resumable. Keep simple replies short without truncating needed detail. Omit routine Summary headings and closing recaps. Use TL;DR only when helpful for a complex response, and place it first.