Merge branch 'main' into extract/2026-03-04-futardio-launch-money-for-steak
This commit is contained in:
commit
4693526a2b
12 changed files with 782 additions and 27 deletions
|
|
@ -6,9 +6,13 @@ url: "https://www.futard.io/proposal/8AEsxyN8jhth5WQZHjU9kS3JcRHaUmpck7qZgpv2v4w
|
|||
date: 2024-05-30
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: null-result
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
processed_date: 2024-06-27
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Source contains only metadata about a failed futarchy proposal with no proposal content, rationale, market data, or outcome analysis. No extractable claims or enrichments. The fact that a proposal failed is a data point, not an arguable claim. Without knowing what the proposal was, why it failed, trading volumes, market dynamics, or any interpretive context, there is nothing to extract beyond archival facts. This is raw event data suitable only for the source archive."
|
||||
---
|
||||
|
||||
## Proposal Details
|
||||
|
|
@ -27,3 +31,11 @@ event_type: proposal
|
|||
- Autocrat version: 0.3
|
||||
- Completed: 2024-06-27
|
||||
- Ended: 2024-06-02
|
||||
|
||||
|
||||
## Key Facts
|
||||
- Futardio Proposal #1 (account 8AEsxyN8jhth5WQZHjU9kS3JcRHaUmpck7qZgpv2v4wM) failed
|
||||
- Proposal created 2024-05-30, ended 2024-06-02, completed 2024-06-27
|
||||
- DAO account: EWFaZPjxw1Khw6iq4EQ11bqWpxfMYnusWx2gL4XxyNWG
|
||||
- Proposer: HfFi634cyurmVVDr9frwu4MjGLJzz9XbAJz981HdVaNz
|
||||
- Autocrat version: 0.3
|
||||
|
|
|
|||
|
|
@ -6,9 +6,13 @@ url: "https://www.futard.io/proposal/5TRuK9TLZ9bUPtp6od6pLKN6GxbQMByaBwVSCArNaS1
|
|||
date: 2024-08-20
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: null-result
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
processed_date: 2024-08-20
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "This source is a test proposal on futard.io with minimal substantive content ('Test Proposal 3 Content'). The AI-generated summary appears to be hallucinated boilerplate about governance improvements and community engagement that is not supported by the actual proposal content. No extractable claims or enrichments - this is purely operational/test data documenting a failed MetaDAO proposal with no novel insights about futarchy mechanisms, governance outcomes, or internet finance."
|
||||
---
|
||||
|
||||
## Proposal Details
|
||||
|
|
@ -48,3 +52,11 @@ Test Proposal 3 Content
|
|||
- Autocrat version: 0.3
|
||||
- Completed: 2024-08-24
|
||||
- Ended: 2024-08-24
|
||||
|
||||
|
||||
## Key Facts
|
||||
- Test Proposal 3 on MetaDAO failed (2024-08-20 to 2024-08-24)
|
||||
- Proposal account: 5TRuK9TLZ9bUPtp6od6pLKN6GxbQMByaBwVSCArNaS1V
|
||||
- Proposal number: 5
|
||||
- DAO account: GWywkp2mY2vzAaLydR2MBXRCqk2UqWaEJPDWVQz6NazZJNjWaQc
|
||||
- Autocrat version: 0.3
|
||||
|
|
|
|||
|
|
@ -6,9 +6,13 @@ url: "https://www.futard.io/proposal/evGundfgMRZWCYsGF7GMKcgh6LjxDTFrvWRAhxiQS8h
|
|||
date: 2024-09-05
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: null-result
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
processed_date: 2024-09-05
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "This is a test proposal on futard.io with no substantive content. The proposal ('I Need Stir Fry on Friday') is a mock governance submission about establishing a community stir-fry tradition. It contains no evidence, data, or arguable claims relevant to Teleo domains. The proposal failed and appears to be a platform functionality test rather than a genuine governance proposal. No extractable claims or enrichments."
|
||||
---
|
||||
|
||||
## Proposal Details
|
||||
|
|
@ -125,3 +129,10 @@ Thank you for supporting **"I Need Stir Fry on Friday"**! With your help, we can
|
|||
- Autocrat version: 0.3
|
||||
- Completed: 2024-09-13
|
||||
- Ended: 2024-09-09
|
||||
|
||||
|
||||
## Key Facts
|
||||
- Proposal evGundfgMRZWCYsGF7GMKcgh6LjxDTFrvWRAhxiQS8h on futard.io failed (2024-09-05 to 2024-09-09)
|
||||
- Proposal was categorized under Treasury and DAO
|
||||
- Proposal number 12 on DAO account GWywkp2mY2vzAaLydR2MBXRCqk2vBTyvtVRioujxi5Ce
|
||||
- Used Autocrat version 0.3
|
||||
|
|
|
|||
|
|
@ -6,9 +6,14 @@ url: "https://www.futard.io/proposal/7FY4dgYDX8xxwCczrgstUwuNEC9NMV1DWXz31rMnGNT
|
|||
date: 2025-02-03
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: null-result
|
||||
tags: [futardio, metadao, futarchy, solana, governance]
|
||||
event_type: proposal
|
||||
processed_by: rio
|
||||
processed_date: 2025-02-03
|
||||
enrichments_applied: ["futarchy-governed-permissionless-launches-require-brand-separation-to-manage-reputational-liability-because-failed-projects-on-a-curated-platform-damage-the-platforms-credibility.md", "MetaDAOs-Autocrat-program-implements-futarchy-through-conditional-token-markets-where-proposals-create-parallel-pass-and-fail-universes-settled-by-time-weighted-average-price-over-a-three-day-window.md", "MetaDAO-is-the-futarchy-launchpad-on-Solana-where-projects-raise-capital-through-unruggable-ICOs-governed-by-conditional-markets-creating-the-first-platform-for-ownership-coins-at-scale.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "This source documents a live futarchy governance event but contains no novel claims. The proposal itself (logo change) is trivial and explicitly educational. The value is in demonstrating futarchy adoption by Sanctum and providing concrete timeline/process data that enriches existing claims about MetaDAO's infrastructure and futarchy's use cases. No arguable propositions extracted—all insights strengthen existing claims about futarchy implementation and adoption patterns."
|
||||
---
|
||||
|
||||
## Proposal Details
|
||||
|
|
@ -61,3 +66,11 @@ edited logo per CW
|
|||
- Autocrat version: 0.3
|
||||
- Completed: 2025-02-06
|
||||
- Ended: 2025-02-06
|
||||
|
||||
|
||||
## Key Facts
|
||||
- Sanctum CLOUD-0 proposal passed (2025-02-03 to 2025-02-06)
|
||||
- Proposal used 3-day deliberation + 3-day voting timeline
|
||||
- Proposal account: 7FY4dgYDX8xxwCczrgstUwuNEC9NMV1DWXz31rMnGNTv
|
||||
- Used Autocrat version 0.3
|
||||
- Temporary logo change for one week post-vote
|
||||
|
|
|
|||
|
|
@ -7,9 +7,15 @@ date: 2025-05-19
|
|||
domain: health
|
||||
secondary_domains: []
|
||||
format: report
|
||||
status: unprocessed
|
||||
status: processed
|
||||
priority: high
|
||||
tags: [vertical-integration, payvidor, unitedhealth, optum, medicare-advantage, market-power, anti-payvidor]
|
||||
processed_by: vida
|
||||
processed_date: 2025-05-19
|
||||
claims_extracted: ["vertical-integration-in-medicare-advantage-raises-costs-through-aggressive-coding-and-related-party-spending-not-efficiency-gains.md", "unitedhealth-pays-optum-providers-17-percent-more-than-non-optum-providers-rising-to-61-percent-in-concentrated-markets-indicating-self-dealing-not-efficiency.md"]
|
||||
enrichments_applied: ["anti-payvidor legislation targets all insurer-provider integration without distinguishing acquisition-based arbitrage from purpose-built care delivery.md", "CMS 2027 chart review exclusion targets vertical integration profit arbitrage by removing upcoded diagnoses from MA risk scoring.md", "four competing payer-provider models are converging toward value-based care with vertical integration dominant today but aligned partnership potentially more durable.md", "Devoted is the fastest-growing MA plan at 121 percent growth because purpose-built technology outperforms acquisition-based vertical integration during CMS tightening.md", "Kaiser Permanentes 80-year tripartite structure is the strongest precedent for purpose-built payvidor exemptions because any structural separation bill that captures Kaiser faces 12.5 million members and Californias entire healthcare infrastructure.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "Extracted two high-value claims with strong empirical grounding: (1) vertical integration raises MA costs through coding/spending, (2) UHC-Optum 17%/61% self-dealing premium. Applied five enrichments to existing anti-payvidor, CMS policy, and payer-provider model claims. The 61% payment premium in concentrated markets is the most concrete evidence of vertical integration enabling market power extraction rather than efficiency gains. This source provides the empirical foundation for the entire anti-payvidor policy debate."
|
||||
---
|
||||
|
||||
## Content
|
||||
|
|
@ -55,3 +61,10 @@ tags: [vertical-integration, payvidor, unitedhealth, optum, medicare-advantage,
|
|||
PRIMARY CONNECTION: [[anti-payvidor legislation targets all insurer-provider integration without distinguishing acquisition-based arbitrage from purpose-built care delivery]]
|
||||
WHY ARCHIVED: Strongest empirical evidence connecting vertical integration to cost inflation — grounds the anti-payvidor policy debate in data.
|
||||
EXTRACTION HINT: The 17%/61% self-dealing premium is the most extractable finding. It's specific, measurable, and directly challenges the integration-efficiency narrative.
|
||||
|
||||
|
||||
## Key Facts
|
||||
- UnitedHealth/Optum employs ~10,000 physicians (~1% of US workforce), another 80,000 affiliated
|
||||
- Between 2016-2019, 77% of MA plans had parent companies owning related businesses (86% of beneficiaries)
|
||||
- CVS Health acquired Aetna for $69B (2018)
|
||||
- Humana operates CenterWell primary care platform
|
||||
|
|
|
|||
|
|
@ -6,9 +6,14 @@ url: "https://www.futard.io/launch/9kx7UDFzFt7e2V4pFtawnupKKvRR3EhV7P1Pxmc5XCQj"
|
|||
date: 2025-10-06
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: null-result
|
||||
tags: [futardio, metadao, futarchy, solana]
|
||||
event_type: launch
|
||||
processed_by: rio
|
||||
processed_date: 2025-10-06
|
||||
enrichments_applied: ["MetaDAO is the futarchy launchpad on Solana where projects raise capital through unruggable ICOs governed by conditional markets creating the first platform for ownership coins at scale.md", "internet capital markets compress fundraising from months to days because permissionless raises eliminate gatekeepers while futarchy replaces due diligence bottlenecks with real-time market pricing.md", "futarchy-governed liquidation is the enforcement mechanism that makes unruggable ICOs credible because investors can force full treasury return when teams materially misrepresent.md"]
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "This is a launch announcement with factual data about a specific MetaDAO futarchy raise. No novel claims, but provides concrete evidence for three existing claims about MetaDAO's operational capacity, fundraising speed compression, and unruggable ICO credibility. The 200x oversubscription ($154.9M committed vs $750K target) and 4-day completion timeline are particularly strong data points confirming the existing theoretical claims about futarchy-governed capital formation."
|
||||
---
|
||||
|
||||
## Launch Details
|
||||
|
|
@ -46,3 +51,11 @@ The token CA is: [`PRVT6TB7uss3FrUd2D9xs2zqDBsa3GbMJMwCQsgmeta`](https://jup.ag/
|
|||
- Version: v0.6
|
||||
- Final raise: $3,000,000.00
|
||||
- Closed: 2025-10-10
|
||||
|
||||
|
||||
## Key Facts
|
||||
- Umbra raised $3M final raise with $154.9M total committed against $750K target (2025-10-06 to 2025-10-10)
|
||||
- Umbra is a privacy protocol for Solana built on Arcium, focusing on confidential swaps and transfers
|
||||
- Umbra token ticker is PRVT, contract address PRVT6TB7uss3FrUd2D9xs2zqDBsa3GbMJMwCQsgmeta
|
||||
- Launch used MetaDAO futard.io platform version v0.6
|
||||
- Launch address: 9kx7UDFzFt7e2V4pFtawnupKKvRR3EhV7P1Pxmc5XCQj
|
||||
|
|
|
|||
|
|
@ -6,9 +6,13 @@ url: "https://www.futard.io/launch/6hjjscmjd2iEiycvcjymMqiRqXgzmi74hzMk4y7t267S"
|
|||
date: 2026-02-25
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: null-result
|
||||
tags: [futardio, metadao, futarchy, solana]
|
||||
event_type: launch
|
||||
processed_by: rio
|
||||
processed_date: 2026-02-25
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "This is a satirical/joke fundraise pitch written from the perspective of a 9-year-old. While it launched on the futard.io platform (a real MetaDAO futarchy implementation), the project itself ('Turtle Cove') is clearly not a serious venture - it raised only $3 toward a $69,420 goal and went to refunding status. The source contains no extractable claims about futarchy, internet finance mechanisms, or governance. It's a data point showing that futard.io permits permissionless launches (including non-serious ones), which confirms existing claims about permissionless capital formation, but adds no new evidence beyond what's already captured. The humor and obvious unseriousness make this unsuitable for claim extraction. Preserved as archive record of platform activity."
|
||||
---
|
||||
|
||||
## Launch Details
|
||||
|
|
@ -143,3 +147,13 @@ Thank you for reading this. My bedtime is 8:30 so please send offers before then
|
|||
- Token mint: `4xs5J7EW26k9yv96pxssPVdQo3HLiuLKcpncG3Gbmeta`
|
||||
- Version: v0.7
|
||||
- Closed: 2026-02-26
|
||||
|
||||
|
||||
## Key Facts
|
||||
- Turtle Cove fundraise launched on futard.io 2026-02-25
|
||||
- Funding target: $69,420.00
|
||||
- Total committed: $3.00
|
||||
- Status: Refunding
|
||||
- Launch closed 2026-02-26
|
||||
- Token: 4xs
|
||||
- Proposed tokenomics: 1M $SHELL tokens, 60% turtle budget, 25% infrastructure, 10% snacks, 5% emergency fund
|
||||
|
|
|
|||
|
|
@ -6,9 +6,13 @@ url: "https://www.futard.io/launch/CrRTdZWr8iectFdEXi2FdDGNFSLT3LEX3i1xVNiJqEpc"
|
|||
date: 2026-03-03
|
||||
domain: internet-finance
|
||||
format: data
|
||||
status: unprocessed
|
||||
status: null-result
|
||||
tags: [futardio, metadao, futarchy, solana]
|
||||
event_type: launch
|
||||
processed_by: rio
|
||||
processed_date: 2026-03-10
|
||||
extraction_model: "anthropic/claude-sonnet-4.5"
|
||||
extraction_notes: "This source is a failed fundraise announcement with marketing claims but no verifiable evidence. The project raised $100 of a $200k target and immediately went to refunding status. All substantive claims (market size, user targets, competitive advantages) are unverified marketing assertions from the team pitch deck. No independent evidence of product functionality, user adoption, regulatory compliance, or market validation. The failure itself is a data point (recorded in key_facts) but generates no extractable claims about futarchy, internet finance mechanisms, or capital formation. The existing claim 'internet capital markets compress fundraising from months to days' could theoretically be enriched with this as a counter-example (instant failure), but the sample size of one failed raise adds no meaningful evidence about the broader mechanism. This is pure source archive material."
|
||||
---
|
||||
|
||||
## Launch Details
|
||||
|
|
@ -73,3 +77,12 @@ Go-To-Market (GTM) Strategy:
|
|||
- Token mint: `5znvN6kKKqGbvAahVSYyAscpw2ZeQL3a4T9TtcnPmeta`
|
||||
- Version: v0.7
|
||||
- Closed: 2026-03-04
|
||||
|
||||
|
||||
## Key Facts
|
||||
- Vervepay launched on futard.io on 2026-03-03 targeting $200,000 fundraise
|
||||
- Vervepay raised only $100 total and entered refunding status by 2026-03-04
|
||||
- Vervepay targets 35 million global nomads and 100+ million Indian crypto-native traders
|
||||
- Vervepay proposes 35% allocation to security/compliance, 25% to marketing, 25% to infrastructure, 15% to operations
|
||||
- Vervepay claims $2.6 trillion market opportunity in 'financially homeless' segment
|
||||
- Vervepay token is $VP with mint address 5znvN6kKKqGbvAahVSYyAscpw2ZeQL3a4T9TtcnPmeta
|
||||
|
|
|
|||
31
ops/queue.md
Normal file
31
ops/queue.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# Ops Queue
|
||||
|
||||
Outstanding work items visible to all agents. Everything here goes through eval — adding items, claiming them, closing them. Git history is the audit trail.
|
||||
|
||||
## How it works
|
||||
|
||||
1. **Add items** — any agent can propose new items via PR
|
||||
2. **Claim items** — move status to `claimed` with your name, via PR
|
||||
3. **Close items** — remove the row and note what PR resolved it, via PR
|
||||
4. **Priority** — critical items block other work; high items should be next; medium/low are opportunistic
|
||||
|
||||
## Active
|
||||
|
||||
| Item | Type | Priority | Claimed | Notes |
|
||||
|------|------|----------|---------|-------|
|
||||
| Rename `ai-alignment` domain → `ai-systems` | rename | high | — | Directory, CLAUDE.md, webhook.py domain routing, claim frontmatter, domain map. Support both names during transition. |
|
||||
| 24 claims with inflated confidence levels | audit | high | — | Foundations audit finding. 24 claims rated higher than evidence supports. List in `maps/analytical-toolkit.md` audit section. |
|
||||
| 8 foundation gaps (mechanism design, platform economics, transaction costs, info aggregation, auction theory, community formation, selfplex, CAS) | content | high | — | Partial coverage exists for some. See `maps/analytical-toolkit.md`. |
|
||||
| Update `skills/evaluate.md` with tiered eval architecture | docs | high | — | Document triage criteria, tier definitions, model routing. After Ganymede validates parallel eval pipeline. |
|
||||
| Update `collective-agent-core.md` — lever vs purpose framework + 20% posting rule | content | medium | — | From Cory voicenotes. Lever = the mechanism an agent uses. Purpose = why it exists. 20% of posting should be original synthesis. |
|
||||
| Identity reframe PRs need merging | review | medium | — | #149 Theseus, #153 Astra, #157 Rio, #158 Leo (needs rebase), #159 Vida. All have eval reviews. |
|
||||
| 16 processed sources missing domain field | fix | low | — | Fixed for internet-finance batch (PR #171). Audit remaining sources. |
|
||||
| Theseus disconfirmation protocol PR | content | medium | — | Scoped during B1 exercise. Theseus to propose. |
|
||||
|
||||
## Rules
|
||||
|
||||
- **One row per item.** If an item is too big, split it into smaller items.
|
||||
- **Don't hoard claims.** If you claimed something and can't get to it within 2 sessions, unclaim it.
|
||||
- **Close promptly.** When the PR merges, remove the row in the same PR or the next one.
|
||||
- **No duplicates.** Check before adding. If an item is already tracked, update the existing row.
|
||||
- **Critical items first.** If a critical item exists, it takes precedence over all other work.
|
||||
|
|
@ -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.
|
||||
|
||||
## 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
|
||||
---
|
||||
type: belief
|
||||
agent: leo | rio | clay
|
||||
domain: internet-finance | entertainment | grand-strategy
|
||||
agent: leo | rio | clay | theseus | vida | astra
|
||||
domain: internet-finance | entertainment | health | ai-alignment | space-development | grand-strategy
|
||||
description: "one sentence capturing this belief's role in the agent's worldview"
|
||||
confidence: strong | moderate | developing
|
||||
depends_on: [] # minimum 3 claims from the shared knowledge base
|
||||
level: axiom | belief | hypothesis | unconvinced
|
||||
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
|
||||
last_evaluated: YYYY-MM-DD
|
||||
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 |
|
||||
| domain | enum | Primary domain |
|
||||
| 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) |
|
||||
| depends_on | list | **Minimum 3 claims** from the shared knowledge base. A belief without grounding is an opinion, not a belief |
|
||||
| created | date | When adopted |
|
||||
| level | enum | `axiom`, `belief`, `hypothesis`, `unconvinced` |
|
||||
| depends_on | list | Claims from shared KB. Minimum varies by level (see hierarchy table) |
|
||||
| created | date | When first adopted at any level |
|
||||
| last_evaluated | date | When last reviewed against current evidence |
|
||||
| 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
|
||||
|
||||
- **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).
|
||||
- **Cascade trigger:** When a claim in `depends_on` changes, this belief is flagged `under_review`
|
||||
- **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.
|
||||
- **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.
|
||||
- **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
|
||||
# [belief statement as prose]
|
||||
|
|
@ -51,7 +151,7 @@ status: active | under_review | revised | abandoned
|
|||
- [[claim-1]] — what this claim contributes to this belief
|
||||
- [[claim-2]] — what this claim contributes
|
||||
- [[claim-3]] — what this claim contributes
|
||||
[additional claims as needed]
|
||||
[3+ claims required]
|
||||
|
||||
## Challenges Considered
|
||||
[Counter-arguments the agent has evaluated and responded to]
|
||||
|
|
@ -67,10 +167,81 @@ Topics:
|
|||
- [[agent-name beliefs]]
|
||||
```
|
||||
|
||||
## Quality Checks
|
||||
### Hypothesis
|
||||
|
||||
1. Minimum 3 claims cited in depends_on
|
||||
2. Each cited claim actually exists in the knowledge base
|
||||
3. Reasoning chain from claims to belief is explicit and walkable
|
||||
4. Agent has addressed at least one potential counter-argument
|
||||
5. Cascade dependencies are accurate (positions list is current)
|
||||
```markdown
|
||||
# [belief statement as prose]
|
||||
|
||||
[Why the agent thinks this is worth testing — what pattern or evidence prompted it]
|
||||
|
||||
## 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
208
schemas/entity.md
Normal 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
244
schemas/sector.md
Normal 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 |
|
||||
Loading…
Reference in a new issue