Compare commits
7 commits
b13b5eb042
...
182a06c3ac
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
182a06c3ac | ||
| 8c52273ec3 | |||
| 062ffb0829 | |||
| fbdc8e3abb | |||
| c45c66ddc4 | |||
| d34a7a0f53 | |||
|
|
cd5b061567 |
10 changed files with 434 additions and 14 deletions
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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 |
|
||||
|------|----------|----------|----------|---------|
|
||||
|
|
|
|||
21
entities/internet-finance/pantera-capital.md
Normal file
21
entities/internet-finance/pantera-capital.md
Normal 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
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
149
skills/extract-entities.md
Normal 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`
|
||||
Loading…
Reference in a new issue