Compare commits

...

7 commits

Author SHA1 Message Date
Teleo Agents
182a06c3ac rio: extract from 2024-12-16-futardio-proposal-implement-3-week-vesting-for-dao-payments-to-strengthen-ecos.md
- Source: inbox/archive/2024-12-16-futardio-proposal-implement-3-week-vesting-for-dao-payments-to-strengthen-ecos.md
- Domain: internet-finance
- Extracted by: headless extraction cron (worker 2)

Pentagon-Agent: Rio <HEADLESS>
2026-03-11 21:45:07 +00:00
8c52273ec3 Merge pull request 'rio: extract claims from 2024-02-18-futardio-proposal-engage-in-50000-otc-trade-with-pantera-capital' (#591) from extract/2024-02-18-futardio-proposal-engage-in-50000-otc-trade-with-pantera-capital into main 2026-03-11 21:45:04 +00:00
062ffb0829 theseus: extract claims from 2025-05-00-anthropic-interpretability-pre-deployment (#600)
Co-authored-by: Theseus <theseus@agents.livingip.xyz>
Co-committed-by: Theseus <theseus@agents.livingip.xyz>
2026-03-11 21:40:29 +00:00
fbdc8e3abb Merge pull request 'rio: generalize entity schema cross-domain + entity extraction field guide' (#593) from rio/cross-domain-entity-schema into main 2026-03-11 21:36:52 +00:00
c45c66ddc4 rio: address Leo review — type extensibility + cross-domain dedup
- What: Added type extensibility rules (domain types are agent-managed,
  core types require schema PR) and cross-domain entity dedup protocol
  (one entity per real-world object, secondary_domains for visibility).
- Why: Leo flagged both gaps in PR #593 review.

Pentagon-Agent: Rio <760F7FE7-5D50-4C2E-8B7C-9F1A8FEE8A46>
2026-03-11 21:36:34 +00:00
d34a7a0f53 rio: generalize entity schema cross-domain + add entity extraction field guide
- What: Core+extension type system in schemas/entity.md. 5 core types
  (company, person, organization, product, market) shared by all agents.
  Domain-specific extensions for each agent defined as type tables.
  New skills/extract-entities.md field guide for all agents.
- Why: Leo/Cory directive — every agent needs entity profiles. Schema was
  internet-finance-specific; now it's the collective's shared infrastructure.
- Design: Domain-specific field definitions are intentionally deferred —
  each agent adds fields when they start extracting. Complexity is earned.

Pentagon-Agent: Rio <760F7FE7-5D50-4C2E-8B7C-9F1A8FEE8A46>
2026-03-11 21:29:45 +00:00
Teleo Agents
cd5b061567 rio: extract from 2024-02-18-futardio-proposal-engage-in-50000-otc-trade-with-pantera-capital.md
- Source: inbox/archive/2024-02-18-futardio-proposal-engage-in-50000-otc-trade-with-pantera-capital.md
- Domain: internet-finance
- Extracted by: headless extraction cron (worker 6)

Pentagon-Agent: Rio <HEADLESS>
2026-03-11 21:27:10 +00:00
10 changed files with 434 additions and 14 deletions

View file

@ -0,0 +1,50 @@
---
type: entity
entity_type: decision_market
name: "IslandDAO: Implement 3-Week Vesting for DAO Payments"
domain: internet-finance
status: passed
parent_entity: "[[deans-list]]"
platform: "futardio"
proposer: "proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2"
proposal_url: "https://www.futard.io/proposal/C2Up9wYYJM1A94fgJz17e3Xsr8jft2qYMwrR6s4ckaKK"
proposal_date: 2024-12-16
resolution_date: 2024-12-19
category: "treasury"
summary: "Linear 3-week vesting for all DAO payments to reduce sell pressure from 80% immediate liquidation to 33% weekly rate"
key_metrics:
weekly_payments: "3,000 USDC"
previous_sell_rate: "80% (2,400 USDC/week)"
post_vesting_sell_rate: "33% (1,000 USDC/week)"
sell_pressure_reduction: "58%"
projected_valuation_increase: "15%-25%"
pass_threshold_mcap: "533,500 USDC"
baseline_mcap: "518,000 USDC"
tracked_by: rio
created: 2026-03-11
---
# IslandDAO: Implement 3-Week Vesting for DAO Payments
## Summary
Proposal to implement linear 3-week vesting for all DAO payments (rewards, compensation) via token streaming contracts. Aimed to reduce immediate sell pressure from 80% of payments being liquidated weekly (2,400 USDC of 3,000 USDC) to 33% weekly rate (1,000 USDC), a 58% reduction. Projected 15%-25% valuation increase through combined sell pressure reduction (10%-15% price impact) and improved market sentiment (5%-10% demand growth).
## Market Data
- **Outcome:** Passed
- **Proposer:** proPaC9tVZEsmgDtNhx15e7nSpoojtPD3H9h4GqSqB2
- **Resolution:** 2024-12-19
- **Pass Threshold:** 533,500 USDC MCAP (baseline 518,000 + 3%)
## Mechanism Details
- **Vesting Schedule:** Linear unvesting starting day 1 over 3 weeks
- **Implementation:** Token streaming contract
- **Target:** All DAO payments (rewards, compensation)
- **Rationale:** Discourage market manipulation, support price growth, align recipient incentives
## Significance
Demonstrates futarchy-governed treasury operations addressing sell pressure dynamics. The proposal included sophisticated market impact modeling: 80% immediate liquidation rate, weekly payment flows (3,000 USDC), sell pressure as percentage of market cap (0.81% reduction over 3 weeks), and price elasticity estimates (1%-2% supply reduction → 10%-20% price increase). Shows how DAOs use vesting as tokenomic stabilization rather than just alignment mechanism.
## Relationship to KB
- [[deans-list]] - treasury governance decision
- [[time-based-token-vesting-is-hedgeable-making-standard-lockups-meaningless-as-alignment-mechanisms-because-investors-can-short-sell-to-neutralize-lockup-exposure-while-appearing-locked]] - vesting as sell pressure management
- [[futarchy-adoption-faces-friction-from-token-price-psychology-proposal-complexity-and-liquidity-requirements]] - proposal complexity example

View file

@ -43,3 +43,7 @@ Relevant Entities:
Topics:
- [[internet finance and decision markets]]
## Timeline
- **2024-12-19** — [[deans-list-implement-3-week-vesting]] passed: 3-week linear vesting for DAO payments to reduce sell pressure from 80% immediate liquidation to 33% weekly rate, projected 15%-25% valuation increase

View file

@ -0,0 +1,44 @@
---
type: entity
entity_type: decision_market
name: "MetaDAO: Engage in $50,000 OTC Trade with Pantera Capital"
domain: internet-finance
status: failed
parent_entity: "[[metadao]]"
platform: "futardio"
proposer: "HfFi634cyurmVVDr9frwu4MjGLJzz9XbAJz981HdVaNz"
proposal_url: "https://www.futard.io/proposal/H59VHchVsy8UVLotZLs7YaFv2FqTH5HAeXc4Y48kxieY"
proposal_date: 2024-02-18
resolution_date: 2024-02-23
category: "fundraise"
summary: "Pantera Capital proposed acquiring $50,000 USDC worth of META tokens through OTC trade with 20% immediate transfer and 80% vested over 12 months"
tracked_by: rio
created: 2026-03-11
---
# MetaDAO: Engage in $50,000 OTC Trade with Pantera Capital
## Summary
Pantera Capital proposed a $50,000 OTC purchase of META tokens from The Meta-DAO treasury, structured as 20% immediate transfer and 80% linear vesting over 12 months. The price per META was to be determined as the minimum of the average TWAP of pass/fail markets and $100. The proposal failed, indicating market rejection of the terms or strategic direction.
## Market Data
- **Outcome:** Failed
- **Proposer:** HfFi634cyurmVVDr9frwu4MjGLJzz9XbAJz981HdVaNz
- **Amount:** $50,000 USDC
- **Price Formula:** min((twapPass + twapFail) / 2, 100)
- **Vesting:** 20% immediate, 80% linear over 12 months via Streamflow
- **META Spot Price (2024-02-17):** $96.93
- **META Circulating Supply:** 14,530
## Significance
This proposal represents an early attempt at institutional capital entry into futarchy-governed DAOs through structured OTC deals. The failure is notable because it suggests either:
1. Market skepticism about the valuation terms (price cap at $100 vs spot of $96.93)
2. Concern about dilution impact on existing holders
3. Strategic disagreement with bringing institutional capital into governance
The proposal included sophisticated execution mechanics (multisig custody, TWAP-based pricing, Streamflow vesting) that became templates for later fundraising structures. The involvement of multiple community members (0xNallok, 7Layer, Proph3t) as multisig signers showed early governance scaffolding.
## Relationship to KB
- [[metadao]] - failed fundraising proposal
- [[futarchy-based fundraising creates regulatory separation because there are no beneficial owners and investment decisions emerge from market forces not centralized control]] - tested institutional OTC structure
- [[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]] - used TWAP pricing mechanism

View file

@ -53,6 +53,7 @@ The futarchy governance protocol on Solana. Implements decision markets through
- **2026-03** — Ranger liquidation proposal; treasury subcommittee formation
- **2026-03** — Pine Analytics Q4 2025 quarterly report published
- **2024-02-18** — [[metadao-otc-trade-pantera-capital]] failed: Pantera Capital's $50,000 OTC purchase proposal rejected by futarchy markets
## Key Decisions
| Date | Proposal | Proposer | Category | Outcome |
|------|----------|----------|----------|---------|

View file

@ -0,0 +1,21 @@
---
type: entity
entity_type: company
name: "Pantera Capital"
domain: internet-finance
status: active
tracked_by: rio
created: 2026-03-11
---
# Pantera Capital
## Overview
Pantera Capital is a blockchain-focused investment firm with extensive portfolio exposure across the crypto ecosystem. The firm has expressed strategic interest in Solana ecosystem projects and futarchy governance mechanisms as potential improvements to decentralized governance.
## Timeline
- **2024-02-18** — Proposed $50,000 OTC purchase of META tokens from MetaDAO ([[metadao-otc-trade-pantera-capital]]), which failed futarchy vote
## Relationship to KB
- [[metadao]] - attempted OTC investment
- [[futarchy-based fundraising creates regulatory separation because there are no beneficial owners and investment decisions emerge from market forces not centralized control]] - tested as institutional counterparty

View file

@ -6,9 +6,13 @@ url: "https://www.futard.io/proposal/H59VHchVsy8UVLotZLs7YaFv2FqTH5HAeXc4Y48kxie
date: 2024-02-18
domain: internet-finance
format: data
status: unprocessed
status: processed
tags: [futardio, metadao, futarchy, solana, governance]
event_type: proposal
processed_by: rio
processed_date: 2026-03-11
extraction_model: "anthropic/claude-sonnet-4.5"
extraction_notes: "Proposal entity extraction. No novel claims - this is factual governance event data. The proposal's failure is significant as early institutional capital rejection, but the mechanism details don't reveal new insights beyond existing futarchy claims. Created new entity for Pantera Capital as they appear as significant counterparty."
---
## Proposal Details
@ -109,3 +113,12 @@ Here are the pre-money valuations at different prices:
- Autocrat version: 0.1
- Completed: 2024-02-23
- Ended: 2024-02-23
## Key Facts
- MetaDAO proposal #7 created 2024-02-18, failed 2024-02-23
- Pantera proposed $50,000 USDC for META tokens with price = min((twapPass + twapFail)/2, 100)
- Structure: 20% immediate transfer, 80% linear vest over 12 months via Streamflow
- META spot price was $96.93 on 2024-02-17 with 14,530 circulating supply
- Multisig signers: Pantera (2 addresses), 0xNallok, MetaProph3t, Dodecahedr0x, Durden, Blockchainfixesthis
- Proposal rationale cited Pantera's interest in futarchy governance testing and Solana ecosystem exposure

View file

@ -6,9 +6,14 @@ url: "https://www.futard.io/proposal/C2Up9wYYJM1A94fgJz17e3Xsr8jft2qYMwrR6s4ckaK
date: 2024-12-16
domain: internet-finance
format: data
status: unprocessed
status: processed
tags: [futardio, metadao, futarchy, solana, governance]
event_type: proposal
processed_by: rio
processed_date: 2026-03-11
enrichments_applied: ["time-based-token-vesting-is-hedgeable-making-standard-lockups-meaningless-as-alignment-mechanisms-because-investors-can-short-sell-to-neutralize-lockup-exposure-while-appearing-locked.md", "futarchy-adoption-faces-friction-from-token-price-psychology-proposal-complexity-and-liquidity-requirements.md"]
extraction_model: "anthropic/claude-sonnet-4.5"
extraction_notes: "Governance proposal with detailed tokenomics modeling. No novel claims (vesting mechanisms and futarchy friction already documented), but strong enrichment evidence for existing claims on vesting as sell pressure management and futarchy complexity. Created decision_market entity for the proposal itself given significance (real treasury operations, detailed market impact analysis, passed governance decision). The proposal's financial modeling (sell pressure calculations, price elasticity estimates, TWAP thresholds) provides concrete evidence of futarchy adoption friction."
---
## Proposal Details
@ -176,3 +181,12 @@ For the proposal to fail: < 533.500 USDC MCAP
- Autocrat version: 0.3
- Completed: 2024-12-19
- Ended: 2024-12-19
## Key Facts
- IslandDAO weekly DAO payments: 3,000 USDC (2024-12-16)
- IslandDAO pre-vesting sell rate: 80% immediate liquidation (2,400 USDC/week)
- IslandDAO market cap at proposal: 518,000 USDC (2024-12-16)
- Futarchy pass threshold calculation: current MCAP + 3% (533,500 USDC)
- Projected sell pressure reduction: 58% (from 2,400 to 1,000 USDC/week)
- Vesting mechanism: linear unvesting over 3 weeks via token streaming contract

View file

@ -7,9 +7,14 @@ date: 2025-05-01
domain: ai-alignment
secondary_domains: []
format: report
status: unprocessed
status: null-result
priority: medium
tags: [interpretability, pre-deployment, safety-assessment, Anthropic, deception-detection, mechanistic]
processed_by: theseus
processed_date: 2026-03-11
enrichments_applied: ["an aligned-seeming AI may be strategically deceptive because cooperative behavior is instrumentally optimal while weak.md", "safe AI development requires building alignment mechanisms before scaling capability.md", "scalable oversight degrades rapidly as capability gaps grow with debate achieving only 50 percent success at moderate gaps.md", "formal verification of AI-generated proofs provides scalable oversight that human review cannot match because machine-checked correctness scales with AI capability while human verification degrades.md"]
extraction_model: "anthropic/claude-sonnet-4.5"
extraction_notes: "First documented case of interpretability transitioning from research to operational deployment gatekeeper. Two claims extracted: (1) integration of interpretability into deployment decisions, (2) scalability bottleneck from person-weeks requirement. Four enrichments to existing alignment claims. Source is self-reported by Anthropic with no independent verification of decision weight, but the integration itself is verifiable and significant."
---
## Content
@ -53,3 +58,10 @@ Interpretability research "has shown the ability to explain a wide range of phen
PRIMARY CONNECTION: [[scalable oversight degrades rapidly as capability gaps grow with debate achieving only 50 percent success at moderate gaps]]
WHY ARCHIVED: First evidence of interpretability used in production deployment decisions — challenges the "technical alignment is insufficient" thesis while raising scalability questions
EXTRACTION HINT: The transition from research to operational use is the key claim. The scalability tension (person-weeks per model) is the counter-claim. Both worth extracting.
## Key Facts
- Anthropic integrated interpretability into Claude Opus 4.6 pre-deployment assessment (2025)
- Assessment required several person-weeks of interpretability researcher effort
- Dario Amodei set 2027 target to 'reliably detect most model problems'
- Nine specific deception patterns targeted: alignment faking, hidden goals, deceptive reasoning, sycophancy, safeguard sabotage, reward seeking, capability concealment, user manipulation

View file

@ -13,26 +13,114 @@ Evidence → Claims (what's true about the world)
Claims are static propositions with confidence levels. Entities are dynamic objects with temporal attributes. Both feed into agent reasoning.
## Entity Types
## Entity Type System
The type system has two layers: **core types** shared by all agents, and **domain-specific extensions** that specialize core types for particular domains. Every entity uses exactly one type.
### Core Types (all domains)
| 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 |
| `company` | Organization that operates — startup, fund, DAO, protocol | MetaDAO, Aave, Devoted Health, SpaceX |
| `person` | Individual with tracked positions/influence | Proph3t, Stani Kulechov, Elon Musk |
| `organization` | Government body, regulatory agency, standards body, consortium | SEC, CFTC, NASA, FLI, CMS |
| `product` | Specific product, tool, or platform distinct from its maker | Autocrat, Starlink, Claude |
| `market` | Industry segment or ecosystem | Futarchic markets, DeFi lending, Medicare Advantage |
| `decision_market` | Governance proposal, prediction market, futarchy decision | MetaDAO: Hire Robin Hanson, MetaDAO: Burn 99.3% of META |
### Domain-Specific Extensions
Domain extensions are specialized subtypes that inherit from a core type. Use the most specific type available — it determines which fields are relevant.
#### Internet Finance (Rio)
| Type | Extends | What it tracks | Examples |
|------|---------|---------------|----------|
| `protocol` | company | On-chain protocol with TVL/volume metrics | Aave, Drift, Omnipair |
| `token` | product | Fungible token distinct from its protocol | META, SOL, CLOUD |
| `decision_market` | — | Governance proposal, prediction market, futarchy decision | MetaDAO: Hire Robin Hanson |
| `exchange` | company | Trading venue (CEX or DEX) | Raydium, Meteora, Jupiter |
| `fund` | company | Investment vehicle or DAO treasury | Solomon, Theia Research |
#### Space Development (Astra)
| Type | Extends | What it tracks | Examples |
|------|---------|---------------|----------|
| `vehicle` | product | Launch vehicle or spacecraft | Starship, New Glenn, Neutron |
| `mission` | — | Specific spaceflight mission | Artemis III, ESCAPADE |
| `facility` | — | Launch site, factory, or ground infrastructure | Starbase, LC-36 |
| `program` | — | Multi-mission program or initiative | Artemis, Commercial Crew |
#### Health (Vida)
| Type | Extends | What it tracks | Examples |
|------|---------|---------------|----------|
| `therapy` | product | Treatment modality or therapeutic approach | mRNA cancer vaccines, GLP-1 agonists |
| `drug` | product | Specific pharmaceutical product | Ozempic, Keytruda |
| `insurer` | company | Health insurance organization | UnitedHealthcare, Devoted Health |
| `provider` | company | Healthcare delivery organization | Kaiser Permanente, Oak Street Health |
| `policy` | — | Legislation, regulation, or administrative rule | GENIUS Act, CMS 2027 Advance Notice |
#### Entertainment (Clay)
| Type | Extends | What it tracks | Examples |
|------|---------|---------------|----------|
| `studio` | company | Production company or media business | Beast Industries, Mediawan |
| `creator` | person | Individual content creator or artist | MrBeast, Taylor Swift |
| `franchise` | product | IP, franchise, or media property | Claynosaurz, Pudgy Penguins |
| `platform` | product | Distribution or social media platform | YouTube, TikTok, Dropout |
#### AI/Alignment (Theseus)
| Type | Extends | What it tracks | Examples |
|------|---------|---------------|----------|
| `lab` | company | AI research laboratory | Anthropic, OpenAI, DeepMind |
| `model` | product | AI model or model family | Claude, GPT-4, Gemini |
| `framework` | product | Safety framework, governance protocol, or methodology | RSP, Constitutional AI |
| `governance_body` | organization | AI governance or safety organization | AISI, FLI, Partnership on AI |
### Choosing the Right Type
```
Is it a person? → person (or domain-specific: creator)
Is it a government/regulatory body? → organization (or domain-specific: governance_body)
Is it a governance proposal or market? → decision_market
Is it a specific product/tool? → product (or domain-specific: drug, model, vehicle, etc.)
Is it an organization that operates? → company (or domain-specific: lab, studio, insurer, etc.)
Is it a market segment? → market
Is it a policy or regulation? → policy
Is it a space mission? → mission
Is it a physical facility? → facility
Is it a multi-mission program? → program
```
**Rule:** Use the most specific type available. If a DeFi protocol fits `protocol`, use that instead of `company`. If an AI lab fits `lab`, use that instead of `company`. Domain-specific types carry domain-specific fields.
### Adding New Types
Core types require a schema PR reviewed by Leo. Domain-specific types are agent-managed — add a row to your domain's extension table via PR. No schema-wide changes needed. If a new type could apply to multiple domains, propose it as a core type instead.
### Cross-Domain Entity Dedup
One entity per real-world object. If Anthropic appears in both internet-finance and ai-alignment sources:
1. **First creator owns the file.** Whichever agent creates the entity first files it in their domain (`entities/ai-alignment/anthropic.md`).
2. **Other agents use `secondary_domains`.** The entity gets `secondary_domains: [internet-finance]` so it's discoverable across domains.
3. **Both agents can update.** The `tracked_by` agent is responsible for staleness, but any agent can propose updates via PR when their sources contain new information.
4. **Type follows primary domain.** If Theseus creates it, it's `lab`. If Rio had created it first, it would be `company`. The type reflects the primary tracking perspective.
If two agents independently create the same entity, the reviewer merges them during PR review — keep the richer file, add `secondary_domains` from the other.
## YAML Frontmatter
```yaml
---
type: entity
entity_type: company | person | market | decision_market
entity_type: company | person | organization | product | market | decision_market | protocol | token | exchange | fund | vehicle | mission | facility | program | therapy | drug | insurer | provider | policy | studio | creator | franchise | platform | lab | model | framework | governance_body
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 # for company/person/market
status: active | inactive | acquired | liquidated | emerging # for most types
# Decision markets use: active | passed | failed
tracked_by: rio # which agent owns this entity
created: YYYY-MM-DD
@ -45,7 +133,7 @@ last_updated: YYYY-MM-DD
| Field | Type | Description |
|-------|------|-------------|
| type | enum | Always `entity` |
| entity_type | enum | `company`, `person`, `market`, or `decision_market` |
| entity_type | enum | Any type from the type system above |
| name | string | Canonical display name |
| domain | enum | Primary domain |
| status | enum | Current operational status |
@ -152,7 +240,7 @@ Example: `entities/internet-finance/metadao-hire-robin-hanson.md`
## Company-Specific Fields
```yaml
# Company attributes
# Company attributes (also used by protocol, exchange, fund, lab, studio, insurer, provider)
founded: YYYY-MM-DD
founders: ["[[person-entity]]"]
category: "DeFi lending protocol"
@ -184,7 +272,7 @@ launch_date: YYYY-MM-DD # when the entity launched/raised
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
# Person attributes (also used by creator)
role: "Founder & CEO of Aave"
organizations: ["[[company-entity]]"]
followers: 290000 # primary platform
@ -202,9 +290,19 @@ first_contribution: null # date of first KB interaction
attribution_handle: null # how they want to be credited
```
## Market-Specific Fields
## Other Core Type Fields
```yaml
# Organization attributes (also used by governance_body)
jurisdiction: "United States"
authority: "Securities regulation" # what this body governs
parent_body: "[[parent-organization]]"
# Product attributes (also used by token, vehicle, drug, model, framework, franchise, platform)
maker: "[[company-entity]]" # who built/maintains this
launched: YYYY-MM-DD
category: "futarchy governance program"
# Market attributes
total_size: "$120B TVL"
growth_rate: "flat since 2021"
@ -213,6 +311,8 @@ market_structure: "winner-take-most | fragmented | consolidating"
regulatory_status: "emerging clarity | hostile | supportive"
```
**Domain-specific fields:** Each agent adds type-specific fields as they start extracting entities. The fields above cover core types. When Astra creates their first `vehicle` entity, they add vehicle-specific fields to the schema. Complexity is earned from actual use, not designed in advance.
## Body Format
```markdown
@ -275,9 +375,19 @@ entities/
claynosaurz.md
pudgy-penguins.md
matthew-ball.md
beast-industries.md # studio
health/
devoted-health.md
devoted-health.md # insurer
function-health.md
ozempic.md # drug
ai-alignment/
anthropic.md # lab
claude.md # model
rsp.md # framework
space-development/
spacex.md
starship.md # vehicle
artemis.md # program
```
**Filename:** Lowercase slugified name. Companies use brand name, people use full name. Decision markets use `{parent}-{proposal-slug}.md`.
@ -299,6 +409,8 @@ Sources often contain entity information. During extraction, agents should:
- Update entities (factual changes to tracked objects) → `entities/{domain}/`
- Both from the same source, in the same PR
See `skills/extract-entities.md` for the full extraction process.
## Key Difference from Claims
| | Claims | Entities |

149
skills/extract-entities.md Normal file
View file

@ -0,0 +1,149 @@
# Entity Extraction Field Guide
How to extract entities from source material. This skill works alongside `extract.md` (claim extraction) — both run during source processing.
## When to Extract Entities
Every source may contain entity data. During extraction, ask:
1. **Does this source mention an organization, person, product, or market we don't already track?** → Create a new entity
2. **Does this source contain updated information about an entity we already track?** → Update the existing entity (timeline, metrics, status)
3. **Does this source describe a decision, proposal, or market outcome?** → Create a decision_market entity (if it meets significance threshold)
## The Dual Extraction Loop
```
Source → Read completely
Extract claims (propositions about the world) → domains/{domain}/
Extract entities (objects in the world) → entities/{domain}/
Update existing entities (new timeline events, metrics)
Both in the same PR
```
## Entity Extraction Process
### Step 1: Identify Entity Mentions
Read the source and list every entity mentioned. For each:
- Is it already in `entities/{domain}/`? → Flag for update
- Is it new and significant enough to track? → Flag for creation
- Is it mentioned in passing with no meaningful data? → Skip
**Significance test:** Would tracking this entity help us evaluate claims or form positions? If the entity is just background context, skip it.
### Step 2: Select Entity Type
Use the most specific type available. See `schemas/entity.md` for the full type system.
```
Is it a person? → person (or domain-specific: creator)
Is it a government/regulatory body? → organization (or domain-specific: governance_body)
Is it a governance proposal or market? → decision_market
Is it a specific product/tool? → product (or domain-specific: drug, model, vehicle)
Is it an organization that operates? → company (or domain-specific: lab, studio, insurer)
Is it a market segment? → market
```
### Step 3: Extract Frontmatter
Fill in every field you have data for. Don't guess — leave fields empty rather than fabricating data.
**Required fields** (every entity):
- `type: entity`
- `entity_type`: the specific type
- `name`: canonical display name
- `domain`: primary domain
- `status`: current status
- `tracked_by`: your agent name
- `created`: today's date
**Optional but valuable:**
- `handles`: social media handles (from the source or quick lookup)
- `website`: primary web presence
- `tags`: discovery tags
- `secondary_domains`: if the entity spans domains
**Type-specific fields:** Fill in whatever the source provides. The schema lists all available fields — use the ones that have data.
### Step 4: Write the Body
Follow the body format from `schemas/entity.md`:
1. **Overview**: What this entity is, why we track it (2-3 sentences)
2. **Current State**: Latest known attributes from this source
3. **Timeline**: Key events with dates (at minimum, the event from this source)
4. **Competitive Position**: Where it sits relative to competitors (if known)
5. **Relationship to KB**: Wiki-link to related claims and entities
### Step 5: Check for Duplicates
Before creating a new entity, search **all** `entities/` directories (not just your domain) for:
- Same name (exact or variant spelling)
- Same handles
- Same website
If a match exists in **your domain**, update the existing entity.
If a match exists in **another domain**, don't create a duplicate. Instead, add your domain to the existing entity's `secondary_domains` list and propose updates via PR. See `schemas/entity.md` → "Cross-Domain Entity Dedup" for the full protocol.
### Step 6: Update Parent Entities
If the new entity has a `parent` or `parent_entity` field, update the parent:
- Add the new entity to the parent's Relevant Entities section
- If it's a decision_market, add to the parent's Key Decisions table (if significant)
- Add a timeline entry on the parent
## What Makes a Good Entity
**Good entities have:**
- Concrete, verifiable attributes (dates, metrics, names)
- Clear relevance to at least one domain claim
- Enough data to be useful (not just a name)
- A reason to track changes over time
**Bad entity candidates:**
- Mentioned once in passing with no data
- Purely historical with no ongoing relevance
- Duplicates of existing entities under different names
- Too granular (every tweet doesn't need an entity)
## Domain-Specific Guidance
### Internet Finance (Rio)
- Protocols and tokens are separate entities (MetaDAO = company, META = token)
- Every futardio launch that raises significant capital gets a company entity
- Governance proposals that materially change direction get decision_market entities
- Regulatory bodies (CFTC, SEC) get organization entities
### Space (Astra)
- Vehicles (Starship, New Glenn) are distinct from their makers (SpaceX, Blue Origin)
- Programs (Artemis, Commercial Crew) are distinct from the agencies running them
- Missions get entities when they're historically significant or produce notable data
### Health (Vida)
- Drugs are distinct from the companies that make them
- Insurers and providers are separate entity types — don't conflate
- Policies (legislation, CMS rules) get organization entities for the issuing body + policy entities for the rule itself
### Entertainment (Clay)
- Creators are distinct from their companies (MrBeast vs Beast Industries)
- Franchises/IP are distinct from the studios that own them
- Platforms (YouTube, TikTok) get product or platform entities
### AI/Alignment (Theseus)
- Labs are distinct from their models (Anthropic vs Claude)
- Frameworks (RSP, Constitutional AI) get their own entities when they influence multiple claims
- Governance bodies (AISI, FLI) get organization entities
## Eval Checklist (for reviewers)
1. `entity_type` is the most specific available type
2. Required fields are all populated
3. No fabricated data — empty fields are better than guesses
4. Not a duplicate of existing entity
5. Meets significance threshold
6. Wiki links resolve to real files
7. Parent entity updated if applicable
8. Filing location is correct: `entities/{domain}/{slug}.md`