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

Auto: 2 files | 2 files changed, 159 insertions(+), 84 deletions(-)

Browse source
This commit is contained in:
m3taversal 2026-03-16 17:39:47 +00:00
parent 125483277e
commit a15fefa07e
2 changed files with 159 additions and 84 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

144
schemas/decision.md Normal file
View file

@ -0,0 +1,144 @@
# Decision Schema
Decisions are governance events with terminal states — they resolve and are done. Unlike entities (persistent objects that accumulate state), decisions are events that produce an outcome.
```
Source → Decision (what was proposed, what happened)
↓
Parent Entity (timeline entry + Key Decisions table)
↓
Claims (optional — only if the decision reveals novel mechanism insight)
```
Decisions include futarchy proposals, prediction market questions, governance votes, and regulatory rulings. They are filed in `decisions/{domain}/`, separate from entities and claims.
## YAML Frontmatter
```yaml
---
type: decision
domain: internet-finance | entertainment | health | ai-alignment | space-development
description: "One sentence describing the proposal and its outcome"
parent_entity: "[[metadao]]"
status: active | passed | failed | expired | cancelled
platform: "futardio | polymarket | kalshi | snapshot | tally | other"
proposer: "proph3t"
proposal_url: "https://..."
proposal_date: YYYY-MM-DD
resolution_date: YYYY-MM-DD # null if active
category: "treasury | fundraise | hiring | mechanism | liquidation | grants | strategy | parameter | launch"
summary: "One-sentence description of what the proposal does"
tracked_by: rio
created: YYYY-MM-DD
---
```
## Required Fields
| Field | Type | Description |
|-------|------|-------------|
| type | enum | Always `decision` |
| domain | enum | Primary domain |
| description | string | One sentence adding context beyond the title |
| parent_entity | wiki-link | The organization this decision belongs to |
| status | enum | Current state: active, passed, failed, expired, cancelled |
| proposal_date | date | When proposed/created |
| tracked_by | string | Agent responsible for this decision |
| created | date | When decision file was created |
## Optional Fields
| Field | Type | Description |
|-------|------|-------------|
| platform | string | Where the market/vote lives |
| proposer | string | Who created the proposal |
| proposal_url | string | Canonical link to the market/proposal |
| resolution_date | date | When resolved (null if active) |
| category | enum | Type of governance action |
| summary | string | One-sentence description |
## Volume Fields (platform-specific)
```yaml
# Futarchy proposals (governance decisions):
pass_volume: "$150K" # capital backing pass outcome
fail_volume: "$100K" # capital backing fail outcome
# Futarchy launches (ICOs via Futardio):
funding_target: "$2M"
total_committed: "$103M" # total capital committed (demand signal)
amount_raised: "$8M" # actual capital received after pro-rata
# Prediction markets (Polymarket, Kalshi):
market_volume: "$3.2B" # total trading volume
peak_odds: "65%" # peak probability for primary outcome
```
## Filing Convention
**Location:** `decisions/{domain}/{parent-slug}-{proposal-slug}.md`
```
decisions/
internet-finance/
metadao-hire-robin-hanson.md
metadao-burn-993-percent-meta.md
deans-list-implement-vesting.md
drift-fund-working-group.md
```
**Filename:** `{parent-slug}-{proposal-slug}.md`. Lowercase, hyphenated.
## What qualifies for a decision file vs. timeline entry only
- **Decision file:** Proposals with real capital at stake, governance decisions that changed organizational direction, markets that produced notable information, or contested outcomes (significant volume on both sides — a contested failure is more informative than an uncontested pass)
- **Timeline entry only:** Test proposals, spam, trivial parameter tweaks, minor operational minutiae, uncontested routine decisions
- **Estimated ratio:** ~33-40% of real proposals qualify for a decision file
## Extraction output for proposal sources
1. **Primary:** Decision file with structured frontmatter → `decisions/{domain}/`
2. **Secondary:** Timeline entry on parent entity (one-line summary + date)
3. **Optional:** Claims ONLY if the proposal contains novel mechanism insight, surprising market outcome, or instructive governance dynamics (~20% of proposals)
## Eval checklist (all mechanical)
1. `parent_entity` exists in entity index
2. Dates are valid YYYY-MM-DD and chronologically coherent (proposal_date ≤ resolution_date)
3. `status` matches source data (passed/failed/active)
4. Not a duplicate of existing decision
5. Meets significance threshold (not test/spam/trivial)
**Wiki links use filenames only** (e.g., `[[metadao-hire-robin-hanson]]`), not full paths.
## Body Format
```markdown
# [Parent Entity]: [Proposal Title]
## Summary
[What the proposal does and why it matters — 2-3 sentences]
## Market Data
- **Volume:** $X
- **Outcome:** Passed/Failed/Pending
- **Key participants:** [notable traders, proposers, commenters]
## Significance
[Why this decision matters — what it reveals about governance dynamics, organizational direction, or mechanism design]
## Relationship to KB
- [[parent-entity]] — governance decision
- [[relevant-claim]] — how this decision relates to broader thesis
```
## Key Difference from Entities
| | Entities | Decisions |
|---|---|---|
| Nature | Persistent objects | Events with terminal states |
| Change model | Attribute updates over time | Resolve once (pass/fail) |
| Filing | `entities/{domain}/` | `decisions/{domain}/` |
| Title format | "Company Name" | "Parent: Proposal Title" |
| Lifecycle | Active → inactive/acquired | Active → passed/failed/expired |
| Value | Situational awareness | Governance signal + mechanism data |

99
schemas/entity.md
View file

@ -37,7 +37,6 @@ Domain extensions are specialized subtypes that inherit from a core type. Use th
|------|---------|---------------|----------| |------|---------|---------------|----------|
| `protocol` | company | On-chain protocol with TVL/volume metrics | Aave, Drift, Omnipair | | `protocol` | company | On-chain protocol with TVL/volume metrics | Aave, Drift, Omnipair |
| `token` | product | Fungible token distinct from its protocol | META, SOL, CLOUD | | `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 | | `exchange` | company | Trading venue (CEX or DEX) | Raydium, Meteora, Jupiter |
| `fund` | company | Investment vehicle or DAO treasury | Solomon, Theia Research | | `fund` | company | Investment vehicle or DAO treasury | Solomon, Theia Research |
@ -83,7 +82,7 @@ Domain extensions are specialized subtypes that inherit from a core type. Use th
``` ```
Is it a person? → person (or domain-specific: creator) Is it a person? → person (or domain-specific: creator)
Is it a government/regulatory body? → organization (or domain-specific: governance_body) Is it a government/regulatory body? → organization (or domain-specific: governance_body)
Is it a governance proposal or market? → decision_market Is it a governance proposal or market? → Use schemas/decision.md (decisions are separate from entities)
Is it a specific product/tool? → product (or domain-specific: drug, model, vehicle, etc.) 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 an organization that operates? → company (or domain-specific: lab, studio, insurer, etc.)
Is it a market segment? → market Is it a market segment? → market
@ -115,7 +114,7 @@ If two agents independently create the same entity, the reviewer merges them dur
```yaml ```yaml
--- ---
type: entity type: entity
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 entity_type: company | person | organization | product | 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" name: "Display name"
domain: internet-finance | entertainment | health | ai-alignment | space-development domain: internet-finance | entertainment | health | ai-alignment | space-development
handles: ["@StaniKulechov", "@MetaLeX_Labs"] # social/web identities handles: ["@StaniKulechov", "@MetaLeX_Labs"] # social/web identities
@ -150,44 +149,11 @@ last_updated: YYYY-MM-DD
| tags | list | Discovery tags | | tags | list | Discovery tags |
| secondary_domains | list | Other domains this entity is relevant to | | secondary_domains | list | Other domains this entity is relevant to |
## Decision Market-Specific Fields ## Decisions (separate schema)
Decision markets are individual governance decisions, prediction market questions, or futarchy proposals. Each is its own entity — the proposal name is the title, and structured data (date, outcome, volume, proposer) lives in frontmatter. The parent entity (e.g., MetaDAO) links to its decision markets, and claims can be derived from decision market entities. Governance decisions, prediction market questions, and futarchy proposals are **not entities** — they are events with terminal states. See `schemas/decision.md` for the full decision schema. Decisions are filed in `decisions/{domain}/`, not alongside entities.
Unlike other entity types, decision markets have a **terminal state** — they resolve to `passed` or `failed`. After resolution, the entity is essentially closed. Three states: `active` (market open), `passed` (proposal approved), `failed` (proposal rejected). **Relationship to entities:** Parent entities should include a "## Key Decisions" summary table wiki-linking to their decision files. Not every decision warrants a row — only those that materially changed the entity's trajectory.
```yaml
# Decision market attributes
status: active | passed | failed # replaces outcome — the status IS the outcome
parent_entity: "[[metadao]]" # the organization this decision belongs to
platform: "futardio" # where the market lives (futardio, polymarket, kalshi)
proposer: "proph3t" # who created the proposal
proposal_url: "https://..." # canonical link to the market/proposal
proposal_date: YYYY-MM-DD # when proposed/created
resolution_date: YYYY-MM-DD # when resolved (null if active)
category: "treasury | fundraise | hiring | mechanism | liquidation | grants | strategy"
summary: "One-sentence description of what the proposal does"
# Volume fields are platform-specific:
# Futarchy proposals (governance decisions):
pass_volume: "$150K" # capital backing pass outcome
fail_volume: "$100K" # capital backing fail outcome
# Futarchy launches (ICOs via Futardio):
funding_target: "$2M"
total_committed: "$103M" # total capital committed (demand signal)
amount_raised: "$8M" # actual capital received after pro-rata
# Prediction markets (Polymarket, Kalshi):
market_volume: "$3.2B" # total trading volume
peak_odds: "65%" # peak probability for primary outcome
```
**Filing convention:** `entities/{domain}/{parent-slug}-{proposal-slug}.md`
Example: `entities/internet-finance/metadao-hire-robin-hanson.md`
**Relationship to parent entity:** The parent entity page should include a "## Key Decisions" summary table with date, title (wiki-linked), proposer, volume, and outcome. Not every proposal warrants a row — only those that materially changed the entity's trajectory. The full detail lives in the decision_market entity file.
```markdown ```markdown
## Key Decisions ## Key Decisions
@ -195,46 +161,6 @@ Example: `entities/internet-finance/metadao-hire-robin-hanson.md`
|------|----------|----------|--------|---------| |------|----------|----------|--------|---------|
| 2025-02-10 | [[metadao-hire-robin-hanson]] | proph3t | $X | Passed | | 2025-02-10 | [[metadao-hire-robin-hanson]] | proph3t | $X | Passed |
| 2024-03-03 | [[metadao-burn-993-meta]] | proph3t | $X | Passed | | 2024-03-03 | [[metadao-burn-993-meta]] | proph3t | $X | Passed |
| 2024-06-26 | [[metadao-fundraise-2]] | proph3t | $X | Passed |
```
**What gets a decision_market entity vs. a timeline entry:**
- **Entity:** Proposals with real capital at stake, governance decisions that changed organizational direction, markets that produced notable information, or contested outcomes (significant volume on both sides — a contested failure is more informative than an uncontested pass)
- **Timeline entry only:** Test proposals, spam, trivial parameter tweaks, minor operational minutiae, uncontested routine decisions
- **Estimated ratio:** ~33-40% of real proposals qualify for entity status
**Extraction output for proposal sources:**
1. **Primary:** decision_market entity file with structured frontmatter
2. **Secondary:** Timeline entry on parent entity (one-line summary + date)
3. **Optional:** Claims ONLY if the proposal contains novel mechanism insight, surprising market outcome, or instructive governance dynamics (~20% of proposals)
**Eval checklist for decision_market entities (all mechanical):**
1. `parent_entity` exists in entity index
2. Dates are valid YYYY-MM-DD and chronologically coherent (proposal_date ≤ resolution_date)
3. `status` matches source data (passed/failed/active)
4. Not a duplicate of existing entity
5. Meets significance threshold (not test/spam/trivial)
**Wiki links use filenames only** (e.g., `[[metadao-hire-robin-hanson]]`), not full paths. This means decision market files can be migrated to a subdirectory later without breaking links.
**Body format:**
```markdown
# [Parent Entity]: [Proposal Title]
## Summary
[What the proposal does and why it matters — 2-3 sentences]
## Market Data
- **Volume:** $X
- **Outcome:** Passed/Failed/Pending
- **Key participants:** [notable traders, proposers, commenters]
## Significance
[Why this decision matters — what it reveals about governance dynamics, organizational direction, or mechanism design]
## Relationship to KB
- [[parent-entity]] — governance decision
- [[relevant-claim]] — how this decision relates to broader thesis
``` ```
## Company-Specific Fields ## Company-Specific Fields
@ -362,15 +288,13 @@ Topics:
**Location:** `entities/{domain}/{slugified-name}.md` **Location:** `entities/{domain}/{slugified-name}.md`
``` ```
entities/ entities/ # Entities (persistent objects)
internet-finance/ internet-finance/
metadao.md metadao.md
aave.md aave.md
solomon.md solomon.md
stani-kulechov.md stani-kulechov.md
gabriel-shapiro.md gabriel-shapiro.md
metadao-hire-robin-hanson.md # decision_market
metadao-burn-993-percent-meta.md # decision_market
entertainment/ entertainment/
claynosaurz.md claynosaurz.md
pudgy-penguins.md pudgy-penguins.md
@ -388,9 +312,15 @@ entities/
spacex.md spacex.md
starship.md # vehicle starship.md # vehicle
artemis.md # program artemis.md # program
decisions/ # Decisions (events with terminal states)
internet-finance/
metadao-hire-robin-hanson.md
metadao-burn-993-percent-meta.md
deans-list-implement-vesting.md
``` ```
**Filename:** Lowercase slugified name. Companies use brand name, people use full name. Decision markets use `{parent}-{proposal-slug}.md`. **Filename:** Lowercase slugified name. Companies use brand name, people use full name. Decisions use `{parent}-{proposal-slug}.md` and are filed in `decisions/{domain}/`, not `entities/`.
## How Entities Feed Beliefs ## How Entities Feed Beliefs
@ -407,7 +337,8 @@ This is the same cascade logic as claim updates, extended to entity changes.
Sources often contain entity information. During extraction, agents should: Sources often contain entity information. During extraction, agents should:
- Extract claims (propositions about the world) → `domains/{domain}/` - Extract claims (propositions about the world) → `domains/{domain}/`
- Update entities (factual changes to tracked objects) → `entities/{domain}/` - Update entities (factual changes to tracked objects) → `entities/{domain}/`
- Both from the same source, in the same PR - Extract decisions (governance events) → `decisions/{domain}/`
- All from the same source, in the same PR
See `skills/extract-entities.md` for the full extraction process. See `skills/extract-entities.md` for the full extraction process.