Proving Claims

Overview

Evidence should answer named claims. It should not just create a vague sense that the change is fine. This skill turns each claim into a proof you can trace. It keeps six things apart: a fact, an assumption, an unknown, a source claim (something a source says), local proof (something you checked yourself), and decision authority (who gets to decide).

Decision contract

• Claim checked: every material claim is tied to evidence, a stated gap, or a deliberate deferral, no claim reaches past its evidence, and the load-bearing claim's evidence is reproducible by an independent party or independently authored — not the actor's own narration.
• Artifact observed: basis.md, test, and review evidence -> claim-to-evidence rows with a status (pass/fail/gap/deferred/not applicable/planned) in trace.md/verification.md.
• Decision affected: warn -- the release posture the ship.md decision weighs.
• Failure class: overreaching-claim (a claim stated past its evidence, or a fail/unowned gap carried as shippable).
• Next action: record the gap as residual risk for ship.md; a fail or unowned gap escalates to block.

When to Use

• A change record makes claims about the code, says something about safety or security, claims release readiness, or claims a dependency can be trusted.
• Tests pass, but reviewers cannot see which claim each test backs up.
• Evidence gaps have to be accepted, put off, or treated as blockers.
• The proof needs the right kind of check. The kinds are self-check, peer-check, concurrent verification (a second person checks as you go), independent verification (a separate person checks afterward), peer review, a test, or an eval.

When Not to Use

• The claim is purely about wording and carries no engineering or trust weight.
• The request is for formal verification and validation or certification. This skill does not provide those.

Inputs

• basis.md, trace.md, verification.md, and ship.md.
• Test commands, CI runs, reviews, logs, diffs, screenshots, and source links.
• Known gaps and leftover risks.

Process

1. Pull out each important claim.
2. Pick the kind of check each claim needs, and match its depth to the mode: Quick shows the path ran; Standard exercises the branches that matter; Nuclear shows that the conditions which carry consequence independently change the outcome. A green bar at statement level is not condition-level evidence.
3. Sort the support behind each claim into one of these: fact, assumption, unknown, source claim, local proof, or decision authority.
4. Link each claim to its basis, the control or design feature, the code, the evidence, and the release posture.
5. Give each claim an evidence status: pass, fail, gap, deferred, not applicable, or planned.
6. Trim any claim that reaches too far, until the evidence truly backs it.
7. Record the gaps and how they affect the release.
8. For each load-bearing claim, name who authored the evidence relative to the actor. If only the actor did, it is a self-check: raise it to a reproducible or independently authored check, or carry the gap as residual risk — do not count it as an independent check. See docs/02-operating-system/actor-evidence-independence.md.

Outputs

• Claim-to-evidence rows in trace.md or verification.md.
• A clear split between fact, source, and proof for each important claim.
• Evidence commands anyone can rerun, or links to the artifacts.
• The kind of check used for each important claim.
• An updated release posture when the evidence changes.

Verification

• python tools/ng.py validate .nuclear/changes/<slug> passes for Quick or Standard records.
• Every important claim has evidence, a stated gap, or a deliberate deferral.
• No test result is used to imply unrelated safety, security, compliance, or approval.

Escalation

• Stop when the evidence is missing but the record still wants to ship.
• Escalate when claims affect public trust, regulated use, procurement, security, or safety.

Common Rationalizations

• "CI passed, so all claims pass." CI only proves what it checks.
• "A reviewer can read the code." Review counts as evidence only when its scope and result are written down.
• "The same agent checked itself." That can be a self-check, but it is not an independent check — the actor that made the change also wrote the proof, so the gate is downstream of the same mistake.
• "The write-up says it passed." A confident narrative the actor authored is a claim, not evidence. Verify it; do not read it as the verification.
• "We should not mention gaps." Hidden gaps lead to worse release decisions.

Red Flags

• The evidence status is missing.
• A claim says "safe", "secure", "compliant", or "approved" with no scope around it.
• The release decision ignores failed or deferred evidence.
• The only evidence for the load-bearing claim is the actor's own narration, and no independent party can reproduce it.

Prompt

Prove the important Nuclear-grade claims in this packet.

Inputs:
- packet: .nuclear/changes/<slug>/
- claims: <list or source file>
- evidence available: <commands/links/reviews/logs>
- known gaps: <list>

Return:
- claim -> basis -> control/design feature -> support type -> verification type -> evidence -> status -> ship posture
- for each load-bearing claim: who authored the evidence relative to the actor, whether an independent party can reproduce it, and the independence rung (a self-check carried as residual risk if below the stakes)
- narrower wording for any claim that is too broad
- the gaps, deferrals, or blockers, stated plainly
- the validator command to run

Source-lineage note

This skill is an original claim-evidence workflow influenced by public software assurance, verification discipline, and secure development sources mapped in docs/00-standards-foundation/source-map.md. It is not formal verification.