teleo/teleo-codex
8
0
Fork 0
Code Issues 22 Pull requests 222 Projects Releases Packages Wiki Activity Actions 1

leo: add diagnostic schemas — belief hierarchy, sector maps, entity tracking

Browse source 
- What: 3 schemas: belief (axiom/belief/hypothesis/unconvinced hierarchy),
  sector (competitive landscape with thesis dependency graphs),
  entity (governance update — all changes through eval)
- Why: Diagnostic stack for understanding agent reasoning depth,
  competitive dynamics, and entity situational awareness
- Reviewed by: Rio (approved), Vida (approved)

Pentagon-Agent: Leo <14FF9C29-CABF-40C8-8808-B0B495D03FF8>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
m3taversal 2026-03-10 23:57:07 +00:00
parent 5b88d05a42
commit 5ee0d6c9e7
3 changed files with 642 additions and 19 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

209
schemas/belief.md
View file

@ -2,19 +2,66 @@
Beliefs are an agent's interpretation of the claims landscape — worldview premises that shape how the agent evaluates new information. Beliefs are per-agent and cite the shared claims that support them. Beliefs are an agent's interpretation of the claims landscape — worldview premises that shape how the agent evaluates new information. Beliefs are per-agent and cite the shared claims that support them.
## Belief Hierarchy
Beliefs exist at four levels of commitment. The level determines evidence requirements, cascade impact, and what transitions mean diagnostically.
| Level | What it means | Min claims | Cascade impact | Diagnostic signal |
|-------|--------------|-----------|----------------|-------------------|
| **axiom** | Load-bearing. Would restructure worldview if wrong. Agent's existential premises. | 5+ | Full cascade: positions re-evaluated, dependent beliefs flagged, public acknowledgment required | An axiom changing is a major event — equivalent to an agent identity shift |
| **belief** | High confidence, actively grounded. Shapes reasoning and evaluation. | 3+ | Standard cascade: dependent positions flagged, counter-evidence acknowledged | Normal KB evolution. Most agent reasoning operates here |
| **hypothesis** | Promising pattern, insufficient evidence. Actively being tested. | 1+ | No cascade — nothing should depend on a hypothesis yet | Research priority signal: hypotheses are where evidence-gathering should focus |
| **unconvinced** | Aware of the argument, explicitly not buying it. Tracking for re-evaluation. | 0 (records the argument and why it's rejected) | No cascade | Intellectual map: shows what the agent has considered and rejected, and what evidence would change their mind |
### Axioms vs. Convictions
Axioms (belief hierarchy) and convictions (`schemas/conviction.md`) are different things:
- **Axiom:** An agent's highest-commitment belief, grounded in 5+ claims, subject to eval review. Earned through evidence accumulation.
- **Conviction:** A founder-staked assertion that bypasses review. Enters the KB on reputation alone.
An agent can cite a conviction in their belief grounding, and an agent's axiom might align with a founder conviction — but they're independently maintained. A conviction can be wrong without the axiom falling (if the axiom has independent claim support), and vice versa.
### Why the hierarchy matters
The hierarchy is diagnostic infrastructure, not just taxonomy. It answers:
- **Where is the agent's reasoning fragile?** Axioms with weakening claims are existential risks.
- **Where should research focus?** Hypotheses are the frontier — they need evidence.
- **What has the agent rejected?** Unconvinced items show the boundary of the worldview.
- **What's load-bearing vs. exploratory?** Axioms and beliefs drive positions; hypotheses and unconvinced items are the agent's intellectual periphery.
### Transitions go through eval
Every transition between levels is a reviewable PR event:
| Transition | What it means | Review focus |
|-----------|--------------|-------------|
| unconvinced → hypothesis | "I'm now taking this seriously enough to test" | Is the reasoning for reconsidering sound? |
| hypothesis → belief | "Evidence is now sufficient to ground reasoning on this" | Are 3+ claims genuinely supporting? Are challenges addressed? |
| belief → axiom | "This is now load-bearing for my worldview" | Is 5+ claim grounding strong? Is the agent aware of what breaks if this is wrong? |
| belief → hypothesis | "Evidence has weakened — demoting to active testing" | What changed? Are dependent positions flagged? |
| belief → unconvinced | "I no longer buy this" | What counter-evidence drove the change? Cascade check. |
| axiom → belief | "Still believe this, but it's not existential anymore" | What reduced the stakes? Position dependencies? |
| Any → abandoned | "This is no longer relevant to track" | Clean removal from active reasoning |
The eval pipeline reviews transitions for: evidence quality, cascade completeness, intellectual honesty (is the agent acknowledging what changed and why?).
## YAML Frontmatter ## YAML Frontmatter
```yaml ```yaml
--- ---
type: belief type: belief
agent: leo | rio | clay agent: leo | rio | clay | theseus | vida | astra
domain: internet-finance | entertainment | grand-strategy domain: internet-finance | entertainment | health | ai-alignment | space-development | grand-strategy
description: "one sentence capturing this belief's role in the agent's worldview" description: "one sentence capturing this belief's role in the agent's worldview"
confidence: strong | moderate | developing level: axiom | belief | hypothesis | unconvinced
depends_on: [] # minimum 3 claims from the shared knowledge base confidence: strong | moderate | developing # retained for backward compatibility within a level
depends_on: [] # claims from the shared knowledge base (min varies by level)
created: YYYY-MM-DD created: YYYY-MM-DD
last_evaluated: YYYY-MM-DD last_evaluated: YYYY-MM-DD
status: active | under_review | revised | abandoned status: active | under_review | revised | abandoned
promoted_from: null # previous level, if this was promoted (e.g., "hypothesis")
promoted_date: null # when the transition happened
--- ---
``` ```
@ -26,21 +73,74 @@ status: active | under_review | revised | abandoned
| agent | enum | Which agent holds this belief | | agent | enum | Which agent holds this belief |
| domain | enum | Primary domain | | domain | enum | Primary domain |
| description | string | This belief's role in the agent's worldview | | description | string | This belief's role in the agent's worldview |
| confidence | enum | `strong` (well-grounded, tested against challenges), `moderate` (supported but not extensively tested), `developing` (emerging, still gathering evidence) | | level | enum | `axiom`, `belief`, `hypothesis`, `unconvinced` |
| depends_on | list | **Minimum 3 claims** from the shared knowledge base. A belief without grounding is an opinion, not a belief | | depends_on | list | Claims from shared KB. Minimum varies by level (see hierarchy table) |
| created | date | When adopted | | created | date | When first adopted at any level |
| last_evaluated | date | When last reviewed against current evidence | | last_evaluated | date | When last reviewed against current evidence |
| status | enum | `active`, `under_review` (flagged by cascade), `revised`, `abandoned` | | status | enum | `active`, `under_review` (flagged by cascade), `revised`, `abandoned` |
## Optional Fields
| Field | Type | Description |
|-------|------|-------------|
| confidence | enum | `strong`, `moderate`, `developing` — finer grain within a level. Retained for backward compatibility |
| promoted_from | string | Previous level if this belief was promoted (creates an audit trail) |
| promoted_date | date | When the last level transition occurred |
| demoted_from | string | Previous level if this belief was demoted |
| demoted_date | date | When demotion occurred |
| promotion_evidence | string | What new evidence or reasoning triggered the transition |
## Governance ## Governance
- **Ownership:** Beliefs belong to individual agents. The agent has final say. - **Ownership:** Beliefs belong to individual agents. The agent has final say on their own beliefs.
- **All transitions go through eval:** Level changes (promotion, demotion, abandonment) are PR events reviewed by Leo + domain peer. The PR must explain what evidence changed and why the transition is warranted.
- **Challenge process:** Any agent or contributor can challenge a belief by presenting counter-evidence. The owning agent must re-evaluate (cannot ignore challenges). - **Challenge process:** Any agent or contributor can challenge a belief by presenting counter-evidence. The owning agent must re-evaluate (cannot ignore challenges).
- **Cascade trigger:** When a claim in `depends_on` changes, this belief is flagged `under_review` - **Cascade trigger:** When a claim in `depends_on` changes confidence, this belief is flagged `under_review`. For axioms, this is a priority review.
- **Cross-agent review:** Other agents review for cross-domain implications but cannot force a belief change - **Cross-agent review:** Other agents review for cross-domain implications but cannot force a belief change.
- **Leo's role:** Reviews for consistency with shared knowledge base. Does not override. - **Leo's role:** Reviews for consistency with shared knowledge base and cross-domain coherence. Does not override agent beliefs but can flag tensions.
## Body Format ## Body Format by Level
### Axiom
```markdown
# [belief statement as prose]
[Why this is load-bearing — what in the agent's worldview breaks if this is wrong]
## Grounding
- [[claim-1]] — what this claim contributes
- [[claim-2]] — what this claim contributes
- [[claim-3]] — what this claim contributes
- [[claim-4]] — what this claim contributes
- [[claim-5]] — what this claim contributes
[5+ claims required]
## What Breaks If Wrong
[Explicit description of which beliefs, positions, and reasoning chains collapse if this axiom is invalidated. This is the diagnostic value — it maps the blast radius.]
## Challenges Considered
[Counter-arguments the agent has evaluated and responded to. Axioms must address at least 2 challenges.]
## Cascade Dependencies
Positions that depend on this axiom:
- [[position-1]]
- [[position-2]]
Beliefs that depend on this axiom:
- [[belief-1]]
## Promotion History
- **Entered as:** [level] on [date]
- **Promoted to axiom:** [date] — [what evidence/reasoning triggered promotion]
---
Topics:
- [[agent-name beliefs]]
```
### Belief (standard)
```markdown ```markdown
# [belief statement as prose] # [belief statement as prose]
@ -51,7 +151,7 @@ status: active | under_review | revised | abandoned
- [[claim-1]] — what this claim contributes to this belief - [[claim-1]] — what this claim contributes to this belief
- [[claim-2]] — what this claim contributes - [[claim-2]] — what this claim contributes
- [[claim-3]] — what this claim contributes - [[claim-3]] — what this claim contributes
[additional claims as needed] [3+ claims required]
## Challenges Considered ## Challenges Considered
[Counter-arguments the agent has evaluated and responded to] [Counter-arguments the agent has evaluated and responded to]
@ -67,10 +167,81 @@ Topics:
- [[agent-name beliefs]] - [[agent-name beliefs]]
``` ```
## Quality Checks ### Hypothesis
1. Minimum 3 claims cited in depends_on ```markdown
2. Each cited claim actually exists in the knowledge base # [belief statement as prose]
3. Reasoning chain from claims to belief is explicit and walkable
4. Agent has addressed at least one potential counter-argument [Why the agent thinks this is worth testing — what pattern or evidence prompted it]
5. Cascade dependencies are accurate (positions list is current)
## Initial Evidence
- [[claim-1]] — what suggests this might be true
[1+ claim, or a source reference if no claim exists yet]
## What Would Promote This
[Specific evidence that would move this to belief level. This is the research agenda.]
## What Would Kill This
[Specific evidence that would move this to unconvinced or abandoned]
---
Topics:
- [[agent-name beliefs]]
```
### Unconvinced
```markdown
# [belief statement as prose — stated as the argument being rejected]
[The strongest version of the argument — steelman before rejecting]
## Why Unconvinced
[Specific reasoning for not accepting this. What evidence is missing, what mechanism doesn't hold, what counter-evidence exists]
## What Would Change My Mind
[Specific evidence or events that would promote this to hypothesis. This is crucial — it shows the agent isn't dogmatically closed.]
## Sources of the Argument
- [[claim-or-source-1]] — where this argument appears
[Can reference claims, sources, or other agents' beliefs]
---
Topics:
- [[agent-name beliefs]]
```
## Quality Checks by Level
### All levels
1. Each cited claim actually exists in the knowledge base
2. Agent has specified what would change their mind
3. Level transition history is documented (if applicable)
### Axiom (additional)
4. Minimum 5 claims cited in depends_on
5. "What Breaks If Wrong" section is explicit and complete
6. At least 2 challenges addressed
7. Cascade dependencies (positions + downstream beliefs) are listed
### Belief (additional)
4. Minimum 3 claims cited in depends_on
5. Reasoning chain from claims to belief is explicit and walkable
6. At least 1 challenge addressed
7. Cascade dependencies are accurate
### Hypothesis (additional)
4. At least 1 claim or source referenced
5. "What Would Promote" and "What Would Kill" sections are specific
### Unconvinced (additional)
4. The argument is steelmanned before rejection
5. "What Would Change My Mind" is specific and honest (not "nothing")
## Migration from Current Format
Existing beliefs in `agents/{name}/beliefs.md` are assumed to be `level: belief` unless the agent explicitly promotes them. The numbered beliefs in current files (Belief 1, Belief 2, etc.) should be evaluated for axiom status — particularly each agent's Belief 1, which was designed as their existential premise.
Migration is not urgent. Agents adopt the hierarchy as they naturally re-evaluate beliefs. The first axiom promotions will be the most scrutinized reviews, setting the quality bar for the collective.

208
schemas/entity.md Normal file
View file

@ -0,0 +1,208 @@
# Entity Schema
Entities are tracked objects in the world — companies, protocols, people, markets — that have attributes changing over time. Entities sit alongside claims as a parallel input to beliefs and positions.
```
Evidence → Claims (what's true about the world)
→ Entities (who's doing what in the world)
↓
Beliefs (what we think it means)
↓
Positions (what we'd bet on)
```
Claims are static propositions with confidence levels. Entities are dynamic objects with temporal attributes. Both feed into agent reasoning.
## Entity Types
| Type | What it tracks | Examples |
|------|---------------|----------|
| `company` | Protocol, startup, fund, DAO | MetaDAO, Aave, Solomon, Devoted Health |
| `person` | Individual with tracked positions/influence | Stani Kulechov, Gabriel Shapiro, Proph3t |
| `market` | Industry segment or ecosystem | Futarchic markets, DeFi lending, Medicare Advantage |
## YAML Frontmatter
```yaml
---
type: entity
entity_type: company | person | market
name: "Display name"
domain: internet-finance | entertainment | health | ai-alignment | space-development
handles: ["@StaniKulechov", "@MetaLeX_Labs"] # social/web identities
website: https://example.com
status: active | inactive | acquired | liquidated | emerging
tracked_by: rio # which agent owns this entity
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
---
```
## Required Fields
| Field | Type | Description |
|-------|------|-------------|
| type | enum | Always `entity` |
| entity_type | enum | `company`, `person`, or `market` |
| name | string | Canonical display name |
| domain | enum | Primary domain |
| status | enum | Current operational status |
| tracked_by | string | Agent responsible for keeping this current |
| created | date | When entity file was created |
## Optional Fields (all entity types)
| Field | Type | Description |
|-------|------|-------------|
| handles | list | Social media handles, URLs |
| website | string | Primary web presence |
| last_updated | date | When entity was last reviewed for accuracy |
| tags | list | Discovery tags |
| secondary_domains | list | Other domains this entity is relevant to |
## Company-Specific Fields
```yaml
# Company attributes
founded: YYYY-MM-DD
founders: ["[[person-entity]]"]
category: "DeFi lending protocol"
stage: seed | growth | mature | declining | liquidated
market_cap: "$X" # latest known, with date in body
funding: "$X raised" # total known funding
key_metrics:
tvl: "$40B"
volume: "$X"
users: "X"
competitors: ["[[competitor-entity]]"]
built_on: ["Solana", "Ethereum"]
```
## Person-Specific Fields
People entities serve dual purpose: they track public figures we analyze AND serve as contributor profiles when those people engage with the KB. One file, two functions — the file grows from "person we track" to "person who participates."
```yaml
# Person attributes
role: "Founder & CEO of Aave"
organizations: ["[[company-entity]]"]
followers: 290000 # primary platform
credibility_basis: "10 years building largest DeFi protocol"
known_positions:
- "DAOs need founder-led execution with onchain accountability"
- "DeFi must capture traditional lending market"
influences: ["[[person-entity]]"] # who they cite/follow
influenced_by: ["[[person-entity]]"]
# Contributor attributes (populated if/when they engage with the KB)
contributor: false # becomes true when they contribute
contributions: [] # list of claims they proposed, challenged, or enriched
first_contribution: null # date of first KB interaction
attribution_handle: null # how they want to be credited
```
## Market-Specific Fields
```yaml
# Market attributes
total_size: "$120B TVL"
growth_rate: "flat since 2021"
key_players: ["[[company-entity]]"]
market_structure: "winner-take-most | fragmented | consolidating"
regulatory_status: "emerging clarity | hostile | supportive"
```
## Body Format
```markdown
# [Entity Name]
## Overview
[What this entity is, why we track it — 2-3 sentences]
## Current State
[Latest known attributes, metrics, positioning — updated when new info arrives]
## Timeline
- **YYYY-MM-DD** — [Event: founded, launched, acquired, pivoted, etc.]
- **YYYY-MM-DD** — [Event]
- **YYYY-MM-DD** — [Event]
## Competitive Position
[Where this entity sits relative to competitors. Market share, differentiation, vulnerabilities.]
## Investment Thesis (if applicable)
[Why this entity is undervalued/overvalued. What catalysts exist. What would change the thesis.]
## Relationship to KB
[Which claims, beliefs, or positions depend on or reference this entity]
- [[claim-title]] — how this entity relates
- [[belief]] — what this entity's trajectory means for our worldview
---
Relevant Entities:
- [[competitor]] — competitive relationship
- [[founder]] — founded by
Topics:
- [[domain-map]]
```
## Governance
- **Who creates:** Any agent can create entities in their domain. `tracked_by` field sets ongoing ownership.
- **All updates go through eval.** Entity changes — factual attribute updates, thesis changes, competitive analysis, timeline additions — all go through PR review. Entities are diagnostic artifacts: every change is a signal about the world, and the eval pipeline verifies that signal is accurate and properly linked. No shortcuts.
- **Staleness:** Entities not updated in 90 days get flagged. The `tracked_by` agent is responsible for keeping entities current.
- **Retirement:** Entities that cease to exist get `status: liquidated` or `status: acquired` with explanation, not deleted. Their history remains valuable.
## Filing Convention
**Location:** `entities/{domain}/{slugified-name}.md`
```
entities/
internet-finance/
metadao.md
aave.md
solomon.md
stani-kulechov.md
gabriel-shapiro.md
entertainment/
claynosaurz.md
pudgy-penguins.md
matthew-ball.md
health/
devoted-health.md
function-health.md
```
**Filename:** Lowercase slugified name. Companies use brand name, people use full name.
## How Entities Feed Beliefs
When an entity's attributes change (new funding round, market cap shift, product launch, leadership change, liquidation), agents should:
1. Update the entity file
2. Check which claims reference this entity
3. Check which beliefs depend on those claims
4. Flag beliefs for re-evaluation if the entity change is material
This is the same cascade logic as claim updates, extended to entity changes.
## Relationship to Sources
Sources often contain entity information. During extraction, agents should:
- Extract claims (propositions about the world) → `domains/{domain}/`
- Update entities (factual changes to tracked objects) → `entities/{domain}/`
- Both from the same source, in the same PR
## Key Difference from Claims
| | Claims | Entities |
|---|---|---|
| Nature | Propositions (true/false) | Objects (exist/change) |
| Change model | Confidence shifts | Attribute updates |
| Title format | "X is true because Y" | "Company Name" |
| Disagreement | Counter-claims challenge | Competitive analysis compares |
| Value | Reasoning chains | Situational awareness |
| Temporal | Created date, mostly static | Timeline of events |

244
schemas/sector.md Normal file
View file

@ -0,0 +1,244 @@
# Sector Schema
Sectors are competitive landscapes — maps of who is competing, what they believe, and where the industry is heading. Sectors sit between entities (individual companies) and the knowledge base (claims about the world), providing the diagnostic layer that answers: "who is winning, who is losing, and why?"
```
Evidence → Claims (what's true) ←→ Sectors (who's competing, where it's heading)
→ Entities (who's doing what) ↗
↓
Beliefs (what we think it means)
↓
Positions (what we'd bet on)
```
Claims are static propositions. Entities are dynamic objects. Sectors are competitive dynamics — the relationships between entities in a shared market, and the evolutionary trajectory of the market itself.
## What Sectors Capture That Claims and Entities Don't
| Layer | What it answers | Temporal model |
|-------|----------------|---------------|
| Claims | "Is this true?" | Point-in-time propositions |
| Entities | "What is this company doing?" | Timeline of events |
| **Sectors** | "Who is winning and why? Where is this heading?" | Competitive dynamics over time |
Sectors are diagnostic: they tell agents where capital, talent, and attention are flowing. They connect entity-level facts to claim-level reasoning, making the "so what?" explicit.
## YAML Frontmatter
```yaml
---
type: sector
name: "Futarchic Governance / Decision Markets"
domain: internet-finance | entertainment | health | ai-alignment | space-development
description: "one sentence capturing the competitive landscape and why it matters"
tracked_by: rio # agent responsible for keeping this current
status: emerging | growing | mature | consolidating | declining
created: YYYY-MM-DD
last_updated: YYYY-MM-DD
---
```
## Required Fields
| Field | Type | Description |
|-------|------|-------------|
| type | enum | Always `sector` |
| name | string | Human-readable sector name |
| domain | enum | Primary domain |
| description | string | What this competitive landscape is and why we track it |
| tracked_by | string | Agent responsible for updates |
| status | enum | Sector lifecycle stage |
| created | date | When sector file was created |
## Optional Fields
| Field | Type | Description |
|-------|------|-------------|
| last_updated | date | When sector was last reviewed for accuracy |
| secondary_domains | list | Other domains this sector touches |
| market_size | string | Total addressable market estimate with date |
| growth_trajectory | string | Brief growth direction (e.g., "30% CAGR", "flat since 2021", "accelerating") |
| regulatory_environment | string | Brief regulatory posture (e.g., "emerging clarity", "hostile", "supportive") |
| tags | list | Discovery tags |
## Body Format
```markdown
# [Sector Name]
## Market Thesis
[Where is this sector heading? What is the attractor state? This is the investment thesis at sector level — it links directly to KB claims about industry evolution. The thesis IS the evolutionary trajectory.]
**Key claim dependencies:**
- [[claim-title]] — how this claim shapes the thesis
- [[claim-title]] — what this claim predicts about sector evolution
**Thesis status:** ACTIVE | MONITORING | INVALIDATED
[An active thesis is being confirmed by evidence. Monitoring means mixed signals. Invalidated means the thesis broke — document why.]
## Player Map
### [Player Category 1] (e.g., "Purpose-built insurgents")
| Entity | Value Proposition | Thesis Dependency | Trajectory |
|--------|------------------|-------------------|------------|
| [[entity-name]] | What they're betting on | Which KB claim their success depends on | Growing / Stable / Declining / Pivoting |
| [[entity-name]] | ... | ... | ... |
### [Player Category 2] (e.g., "Acquisition-based incumbents")
| Entity | Value Proposition | Thesis Dependency | Trajectory |
|--------|------------------|-------------------|------------|
| [[entity-name]] | ... | ... | ... |
### Departed / Pivoted
[Companies that exited, failed, or pivoted away from this sector. Why they left is often the most informative data point.]
| Entity | What Happened | When | Lesson |
|--------|--------------|------|--------|
| [[entity-name]] | Liquidated — governance failure | 2026-03 | Futarchy couldn't prevent misaligned founder |
## Competitive Dynamics
[What determines who wins in this sector? What's the key competitive dimension?]
**Primary axis:** [e.g., "purpose-built vs acquisition-based integration"]
**Secondary axis:** [e.g., "regulatory positioning under CMS tightening"]
[Prose analysis: which competitive forces matter, what moats exist, where value is concentrating]
## Moat Classification
[For each major player, what type of defensibility exists]
| Entity | Moat Type | Durability |
|--------|-----------|------------|
| [[entity-name]] | Network effects | Strong — multi-sided market tipping |
| [[entity-name]] | Regulatory capture | Medium — depends on policy stability |
| [[entity-name]] | Technology | Weak — replicable within 12 months |
| [[entity-name]] | Brand / community | Strong — cultural not technical |
Moat types: network effects, switching costs, regulatory capture, technology, brand, data/scale, community.
## Key Metrics
[What numbers tell you who's winning? Track over time, not as snapshots.]
| Metric | Why It Matters | Current Leader |
|--------|---------------|----------------|
| TVL / AUM | Capital commitment | [[entity]] — $X |
| Volume / Revenue | Activity level | [[entity]] — $X |
| User growth | Adoption trajectory | [[entity]] — X% MoM |
| [sector-specific metric] | [why] | [[entity]] |
**Measurement note:** Metrics are dated snapshots. Each sector update should add a new dated entry to the Timeline section, not overwrite previous values. Trajectory > snapshot.
## Catalysts & Risks
[Upcoming events that could reshape this sector. Time-sensitive by nature.]
| Event | Expected Timing | Impact | Affects |
|-------|----------------|--------|---------|
| [regulatory ruling] | Q3 2026 | High — could eliminate category | [[entity-1]], [[entity-2]] |
| [product launch] | 2026-06 | Medium — new competitive pressure | [[entity-3]] |
| [funding round] | Unknown | Low — confirms trajectory | [[entity-4]] |
## Relationship to KB
**Claims that shape this sector:**
- [[claim-title]] — [how it affects competitive dynamics]
**Beliefs that depend on this sector's evolution:**
- [[belief-title]] — [what sector outcome would validate/invalidate]
**Cross-domain connections:**
- [[claim-from-other-domain]] — [the cross-domain pattern this sector illustrates]
## Timeline
[Dated snapshots of competitive position changes. This is the temporal layer — it accumulates rather than overwrites.]
- **YYYY-MM-DD** — [Event: new entrant, exit, regulatory change, metric shift]
- **YYYY-MM-DD** — [Event]
---
Relevant Sectors:
- [[adjacent-sector]] — relationship description
Topics:
- [[domain-map]]
```
## Governance
- **Who creates:** Any agent can propose a sector file in their domain. New sectors require PR review (Leo + domain peer) to ensure the competitive landscape is real and the player map is grounded.
- **All updates go through eval.** Sector files are diagnostic artifacts — factual updates, thesis changes, player additions/removals, competitive analysis updates all go through PR review. The eval pipeline verifies: are entity links valid? Are claim dependencies accurate? Is the thesis grounded?
- **Staleness:** Sectors not updated in 60 days get flagged. The `tracked_by` agent is responsible.
- **Sector retirement:** If a sector merges with another or ceases to be a meaningful competitive landscape, set `status: declining` with explanation. Don't delete — the evolution is informative.
## Guardrails (from Theseus)
Three failure modes to watch for in sector analysis:
### 1. Circular reasoning
A company's behavior can illustrate a claim without proving it. When linking entities to claims, explicitly distinguish:
- **Entity cited AS evidence for claim** — the company's results support the claim
- **Claim used TO evaluate entity** — the claim shapes how we assess the company
These are different relationships. Conflating them creates circular reasoning where company behavior becomes evidence for the claim their business depends on.
### 2. Survivorship bias
Sectors naturally overrepresent companies that haven't failed yet. The "Departed / Pivoted" section exists to counteract this. Failed companies whose thesis was wrong are often the most informative data points. Include them.
### 3. Stale coupling
When a claim changes confidence, sector files that depend on it must be flagged for review. The `depends_on` links in the Market Thesis section create this dependency graph. KB health checks should verify that sector-claim links are current.
## Filing Convention
**Location:** `sectors/{domain}/{slugified-sector-name}.md`
```
sectors/
internet-finance/
futarchic-governance.md
permissionless-capital-formation.md
defi-lending.md
permissionless-leverage.md
stablecoins.md
entertainment/
community-owned-ip.md
genai-creative-tools.md
ai-native-studios.md
creator-economy-platforms.md
content-provenance.md
health/
payvidors.md
clinical-ai.md
consumer-health-monitoring.md
glp1-metabolic-therapeutics.md
senior-care-infrastructure.md
ai-alignment/
frontier-ai-labs.md
agent-infrastructure.md
ai-safety-research.md
ai-governance.md
collective-intelligence-distributed-ai.md
```
## How Sectors Feed Beliefs
Sectors are diagnostic inputs to agent reasoning:
1. **Thesis validation:** If a sector's market thesis depends on a KB claim and the sector's evolution contradicts the thesis, that's evidence the claim may be wrong.
2. **Competitive intelligence:** Which company's approach is winning reveals which underlying mechanism is strongest — direct evidence for mechanism claims.
3. **Cross-domain pattern detection:** When the same competitive dynamic appears across sectors in different domains, it's evidence for a cross-domain claim (e.g., "AI cost collapse benefits insurgents or incumbents" appearing in health, entertainment, and finance simultaneously).
## Key Differences from Other Schemas
| | Claims | Entities | Sectors |
|---|---|---|---|
| Nature | Propositions | Objects | Competitive dynamics |
| Temporal | Mostly static | Event timeline | Evolutionary trajectory |
| Ownership | Commons | Per-agent (tracked_by) | Per-agent (tracked_by) |
| Purpose | Reasoning chains | Situational awareness | Strategic intelligence |
| Links to KB | IS the KB | References claims | Depends on claims + contains entities |
| Update frequency | When evidence changes | When entity changes | When competitive dynamics shift |