claim

name	claim
description	Create or update a claim card in the vault. In create mode, guides through evidence collection, confidence assessment, and boundary conditions. In update mode, adds new evidence or changes status. Triggers on "/claim", "/claim create [proposition]", "/claim update [claim-id]", "/claim status", "add a claim", "update claim evidence".
version	1.0
generated_from	swarm-research-os-v0.1
user-invocable	true
allowed-tools	Read, Write, Edit, Glob, Grep, Bash
context	fork
model	opus
argument-hint	create [proposition] | update [claim-id] | status | list

EXECUTE NOW

Target: $ARGUMENTS

Parse immediately:

• create [proposition] → create a new claim card (Step 1–6)
• update [claim-id] → update an existing claim (Step 7–9)
• status → show claim health dashboard (Step 10)
• list → list all claims with status and confidence (Step 11)
• Empty → show help with subcommand options

---

CREATE MODE: Steps 1–6

Step 1: Parse Proposition

The proposition is the claim stated as a testable sentence. It becomes both the filename and the H1 title.

Rules:

• Must be a complete proposition (not a label or question)
• Composability test: "This note argues that [proposition]"
• Lowercase, no trailing period
• Filename: kebab-case with claim- prefix. E.g., "circuit breakers alone outperform full governance stacks" → claim-circuit-breakers-alone-outperform-full-governance-stacks.md
• Truncate filename to max 80 chars if needed

If no proposition provided, ask: "State the claim as a testable proposition (e.g., 'transaction tax above 5% reduces welfare')."

Step 2: Gather Evidence

Search for supporting runs:

1. Ask the user: "Which run(s) support this claim? (run_id or 'search')"
2. If user says "search":
   • Ask for keywords related to the claim
   • Search run-index.yaml by tags
   • Search runs/*/summary.json for relevant metrics
   • Present top candidates with one-line summaries
3. For each supporting run, extract:
   • run_id
   • Primary metric and value
   • Effect size (Cohen's d), p-value, correction method, sample size
   • Construct the detail string: "d={d}, p={p}, N={N}, {correction}-corrected"

Step 3: Assess Confidence

Based on the evidence gathered, recommend a confidence level:

Confidence	Criteria
high	Bonferroni-significant AND replicated across ≥2 independent runs/seeds
medium	Nominally significant OR single-sweep support with BH correction
low	Suggestive but underpowered (<20 seeds) or unreplicated
contested	Conflicting evidence from different runs

Present the recommendation and let the user confirm or override.

Step 4: Document Boundary Conditions

Ask: "What are the known limits of this claim's generalizability?"

Prompt with common dimensions:

• Topology tested (e.g., "small-world only")
• Agent count (e.g., "8 agents")
• Adversarial fraction (e.g., "25%")
• Governance config
• Agent type (e.g., "algorithmic, not LLM-powered")

Step 5: Determine Domain and Related Claims

1. Domain: infer from the proposition and evidence. Must be one of: governance, topology, agent-behavior, decision-theory, collusion, memory, market, calibration, methodology
2. Related claims: scan vault/claims/ for claims with overlapping topics or shared run evidence. Present candidates and let user confirm.

Step 6: Write the Claim Card

Generate vault/claims/{claim-id}.md using the template at vault/templates/claim-card.md.

Fill every field:

• description: ≤200 chars summarizing the claim
• type: claim
• status: active (default for new claims)
• confidence: from Step 3
• domain: from Step 5
• evidence.supporting: from Step 2
• evidence.weakening: [] (new claims start with no weakening evidence)
• evidence.boundary_conditions: from Step 4
• sensitivity: infer from boundary conditions
• related_claims: from Step 5
• created: today's date
• Body sections: Evidence summary, Boundary conditions, Mechanism, Open questions

After writing:

1. Update vault/_index.md to include the new claim
2. Report the created file path and a summary

---

UPDATE MODE: Steps 7–9

Step 7: Read Existing Claim

Read vault/claims/{claim-id}.md. Parse frontmatter. Display current state:

• Status, confidence, domain
• Evidence count (supporting / weakening)
• Boundary conditions
• Last updated date

Step 8: Determine Update Type

Ask: "What kind of update?"

• Add supporting evidence — new run that confirms the claim
• Add weakening evidence — new run that contradicts the claim
• Add boundary condition — new limitation discovered
• Change status — active → weakened → superseded → retracted
• Change confidence — upgrade or downgrade based on new evidence

For each type:

Add supporting/weakening evidence:

1. Ask for run_id
2. Read the run's summary to extract metrics
3. Add the evidence entry to the appropriate list
4. Reassess confidence (Step 3 logic) and recommend if it should change

Change status:

• active → weakened: requires at least one weakening evidence entry
• active → superseded: requires a superseded_by claim_id
• any → retracted: requires explanation in the body

Step 9: Apply Update

Edit the claim file using the Edit tool:

1. Update frontmatter fields
2. Update updated date to today
3. If status changed to weakened, emit a warning:

⚠ CLAIM WEAKENED: {claim-id}
Previous confidence: {old}
New confidence: {new}
Contradiction: {detail}

Consider creating a GitHub issue for investigation.

Update vault/_index.md if the description changed.

---

STATUS MODE: Step 10

Generate a claim health dashboard:

1. Glob vault/claims/*.md
2. For each claim, read frontmatter
3. Display:

## Claim Health Dashboard

| Claim | Status | Confidence | Evidence | Domain | Updated |
|-------|--------|------------|----------|--------|---------|
| circuit-breakers-dominate | active | high | 2S/0W | governance | 2026-02-18 |
| tax-welfare-tradeoff | active | high | 2S/0W | governance | 2026-02-18 |
| smarter-agents-earn-less | active | high | 3S/0W | agent-behavior | 2026-02-18 |
| staking-backfires | active | medium | 1S/0W | governance | 2026-02-18 |

**Summary:**
- {N} active claims ({M} high confidence, {K} medium, {J} low)
- {W} weakened claims
- {S} superseded claims
- {R} retracted claims
- {U} claims not updated in >30 days

---

LIST MODE: Step 11

Quick list of all claims, one per line:

vault/claims/claim-circuit-breakers-dominate.md — active/high — governance
vault/claims/claim-tax-welfare-tradeoff.md — active/high — governance
vault/claims/claim-smarter-agents-earn-less.md — active/high — agent-behavior
vault/claims/claim-staking-backfires.md — active/medium — governance

---

Critical Constraints

1. Prose-as-title. The claim filename and H1 must be a testable proposition.

2. Evidence provenance is mandatory. Every evidence entry must reference a real run_id that exists in runs/. Verify before writing.

3. Confidence must be justified. The confidence level must match the evidence quality criteria in Step 3. Do not assign high without Bonferroni-significant replicated evidence.

4. Boundary conditions are not optional. Every claim must document what has NOT been tested.

5. Never silently change status. Status changes (especially weakening) must be visible and explained.

6. Description ≤200 chars, no trailing period. This is a kernel invariant.

7. Topics footer is mandatory. Every claim must link to [[_index]] at minimum.