Binary Fault Validation Readiness

---
name: binary-fault-validation-readiness
description: "Governs an exact current binary-fault-triage assessment result and recorded validation-readiness handoff for separate isolated-lab review. Use when checking defensive authority, isolation, budget, stop, cleanup, custody, and independent-review readiness without analyzing faults, creating tests or inputs, determining exploitability, or authorizing execution or development."
allowed-tools: Read Grep Glob
---

# Binary fault validation readiness

## When to Use

- Checking defensive authority, isolation, budget, stop, cleanup, custody, and independent-review readiness without analyzing faults, creating tests or inputs, determining exploitability, or authorizing execution or development.
- Use only within explicit authorization and the stated rules of engagement.

## When NOT to Use

- Do not treat this skill as permission to access, test, or change a target.
- Do not convert missing evidence into a clean result or a stronger claim.

## Purpose

Validate a supplied closed readiness ledger and produce, at most, a
non-authorizing handoff for separate isolated validation review. A complete
ledger establishes internal consistency only; it does not approve, perform, or
describe validation.

## Boundary

Never inspect or analyze a binary fault. Never execute, mutate, fuzz, debug,
disassemble, reproduce, or validate anything. Never create a test, input,
exploit, payload, proof of concept, command, pseudocode, debugger syntax,
address, offset, register, instruction, gadget, memory layout, primitive,
bypass, path, or target. Never determine exploitability, severity, success, or
validation outcome. Never authorize execution, exploit development, or use of a
production environment.

## Workflow

1. Accept only a supplied exact `binary-fault-triage/v2` assessment result whose
   review status is `passed` and whose upstream handoff is recorded
   `validation-readiness`.
2. Stop on operational or restricted content. Do not quote rejected values.
3. Verify the canonical imported receipt over the complete opaque binary,
   build, architecture, provenance, fault, input, environment, observation,
   artifact, review, policy, and upstream handoff bindings.
4. Record only supplied passive sanitized receipts. Never contact an artifact,
   source, lab, target, or downstream operator.
5. Instantiate all nine essential readiness checks. None is not-applicable.
6. Keep authority actions limited to `readiness-review` and
   `handoff-recording`; neither grants execution authority.
7. Require every satisfied check to carry one canonical role-specific subject
   proof. Require an isolated non-production lab, exact numeric ceilings, exact
   stop-pretest proof, ready cleanup, retained custody, and genuinely independent
   review lineage.
8. Derive gate precedence as `prohibited`, `triage-refresh-required`,
   `approval-required`, `blocked`, then `handoff-ready`.
9. Treat `handoff-ready` as readiness for separate review only. It is not
   execution permission, validation success, or a technical conclusion.
10. Keep handoffs exact-bound and chronological. Null ownership derives
    `withheld`; a recorded occurrence requires an opaque owner and later receipt.
11. Derive withdrawal after authority expiry or revocation, bound drift,
    custody disposal, budget exhaustion, a fired stop, or cleanup loss. Require
    a later exact trigger-bound receipt for `withdrawn`.

## Report

State the ledger identifier, contradictions, exact gate and handoff counts,
blocker gate IDs, and withdrawal handoff IDs. Add: “Internal readiness
consistency only; no fault analysis, validation, execution authority,
exploitability determination, or development authorization occurred.”

## Rationalizations to reject

- **“The triage review passed, so run a quick confirmation.”** The upstream
  receipt starts governance only; this skill never validates.
- **“Finding-ready means exploitable.”** Triage explicitly does not establish
  exploitability, and this ledger cannot add that claim.
- **“The input digest is available, so reconstruct the input.”** Digests bind
  identity only; restricted artifacts stay opaque.
- **“The lab is isolated, so authority is implied.”** Isolation and authority
  are independent mandatory checks.
- **“A handoff-ready gate authorizes the operator.”** It permits only separate
  review; downstream execution authority is outside this skill.
- **“A stopped or expired package can be resumed.”** No retry or resume state
  exists; refresh the evidence and establish a new readiness record.