Claim
Input: $ARGUMENTS
Interpretations
Before executing, identify which interpretation matches the user’s input:
Interpretation 1 — Direct assertion: The user states something as fact (“X is true”, “Y causes Z”) and it needs testing. Interpretation 2 — Uncertain belief: The user holds a belief with some doubt (“I think X”, “Is X true?”) and wants it examined. Interpretation 3 — Received wisdom: The user presents something they’ve heard or read (“People say X”, “The conventional view is X”) and wants to know if it holds up.
If ambiguous, ask: “Are you asserting this, questioning it, or reporting what others believe?” If clear from context, proceed with the matching interpretation.
Core Principles
-
Claims are tested, not confirmed. The default posture is skeptical curiosity, not validation. Testing means genuinely trying to break the claim, not finding reasons to agree with it.
-
Bundled claims must be unbundled. “Remote work is better” contains at least three claims: better for whom, better by what measure, and better under what conditions. Each gets tested separately. The most load-bearing claim goes first.
-
Untestable claims are restated, not dismissed. “Freedom is the highest value” can’t be tested as-is, but its observable consequences can. Convert to testable predictions, then test those.
-
The user’s confidence determines the balance. Confident assertions need harder adversarial testing (push AW). Uncertain doubts need harder supportive testing (push AR). Never match the user’s emotional investment — counterbalance it.
-
Verdicts are earned, not declared. A claim is VALIDATED only when AR evidence reaches bedrock and AW doesn’t find fatal flaws at bedrock. “Probably true” is not a verdict — it’s a failure to test deeply enough.
-
The most interesting finding is usually the condition. Most claims are neither universally true nor universally false. The valuable output is: “True when A, false when B, and the crux is whether you’re in A or B.”
Routing Decisions
1. Extract the Proposition
What is being claimed? State it as a single testable sentence.
If the input is vague, restate it precisely before proceeding. A claim must be falsifiable — it must be possible for it to be wrong.
2. Is This Actually a Claim?
- “Should I X?” → This is a decision, not a claim. → INVOKE: /decide $ARGUMENTS
- “I want X” → This is a goal. → INVOKE: /want $ARGUMENTS
- “I’m frustrated that X” → This is emotional. → INVOKE: /emotion $ARGUMENTS
- “What are the options for X?” → This is exploration. → INVOKE: /search $ARGUMENTS
- “I think X” (tentative, uncertain) → Use /it to formalize the claim first. → INVOKE: /it $ARGUMENTS
- “X, but Y” (claim with objection attached) → Use /but to separate and resolve. → INVOKE: /but $ARGUMENTS
- “I’m not sure about X” → Use /nsa to classify the uncertainty first. → INVOKE: /nsa $ARGUMENTS
- “Handle this” (vague) → INVOKE: /handle $ARGUMENTS
- If it IS a claim → continue.
3. Claim Shape Detection
- Single claim: proceed directly.
- Multiple claims bundled: unbundle into separate claims. Test the most load-bearing one first, then the others.
- Claim with “etc” or “and so on”: expand the implicit list first. → INVOKE: /etc or /aso on the claim tail, then test each expanded claim.
- Claim that is a platitude (“Move fast and break things”, “Fail fast”): needs operationalization before testing. → INVOKE: /platitude $ARGUMENTS — then test the operationalized version.
- Contradictory platitudes (“Move fast” vs “Measure twice”): → INVOKE: /platitudes $ARGUMENTS
- Hidden compound: “X is better than Y” bundles “X has property A”, “Y lacks property A”, and “property A is the right measure.” Unbundle all three.
4. Is the Claim Testable?
- Testable (“Remote work is more productive”): proceed to ARAW.
- Untestable/definitional (“Freedom is the highest value”): unpack what it would MEAN for this to be true — what observable consequences follow? Test those instead.
- Ethical/moral claim (“We should do X because it’s right”): needs ethical analysis alongside truth-testing. → INVOKE: /eth $ARGUMENTS — then ARAW the factual components.
5. Determine Depth
- Fragment or single sentence with no qualifiers → 2x
- Sentence with context or qualifiers → 4x
- Paragraph with reasoning → 4x-8x
- User specifies depth → use that
- User wants maximum rigor → INVOKE: /certainty $ARGUMENTS instead
6. Set AR/AW Balance
- User says “I believe X” or asserts confidently → push AW harder (test the doubt side more). 60% AW.
- User says “I doubt X” or is skeptical → push AR harder (find what supports it). 60% AR.
- User says “Is X true?” with no lean → balanced 50/50.
- User reports received wisdom (“people say X”) → push AW harder. 60% AW.
- Default: 50/50.
Exception: If the user’s confidence is about their own future capability or aspiration (‘I can do X’, ‘I will achieve Y’), the confidence is not evidence of bias — it’s a claim about commitment. Test the claim’s feasibility, not the user’s right to be confident.
7. Does the Claim Need Context First?
Before testing, some claims need additional framing:
- Claim about the future (“AI will replace programmers by 2030”): → also INVOKE: /fut $ARGUMENTS for temporal context.
- Claim about what’s obvious (“Obviously we should X”): → also INVOKE: /obv $ARGUMENTS to check if the “obvious” holds up.
- Claim that something is safe/dangerous: → also INVOKE: /saf $ARGUMENTS for safety-specific analysis.
- Claim with hidden assumptions: → also INVOKE: /aex $ARGUMENTS to surface them before testing.
Execute
→ INVOKE: /araw $ARGUMENTS
Use the depth and balance determined above.
For bundled claims: → Unbundle first, then INVOKE: /araw on the most load-bearing claim → Then INVOKE: /araw on remaining claims if needed
For untestable claims: → Restate as testable prediction first → Then INVOKE: /araw on the restated claim
Supplementary Analysis (invoke when relevant)
| Situation | Also invoke |
|---|---|
| Claim is an argument with premises | → /agsk (argument analysis) |
| Claim involves predictions | → /fut (future analysis) |
| Claim involves best/worst outcomes | → /gop, /obo, /ogo |
| Claim seems too easy or obvious | → /obv (obvious check) |
| You suspect self-deception | → /sdc (self-deception check) |
| Claim involves safety | → /saf (safety analysis) |
| Claim involves ethics | → /eth (ethics analysis) |
| Claim could be tested empirically | → /abts (A/B test design) |
Failure Modes
| Failure | Signal | Fix |
|---|---|---|
| Confirmation testing | AR much deeper than AW; all claims VALIDATED | Push AW harder — find the genuine weaknesses |
| Unbundling failure | Compound claim tested as single unit | Decompose into atomic claims, test each |
| Vague verdict | ”It’s complicated” or “it depends” without specifics | State exactly what it depends ON — name the conditions |
| Testing the wrong claim | Lots of analysis but the user’s actual question isn’t answered | Re-read the input; are you testing what they asked? |
| Definitional dodge | Claim restated until trivially true | Test the version that has real-world implications, not the safe version |
| Balance mismatch | Testing aligns with user’s confidence instead of counterbalancing | If user is confident, push AW. If doubtful, push AR. |
Depth Scaling
| Depth | Scope | Floor |
|---|---|---|
| 1x | Quick test — one AR/AW pass on the main claim | 5 claims, 12 findings |
| 2x | Standard — unbundle, test main claim, note conditions | 7 claims, 20 findings |
| 4x | Thorough — all claims tested, assumptions surfaced | 12 claims, 35 findings |
| 8x | Deep — full unbundling, all claims to bedrock, alternatives derived | 18 claims, 55 findings |
Pre-Completion Checklist
- Claim extracted and stated as testable sentence
- Bundled claims unbundled into separate propositions
- AR/AW balance set based on user’s confidence level
- ARAW executed at appropriate depth
- Verdict derived from evidence (not asserted)
- Conditions identified (when true / when false)
- What would change the verdict is stated
- Hidden assumptions surfaced (via /aex if needed)
After Completion
Report:
- The claim as tested (restated precisely)
- Whether it was unbundled (and which sub-claim was most load-bearing)
- Verdict from ARAW (validated / conditional / damaged / rejected / uncertain)
- Key AR findings and key AW findings
- Conditions (true when X, false when Y)
- What would change the verdict
- If supplementary skills were used, their findings integrated
Follow-Up Routing
After the claim is tested, the user may need:
- “What should I do about this?” → INVOKE: /decide or /how
- “What are the implications?” → INVOKE: /sycs $ARGUMENTS
- “What’s the worst case?” → INVOKE: /dys $ARGUMENTS
- “What skill should I run next?” → INVOKE: /next or /fonss
Integration
- Use from: /emotion (doubt about self becomes testable claim), /evaluate (core claims extracted and tested), /diagnose (suspected cause tested as claim), /decide (each option’s premises tested)
- Routes to: /araw (primary — the testing engine), /aex (assumption extraction), /it (claim formalization), /but (claim-objection separation), /eth (ethical claims), /fut (future claims)
- Differs from: /viability (claim tests truth, viability tests workability), /evaluate (claim tests a proposition, evaluate assesses a piece of work), /decide (claim tests one statement, decide compares options)
- Complementary: /aex (surface hidden assumptions), /se (enumerate alternative claims), /ver (GOSM verification for empirical claims), /obv (test “obvious” claims)