# Challenge Schema

Challenges are first-class counter-arguments or counter-evidence against specific claims. They are the primary contribution mechanism for new participants — "prove us wrong" is the entry point.

Challenges differ from divergences:
- **Challenge:** One person's counter-argument against one claim. An action.
- **Divergence:** Two or more claims in tension within the KB. A structural observation.

A challenge can trigger a divergence if it produces a new competing claim. But most challenges sharpen existing claims rather than creating new ones.

## Why Challenges Are First-Class

Without a standalone schema, challenges are metadata buried in claim files (`challenged_by` field, `## Challenges` section). This means:
- No attribution for challengers — the highest-value contributor action has no credit path
- No independent evidence chain — counter-evidence is subordinate to the claim it challenges
- No linking — other claims can't reference a challenge
- No tracking — open challenges aren't discoverable as a class

Making challenges first-class gives them attribution, evidence chains, independent linking, and discoverability. This is the schema that makes "prove us wrong" operational.

## YAML Frontmatter

```yaml
---
type: challenge
target: "claim-filename-slug"  # which claim this challenges (filename 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 capturing the counter-argument"
status: open | addressed | accepted | rejected
strength: strong | moderate | weak
source: "who raised this challenge and key counter-evidence"
created: YYYY-MM-DD
resolved: null  # YYYY-MM-DD when status changes from open
---
```

## Required Fields

| Field | Type | Description |
|-------|------|-------------|
| type | enum | Always `challenge` |
| target | string | Filename slug of the claim being challenged |
| domain | enum | Domain of the target claim |
| description | string | The counter-argument in one sentence (~150 chars) |
| status | enum | `open` (unresolved), `addressed` (target claim updated to acknowledge), `accepted` (target claim modified or confidence changed), `rejected` (counter-evidence insufficient, with explanation) |
| strength | enum | `strong` (direct counter-evidence), `moderate` (plausible alternative explanation or scope limitation), `weak` (edge case or theoretical objection) |
| source | string | Attribution — who raised this, key counter-evidence |
| created | date | When filed |

## Optional Fields

| Field | Type | Description |
|-------|------|-------------|
| resolved | date | When status changed from `open` |
| resolution_summary | string | One sentence: how was this resolved? |
| attribution | object | Role-specific contributor tracking (see `schemas/attribution.md`) |

## Status Transitions

| Transition | What it means | Who decides |
|-----------|--------------|-------------|
| open → addressed | Target claim updated its Challenges section to acknowledge this counter-evidence | Claim author + reviewer |
| open → accepted | Target claim changed confidence, scope, or wording based on this challenge | Claim author + reviewer |
| open → rejected | Counter-evidence evaluated and found insufficient — rejection reasoning documented | Reviewer (Leo + domain peer) |
| addressed → accepted | Acknowledgment led to actual claim modification | Claim author + reviewer |

**Key rule:** Rejecting a challenge requires explanation. The rejection reasoning lives in the challenge file's Resolution section, not just a status flip. This is what makes the system intellectually honest — you can't silently dismiss counter-evidence.

## Title Format

Challenge titles state the counter-argument as a prose proposition, prefixed with the target claim context.

**Good:** "the AI content acceptance decline claim may be scope-bounded to entertainment because reference and analytical AI content shows no acceptance penalty"
**Bad:** "challenge to AI acceptance claim"

**The challenge test:** "This note argues against [target claim] because [title]" must work as a sentence.

## Body Format

```markdown
# [counter-argument as prose]

## Target Claim
[[target-claim-filename]] — [one sentence summary of what the target claims]

**Current confidence:** [target claim's confidence level]

## Counter-Evidence

[The argument and evidence against the target claim. This is the substance — why is the claim wrong, incomplete, or mis-scoped?]

- [evidence source 1] — what it shows
- [evidence source 2] — what it shows

## Scope of Challenge

[Is this challenging the entire claim, or a specific scope/boundary condition?]

- **Full challenge:** The claim is wrong — here's why
- **Scope challenge:** The claim is true in context X but not in context Y — the scope is too broad
- **Evidence challenge:** The claim's evidence doesn't support its confidence level

## What This Would Change

[If accepted, what happens downstream? Which beliefs and positions depend on the target claim?]

- [[dependent-belief-or-position]] — how it would be affected
- [[related-claim]] — how it would need updating

## Resolution

[Filled in when status changes from open. Documents how the challenge was resolved.]

**Status:** open | addressed | accepted | rejected
**Resolved:** YYYY-MM-DD
**Summary:** [one sentence]

---

Relevant Notes:
- [[related-claim]] — relationship
- [[divergence-file]] — if this challenge created or connects to a divergence

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

## Governance

- **Who can file:** Any contributor, any agent. Challenges are the primary entry point for new participants.
- **Review:** Leo + domain peer review for quality (is the counter-evidence real? is the scope of challenge clear?). Low bar for filing — the quality gate is on the evidence, not the right to challenge.
- **Resolution:** The claim author must respond to the challenge. They can update the claim (accepted), acknowledge without changing (addressed), or reject with documented reasoning (rejected). They cannot ignore it.
- **Attribution:** Challengers get full attribution. In the contribution scoring system, successful challenges (accepted) are weighted higher than new claims because they improve existing knowledge rather than just adding to it.

## Filing Convention

**Location:** `domains/{domain}/challenge-{slug}.md`

The slug should be descriptive of the counter-argument, not the target claim.

```
domains/
  entertainment/
    challenge-ai-acceptance-decline-may-be-scope-bounded-to-entertainment.md
    challenge-zero-sum-framing-needs-centaur-creator-category.md
  internet-finance/
    challenge-futarchy-manipulation-resistance-assumes-liquid-markets.md
```

## Quality Checks

1. Target claim exists and is correctly referenced
2. Counter-evidence is specific and traceable (not "I think it's wrong")
3. Scope of challenge is explicit (full, scope, or evidence challenge)
4. Strength rating matches the evidence quality
5. "What This Would Change" section identifies real downstream dependencies
6. The challenge is genuinely novel — not restating a known limitation already in the target claim's Challenges section

## Relationship to Existing Challenge Tracking

The `challenged_by` field in claim frontmatter and the `## Challenges` section in claim bodies continue to exist. When a challenge file is created:

1. The target claim's `challenged_by` field should be updated to include the challenge filename
2. The target claim's `## Challenges` section should reference the challenge file for full detail
3. The challenge file is the canonical location for the counter-argument — the claim file just points to it

This is additive, not breaking. Existing claims with inline challenges continue to work. The challenge schema provides a proper home for counter-arguments that deserve independent tracking and attribution.

## How Challenges Feed the Game

Challenges are the primary game mechanic for contributors:

1. **Discovery:** Contributors browse claims and find ones they disagree with
2. **Filing:** They file a challenge with counter-evidence
3. **Resolution:** The claim author and reviewers evaluate the challenge
4. **Credit:** Accepted challenges earn attribution proportional to the cascade impact of the change they produced
5. **Divergence creation:** If a challenge produces a genuine competing claim, it may spawn a divergence — the highest-value knowledge structure in the system

The importance of a challenge is measured by the importance of the claim it targets and the downstream dependencies that would change if the challenge is accepted. This connects directly to the structural importance scoring of the knowledge graph.