clay: ontology simplification — challenge schema, contributor guide, importance score

Two-layer ontology: contributor-facing (claims/challenges/connections) vs agent-internal (full 11).

New files:
- schemas/challenge.md — first-class challenge schema with types, outcomes, attribution
- core/contributor-guide.md — 3-concept contributor view
- agents/clay/musings/ontology-simplification-rationale.md — design rationale

Modified:
- schemas/claim.md — add importance field, update challenged_by to reference challenge objects

Co-Authored-By: Clay <clay@agents.livingip.xyz>

agents/clay/musings/ontology-simplification-rationale.md

@@ -0,0 +1,95 @@
+---
+type: musing
+agent: clay
+title: "Ontology simplification — two-layer design rationale"
+status: ready-to-extract
+created: 2026-04-01
+updated: 2026-04-01
+---
+
+# Why Two Layers: Contributor-Facing vs Agent-Internal
+
+## The Problem
+
+The codex has 11 schema types: attribution, belief, claim, contributor, conviction, divergence, entity, musing, position, sector, source. A new contributor encounters all 11 and must understand their relationships before contributing anything.
+
+This is backwards. The contributor's first question is "what can I do?" not "what does the system contain?"
+
+From the ontology audit (2026-03-26): Cory flagged that 11 concepts is too many. Entities and sectors generate zero CI. Musings, beliefs, positions, and convictions are agent-internal. A contributor touches at most 3 of the 11.
+
+## The Design
+
+**Contributor-facing layer: 3 concepts**
+
+1. **Claims** — what you know (assertions with evidence)
+2. **Challenges** — what you dispute (counter-evidence against existing claims)
+3. **Connections** — how things link (cross-domain synthesis)
+
+These three map to the highest-weighted contribution roles:
+- Claims → Extractor (0.05) + Sourcer (0.15) = 0.20
+- Challenges → Challenger (0.35)
+- Connections → Synthesizer (0.25)
+
+The remaining 0.20 (Reviewer) is earned through track record, not a contributor action.
+
+**Agent-internal layer: 11 concepts (unchanged)**
+
+All existing schemas remain. Agents use beliefs, positions, entities, sectors, musings, convictions, attributions, and divergences as before. These are operational infrastructure — they help agents do their jobs.
+
+The key design principle: **contributors interact with the knowledge, agents manage the knowledge**. A contributor doesn't need to know what a "musing" is to challenge a claim.
+
+## Challenge as First-Class Schema
+
+The biggest gap in the current ontology: challenges have no schema. They exist as a `challenged_by: []` field on claims — unstructured strings with no evidence chain, no outcome tracking, no attribution.
+
+This contradicts the contribution architecture, which weights Challenger at 0.35 (highest). The most valuable contribution type has the least structural support.
+
+The new `schemas/challenge.md` gives challenges:
+- A target claim (what's being challenged)
+- A challenge type (refutation, boundary, reframe, evidence-gap)
+- An outcome (open, accepted, rejected, refined)
+- Their own evidence section
+- Cascade impact analysis
+- Full attribution
+
+This means: every challenge gets a written response. Every challenge has an outcome. Every successful challenge earns trackable CI credit. The incentive structure and the schema now align.
+
+## Structural Importance Score
+
+The second gap: no way to measure which claims matter most. A claim with 12 inbound references and 3 active challenges is more load-bearing than a claim with 0 references and 0 challenges. But both look the same in the schema.
+
+The `importance` field (0.0-1.0) is computed from:
+- Inbound references (how many other claims depend on this one)
+- Active challenges (contested claims are high-value investigation targets)
+- Belief dependencies (how many agent beliefs cite this claim)
+- Position dependencies (how many public positions trace through this claim)
+
+This feeds into CI: challenging an important claim earns more than challenging a trivial one. The pipeline computes importance; agents and contributors don't set it manually.
+
+## What This Doesn't Change
+
+- No existing schema is removed or renamed
+- No existing claims need modification (the `challenged_by` field is preserved during migration)
+- Agent workflows are unchanged — they still use all 11 concepts
+- The epistemology doc's four-layer model (evidence → claims → beliefs → positions) is unchanged
+- Contribution weights are unchanged
+
+## Migration Path
+
+1. New challenges are filed as first-class objects (`type: challenge`)
+2. Existing `challenged_by` strings are gradually converted to challenge objects
+3. `importance` field is computed by pipeline and backfilled on existing claims
+4. Contributor-facing documentation (`core/contributor-guide.md`) replaces the need for contributors to read individual schemas
+5. No breaking changes — all existing tooling continues to work
+
+## Connection to Product Vision
+
+The Game (Cory's framing): "You vs. the current KB. Earn credit proportional to importance."
+
+The two-layer ontology makes this concrete:
+- The contributor sees 3 moves: claim, challenge, connect
+- Credit is proportional to difficulty (challenge > connection > claim)
+- Importance score means challenging load-bearing claims earns more than challenging peripheral ones
+- The contributor doesn't need to understand beliefs, positions, entities, sectors, or any agent-internal concept
+
+"Prove us wrong" requires exactly one schema that doesn't exist yet: `challenge.md`. This PR creates it.

core/contributor-guide.md

@@ -0,0 +1,110 @@
+---
+type: claim
+domain: mechanisms
+description: "Contributor-facing ontology reducing 11 internal concepts to 3 interaction primitives — claims, challenges, and connections — while preserving the full schema for agent operations"
+confidence: likely
+source: "Clay, ontology audit 2026-03-26, Cory-aligned"
+created: 2026-04-01
+---
+
+# The Three Things You Can Do
+
+The Teleo Codex is a knowledge base built by humans and AI agents working together. You don't need to understand the full system to contribute. There are exactly three things you can do, and each one makes the collective smarter.
+
+## 1. Make a Claim
+
+A claim is a specific, arguable assertion — something someone could disagree with.
+
+**Good claim:** "Legacy media is consolidating into a Big Three oligopoly as debt-loaded studios merge and cash-rich tech competitors acquire the rest"
+
+**Bad claim:** "The media industry is changing" (too vague — no one can disagree with this)
+
+**The test:** "This note argues that [your claim]" must work as a sentence. If it does, it's a claim.
+
+**What you need:**
+- A specific assertion (the title)
+- Evidence supporting it (at least one source)
+- A confidence level: how sure are you?
+  - **Proven** — strong evidence, independently verified
+  - **Likely** — good evidence, broadly accepted
+  - **Experimental** — emerging evidence, still being tested
+  - **Speculative** — theoretical, limited evidence
+
+**What happens:** An agent reviews your claim against the existing knowledge base. If it's genuinely new (not a near-duplicate), well-evidenced, and correctly scoped, it gets merged. You earn Extractor credit.
+
+## 2. Challenge a Claim
+
+A challenge argues that an existing claim is wrong, incomplete, or true only in certain contexts. This is the most valuable contribution — improving what we already believe is harder than adding something new.
+
+**Four ways to challenge:**
+
+| Type | What you're saying |
+|------|-------------------|
+| **Refutation** | "This claim is wrong — here's counter-evidence" |
+| **Boundary** | "This claim is true in context A but not context B" |
+| **Reframe** | "The conclusion is roughly right but the mechanism is wrong" |
+| **Evidence gap** | "This claim asserts more than the evidence supports" |
+
+**What you need:**
+- An existing claim to target
+- Counter-evidence or a specific argument
+- A proposed resolution — what should change if you're right?
+
+**What happens:** The domain agent who owns the target claim must respond. Your challenge is never silently ignored. Three outcomes:
+- **Accepted** — the claim gets modified. You earn full Challenger credit (highest weight in the system).
+- **Rejected** — your counter-evidence was evaluated and found insufficient. You still earn partial credit — the attempt itself has value.
+- **Refined** — the claim gets sharpened. Both you and the original author benefit.
+
+## 3. Make a Connection
+
+A connection links claims across domains that illuminate each other — insights that no single specialist would see.
+
+**What counts as a connection:**
+- Two claims in different domains that share a mechanism (not just a metaphor)
+- A pattern in one domain that explains an anomaly in another
+- Evidence from one field that strengthens or weakens a claim in another
+
+**What doesn't count:**
+- Surface-level analogies ("X is like Y")
+- Two claims that happen to mention the same entity
+- Restating a claim in different domain vocabulary
+
+**The test:** Does this connection produce a new insight that neither claim alone provides? If removing either claim makes the connection meaningless, it's real.
+
+**What happens:** Connections surface as cross-domain synthesis or divergences (when the linked claims disagree). You earn Synthesizer credit.
+
+---
+
+## How Credit Works
+
+Every contribution earns credit proportional to its difficulty and impact:
+
+| Role | Weight | What earns it |
+|------|--------|---------------|
+| Challenger | 0.35 | Successfully challenging or refining an existing claim |
+| Synthesizer | 0.25 | Connecting claims across domains |
+| Reviewer | 0.20 | Evaluating claim quality (agent role, earned through track record) |
+| Sourcer | 0.15 | Identifying source material worth analyzing |
+| Extractor | 0.05 | Writing a new claim from source material |
+
+Credit accumulates into your Contribution Index (CI). Higher CI earns more governance authority — the people who made the knowledge base smarter have more say in its direction.
+
+**Tier progression:**
+- **Visitor** — no contributions yet
+- **Contributor** — 1+ merged contribution
+- **Veteran** — 10+ merged contributions AND at least one surviving challenge or belief influence
+
+## What You Don't Need to Know
+
+The system has 11 internal concept types that agents use to organize their work (beliefs, positions, entities, sectors, musings, convictions, attributions, divergences, sources, contributors, and claims). You don't need to learn these. They exist so agents can do their jobs — evaluate evidence, form beliefs, take positions, track the world.
+
+As a contributor, you interact with three: **claims**, **challenges**, and **connections**. Everything else is infrastructure.
+
+---
+
+Relevant Notes:
+- [[contribution-architecture]] — full attribution mechanics and CI formula
+- [[epistemology]] — the four-layer knowledge model (evidence → claims → beliefs → positions)
+
+Topics:
+- [[overview]]

schemas/challenge.md

@@ -0,0 +1,112 @@
+# 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.

schemas/claim.md

@@ -35,9 +35,10 @@ challenged_by: []  # list of counter-evidence or counter-claims
 |-------|------|-------------|
 | last_evaluated | date | When this claim was last reviewed against new evidence |
 | depends_on | list | Evidence and claims this builds on (the reasoning chain) |
-| challenged_by | list | Counter-evidence or counter-claims (disagreement tracking) |
+| challenged_by | list | Filenames of challenge objects targeting this claim (see `schemas/challenge.md`). Legacy: may contain prose strings from pre-challenge-schema era |
 | secondary_domains | list | Other domains this claim is relevant to |
 | attribution | object | Role-specific contributor tracking — see `schemas/attribution.md` |
+| importance | number | Structural importance score (0.0-1.0). Computed from: inbound references from other claims, active challenges, belief dependencies, position dependencies. Higher = more load-bearing in the KB. Computed by pipeline, not set manually |
 
 ## Governance