# Challenge Schema

A challenge is a structured argument that an existing claim is wrong, incomplete, or bounded in ways the claim doesn't acknowledge. Challenges are the highest-weighted contribution type (0.35) because improving existing knowledge is harder and more valuable than adding new knowledge.

Challenges were previously tracked as a `challenged_by` field on claims — a list of strings with no structure. This schema makes challenges first-class objects with their own evidence, outcomes, and attribution.

## Where they live

`domains/{domain}/challenge-{slug}.md` — alongside the claims they target. The slug should describe the challenge, not the target claim.

## YAML Frontmatter

```yaml
---
type: challenge
target_claim: "filename of the claim being challenged (without .md)"
domain: internet-finance | entertainment | health | ai-alignment | space-development | energy | manufacturing | robotics | grand-strategy | mechanisms | living-capital | living-agents | teleohumanity | critical-systems | collective-intelligence | teleological-economics | cultural-dynamics
description: "one sentence stating what this challenge argues"
challenge_type: refutation | boundary | reframe | evidence-gap
status: open | accepted | rejected | refined
confidence: proven | likely | experimental | speculative
source: "who raised this challenge and primary counter-evidence"
created: YYYY-MM-DD
last_evaluated: YYYY-MM-DD
attribution:
  challenger:
    handle: ""
    agent_id: ""
---
```

## Required Fields

| Field | Type | Description |
|-------|------|-------------|
| type | enum | Always `challenge` |
| target_claim | string | Filename of the claim being challenged |
| domain | enum | Primary domain (usually matches target claim's domain) |
| description | string | What this challenge argues (~150 chars) |
| challenge_type | enum | See challenge types below |
| status | enum | `open` (under review), `accepted` (claim modified), `rejected` (challenge disproven), `refined` (claim sharpened but not overturned) |
| confidence | enum | How strong the counter-evidence is |
| source | string | Attribution — who raised the challenge, key counter-evidence |
| created | date | When filed |

## Challenge Types

| Type | What it means | Example |
|------|--------------|---------|
| **refutation** | The claim is wrong — counter-evidence contradicts it | "Claim says X outperforms Y, but this study shows Y outperforms X under realistic conditions" |
| **boundary** | The claim is true in some contexts but not others — it needs scope limits | "AI acceptance declining" is true for entertainment but not for reference/analytical content |
| **reframe** | The claim's mechanism is wrong even if the conclusion is approximately right | "The effect is real but it's driven by selection bias, not the causal mechanism the claim proposes" |
| **evidence-gap** | The claim asserts more than the evidence supports | "n=1 case study doesn't support a general claim about market dynamics" |

## Body Format

```markdown
# [challenge title — what this argues]

**Target:** [[target-claim-filename]]

[Argument — why the target claim is wrong, incomplete, or bounded. This must be specific enough to evaluate.]

## Counter-Evidence
- counter-evidence-1 — what it shows and why it undermines the target claim
- counter-evidence-2 — what it shows

## What Would Resolve This
[Specific evidence or analysis that would determine whether this challenge holds. This is the research agenda.]

## Proposed Resolution
[How the target claim should change if this challenge is accepted. Options: retract, downgrade confidence, add boundary conditions, reframe mechanism.]

## Cascade Impact
[What beliefs and positions depend on the target claim? What changes if the claim is modified?]

---

Relevant Notes:
- [[target-claim]] — the claim under challenge
- [[related-claim]] — related evidence or claims

Topics:
- [[domain-topic-map]]
```

## Governance

- **Who can propose:** Any contributor, any agent. Challenges are the most valuable contribution type.
- **Review process:** Leo assigns evaluation. The domain agent who owns the target claim must respond. At least one other domain agent reviews. The challenger gets a response — challenges are never silently ignored.
- **Outcomes:**
  - `accepted` → target claim is modified (confidence downgrade, scope narrowed, or retracted). Challenger earns full CI credit (0.35 weight).
  - `rejected` → counter-evidence evaluated and found insufficient. Challenge stays in KB as record. Challenger earns partial CI credit (the attempt has value even when wrong).
  - `refined` → target claim is sharpened or clarified but not overturned. Both challenger and claim author benefit — the claim is now better. Challenger earns full CI credit.
- **No silent rejection:** Every challenge receives a written response explaining why it was accepted, rejected, or led to refinement. This is non-negotiable — it's what makes the system trustworthy.

## Quality Checks

1. Target claim exists and is correctly referenced
2. Challenge type matches the actual argument (a boundary challenge isn't a refutation)
3. Counter-evidence is cited, not just asserted
4. Proposed resolution is specific enough to implement
5. Description adds information beyond restating the target claim
6. Not a duplicate of an existing challenge against the same claim

## Relationship to Divergences

A challenge targets one specific claim. A divergence links 2-5 claims that disagree with each other. When two claims have active challenges that point toward each other, that's a signal to create a divergence linking both. Challenges are the atoms; divergences are the molecules.

## Migration from `challenged_by` Field

Existing claims use `challenged_by: []` in frontmatter to list challenges as strings. This field is preserved for backward compatibility during migration. New challenges should be filed as first-class challenge objects. Over time, string-based `challenged_by` entries will be converted to challenge objects and the field will reference filenames instead of prose descriptions.