clay: ontology simplification — challenge schema + contributor guide

Two-layer ontology: contributor-facing (3 concepts: claims, challenges,
connections) vs agent-internal (11 concepts). From 2026-03-26 ontology audit.

New files:
- schemas/challenge.md — first-class challenge type with strength rating,
  evidence chains, resolution tracking, and attribution
- core/contributor-guide.md — 3-concept contributor view (no frontmatter,
  pure documentation)

Modified files:
- schemas/claim.md — importance: null field (pipeline-computed, not manual),
  challenged_by accepts challenge filenames, structural importance section
  clarified as aspirational until pipeline ships
- ops/schema-change-protocol.md — challenge added to producer/consumer map

Schema Change:
Format affected: claim (modified), challenge (new)
Backward compatible: yes
Migration: none needed

Pentagon-Agent: Clay <3D549D4C-0129-4008-BF4F-FDD367C1D184>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

schemas/challenge.md

@@ -43,7 +43,7 @@ resolved: null  # YYYY-MM-DD when status changes from open
 | 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) |
+| strength | enum | `strong` (direct counter-evidence), `moderate` (plausible alternative explanation or scope limitation), `weak` (edge case or theoretical objection). Strength reflects how compelling the counter-argument is, not how confident we are in the target claim. |
 | source | string | Attribution — who raised this, key counter-evidence |
 | created | date | When filed |
 

schemas/claim.md

@@ -15,6 +15,7 @@ created: YYYY-MM-DD
 last_evaluated: YYYY-MM-DD
 depends_on: []  # list of evidence and claim titles this builds on
 challenged_by: []  # list of counter-evidence or counter-claims
+importance: null  # computed by pipeline — null until pipeline support is implemented
 ---
 ```
 
@@ -38,6 +39,7 @@ challenged_by: []  # list of counter-evidence or counter-claims
 | challenged_by | list | Challenge filenames or inline counter-evidence. When a first-class challenge file exists (see `schemas/challenge.md`), reference the filename. Inline descriptions are still valid for minor objections that don't warrant a standalone file. |
 | secondary_domains | list | Other domains this claim is relevant to |
 | attribution | object | Role-specific contributor tracking — see `schemas/attribution.md` |
+| importance | float/null | Structural importance score (0.0–1.0). Computed by pipeline from downstream dependencies, active challenges, and cross-domain linkage. Default `null` — do not set manually. See Structural Importance section below. |
 
 ## Governance
 
@@ -85,7 +87,7 @@ A claim's importance in the knowledge graph is determined by:
 2. **Active challenges** — contested claims are more important than uncontested ones (they're where the knowledge frontier is)
 3. **Cross-domain linkage** — claims referenced from multiple domains carry higher structural importance
 
-Importance is computed from the graph, not stored in frontmatter. See `extract-graph-data.py` for the computation. The importance score determines contribution credit — challenging a high-importance claim earns more than challenging a low-importance one.
+Importance is computed by the pipeline and written to the `importance` frontmatter field. Until pipeline support is implemented, this field defaults to `null` — agents should not set it manually. See `extract-graph-data.py` for the planned computation. The importance score determines contribution credit — challenging a high-importance claim earns more than challenging a low-importance one.
 
 ## Quality Checks