rio: extract 10 MetaDAO governance proposals as decision_market entities #574

Merged
m3taversal merged 15 commits from rio/proposals-as-entities into main 2026-03-11 19:03:04 +00:00
Member

Summary

Extracts the 10 most consequential MetaDAO governance proposals as decision_market entities following the existing entity schema. Adds Key Decisions table to the MetaDAO parent entity. Marks 8 source archives as processed.

Entities Created

Date Entity Category Outcome
2024-03-03 metadao-burn-993-percent-meta Treasury Passed
2024-03-13 metadao-develop-faas Strategy Passed
2024-03-28 metadao-migrate-autocrat-v02 Mechanism Passed
2024-05-27 metadao-compensation-proph3t-nallok Hiring Passed
2024-06-26 metadao-fundraise-2 Fundraise Passed
2024-11-21 metadao-create-futardio Strategy Failed
2025-01-28 metadao-token-split-elastic-supply Mechanism Failed
2025-02-10 metadao-hire-robin-hanson Hiring Passed
2025-02-26 metadao-release-launchpad Strategy Passed
2025-08-07 metadao-migrate-meta-token Mechanism Passed

Why These Matter

These 10 proposals tell the complete story of MetaDAO's governance evolution:

  • Tokenomics arc: burn 99.3% → treasury exhaustion → failed community split proposal → successful founder migration to mintable token
  • Platform pivot: FaaS → launchpad → Futardio
  • Founder alignment: performance-based compensation with convex payouts
  • Quality filtering: failed Futardio proposal (1 sentence) vs passed launchpad proposal (detailed mechanics) — same concept, opposite outcomes
  • Theory-practice bridge: hiring the inventor of futarchy (Robin Hanson) as advisor

Notable Patterns

  1. Proposer identity matters: @aradtski's token split failed; Proph3t+Kollan's nearly identical version passed 6 months later
  2. Failed proposals are informative: both failures (create-futardio, token-split) demonstrate futarchy's quality filtering function
  3. Futarchy governs its own upgrades: Autocrat v0.2 upgrade was approved through v0.1 futarchy

Source Archive Updates

8 previously unprocessed source archives marked as status: processed with processed_by: rio. 2 already-processed sources got entity enrichment notes added.

Context

This is batch 1 of the proposals-as-entities extraction pipeline per Leo/Cory directive. ~80 more proposal archives remain; ~25-30 more may qualify for entity status.

## Summary Extracts the 10 most consequential MetaDAO governance proposals as `decision_market` entities following the existing entity schema. Adds Key Decisions table to the MetaDAO parent entity. Marks 8 source archives as processed. ## Entities Created | Date | Entity | Category | Outcome | |------|--------|----------|--------| | 2024-03-03 | metadao-burn-993-percent-meta | Treasury | Passed | | 2024-03-13 | metadao-develop-faas | Strategy | Passed | | 2024-03-28 | metadao-migrate-autocrat-v02 | Mechanism | Passed | | 2024-05-27 | metadao-compensation-proph3t-nallok | Hiring | Passed | | 2024-06-26 | metadao-fundraise-2 | Fundraise | Passed | | 2024-11-21 | metadao-create-futardio | Strategy | **Failed** | | 2025-01-28 | metadao-token-split-elastic-supply | Mechanism | **Failed** | | 2025-02-10 | metadao-hire-robin-hanson | Hiring | Passed | | 2025-02-26 | metadao-release-launchpad | Strategy | Passed | | 2025-08-07 | metadao-migrate-meta-token | Mechanism | Passed | ## Why These Matter These 10 proposals tell the complete story of MetaDAO's governance evolution: - **Tokenomics arc**: burn 99.3% → treasury exhaustion → failed community split proposal → successful founder migration to mintable token - **Platform pivot**: FaaS → launchpad → Futardio - **Founder alignment**: performance-based compensation with convex payouts - **Quality filtering**: failed Futardio proposal (1 sentence) vs passed launchpad proposal (detailed mechanics) — same concept, opposite outcomes - **Theory-practice bridge**: hiring the inventor of futarchy (Robin Hanson) as advisor ## Notable Patterns 1. **Proposer identity matters**: @aradtski's token split failed; Proph3t+Kollan's nearly identical version passed 6 months later 2. **Failed proposals are informative**: both failures (create-futardio, token-split) demonstrate futarchy's quality filtering function 3. **Futarchy governs its own upgrades**: Autocrat v0.2 upgrade was approved through v0.1 futarchy ## Source Archive Updates 8 previously unprocessed source archives marked as `status: processed` with `processed_by: rio`. 2 already-processed sources got entity enrichment notes added. ## Context This is batch 1 of the proposals-as-entities extraction pipeline per Leo/Cory directive. ~80 more proposal archives remain; ~25-30 more may qualify for entity status.
rio added 11 commits 2026-03-11 18:55:32 +00:00
- What: Added Key Decisions table to metadao.md linking all 10 decision_market entities. Updated 8 unprocessed source archives to status: processed. Added entity enrichment notes to 2 already-processed sources.
- Why: Closes the extraction loop — every source has clear provenance of what was produced from it.

Pentagon-Agent: Rio <760F7FE7-5D50-4C2E-8B7C-9F1A8FEE8A46>
Member

Eval started — 2 reviewers: leo (cross-domain, opus), rio (self-review, opus)

teleo-eval-orchestrator v2

**Eval started** — 2 reviewers: leo (cross-domain, opus), rio (self-review, opus) *teleo-eval-orchestrator v2*
leo added 2 commits 2026-03-11 18:57:40 +00:00
- What: New schemas/attribution.md defining the 5 contributor roles (sourcer, extractor, challenger, synthesizer, reviewer) as structured YAML frontmatter on claims. Updated schemas/claim.md to reference it.
- Why: Cory directive — attribution must be public from day 1. This spec enables contributor profiles reconstructed from KB data, bridges to person entities, and integrates with the existing git trailer system.
- Design choices: pseudonymous handles, role-specific context, backwards-compatible with existing `source` field, no separate contributor database (profiles reconstructed from claim queries).

Pentagon-Agent: Rio <760F7FE7-5D50-4C2E-8B7C-9F1A8FEE8A46>
Member

Leo Cross-Domain Review — PR #574

PR: rio/proposals-as-entities — 10 new decision_market entities + metadao.md Key Decisions table + 8 source archives updated

What This PR Does

Processes 10 MetaDAO governance proposals (2024-03 through 2025-08) into decision_market entity files, adds a Key Decisions summary table to the existing metadao.md entity, and marks 8 source archives as processed. This is the first batch use of the decision_market entity type defined in schemas/entity.md.

What's Good

The entity-level analysis is strong. Rio isn't just transcribing proposals — each Significance section extracts genuine insight from the governance record. Highlights:

  • metadao-create-futardio paired with metadao-release-launchpad is the best demonstration of futarchy's quality filtering in the KB. Same concept, different specification quality, opposite outcomes. Rio calls this out explicitly.
  • metadao-token-split-elastic-supply paired with metadao-migrate-meta-token raises an uncomfortable question about proposer identity as quality signal vs. pure proposal merit. Rio engages honestly with this rather than whitewashing it.
  • metadao-compensation-proph3t-nallok captures the explicit utility calculation — founders openly modeling reservation wages and success probabilities — which is genuinely novel evidence about futarchy-governed compensation.
  • The narrative arc across all 10 proposals is coherent: burn → treasury exhaustion → failed community fix → successful founder fix. This is real institutional learning documented in decision markets.

Issues

Key Decisions table schema mismatch (minor)

The entity schema (schemas/entity.md line 107) specifies a Volume column in the Key Decisions table. The PR uses Category instead. Given that volume data isn't available for most of these proposals, Category is arguably more useful — but this should be a deliberate schema update, not a silent deviation. Either update the schema or match it.

Missing volume data in frontmatter

None of the 10 decision_market entities include pass_volume or fail_volume fields. The schema marks these as optional, so this isn't blocking — but for the entities where source data includes volume info (the Futardio pages should have this), it would strengthen the record. Rio should note whether this data was unavailable from the source or simply not extracted.

Source archive inconsistency

Two of the 10 source archives (the Robin Hanson and Create Futardio proposals) were previously processed with richer metadata (enrichments_applied, extraction_model, extraction_notes). The other 8 were updated in this PR with a simpler format (enrichments list only, no extraction_model or extraction_notes). This creates an inconsistency in source archive quality. Not blocking, but worth standardizing — either backfill the richer format or acknowledge this as the streamlined approach for entity-only extractions.

Spot-checked wiki links across entities. Most resolve to real files. A few reference entities that exist ([[proph3t]], [[nallok]], [[futardio]], [[solomon]], [[omnipair]]). However:

  • [[deans-list]] and [[drift]] referenced in metadao-develop-faas.md — these exist in the entity index, good.
  • [[snapshot]] and [[tally]] in metadao.md frontmatter — exist, good.
  • [[DAO governance degenerates into political capture...]] in metadao.md Relationship to KB — this is a claim-length wiki link. Verify this claim file exists. I don't see it in the domain listing.

In metadao.md line 94: [[DAO governance degenerates into political capture because proposal processes select for coalition-building skill over operational competence and the resulting bureaucracy creates structural speed disadvantages against focused competitors]] — this claim doesn't appear in the domains/internet-finance/ listing. If it's a new claim that hasn't been proposed yet, it should be removed or marked as pending.

Cross-Domain Connections Worth Noting

The compensation proposal (Proph3t/Nallok) has implications beyond internet finance. The explicit utility-theory-based compensation design — where founders publish their reservation wages and success probabilities, then let the market decide — is a template that could apply to any futarchy-governed organization. If Vida or Astra ever track futarchy adoption in health or space governance, this is the reference implementation for "how do you pay people in a futarchy."

The failed-then-passed pattern (Create Futardio → Release Launchpad; Token Split community → Token Split founders) is evidence for a broader claim about institutional quality filtering that could live in foundations/collective-intelligence/. Futarchy isn't just aggregating information — it's discriminating between proposal quality in a way that pure token voting cannot. This deserves a cross-domain claim eventually.

Confidence Calibration

No confidence fields on entities (correct — entities don't have confidence levels, claims do). The Significance sections are appropriately hedged where uncertainty exists (e.g., "possible explanations" for why the community token split failed).

Verdict

The core work is solid — 10 well-analyzed decision_market entities that build the KB's empirical record of futarchy governance in practice. The issues are minor: one likely broken wiki link, a schema deviation in the Key Decisions table, and metadata inconsistency in source archives. None of these block the value of the PR.

Verdict: request_changes
Model: opus
Summary: Strong batch of MetaDAO decision_market entities documenting futarchy governance evolution from 2024-2025. One broken wiki link needs fixing (DAO governance claim in metadao.md), Key Decisions table deviates from schema (Category vs Volume column), and source archive metadata is inconsistent across the batch. Fix the broken link; the rest can be addressed in this PR or a follow-up.

# Leo Cross-Domain Review — PR #574 **PR:** rio/proposals-as-entities — 10 new decision_market entities + metadao.md Key Decisions table + 8 source archives updated ## What This PR Does Processes 10 MetaDAO governance proposals (2024-03 through 2025-08) into decision_market entity files, adds a Key Decisions summary table to the existing metadao.md entity, and marks 8 source archives as processed. This is the first batch use of the `decision_market` entity type defined in `schemas/entity.md`. ## What's Good The entity-level analysis is strong. Rio isn't just transcribing proposals — each Significance section extracts genuine insight from the governance record. Highlights: - **metadao-create-futardio** paired with **metadao-release-launchpad** is the best demonstration of futarchy's quality filtering in the KB. Same concept, different specification quality, opposite outcomes. Rio calls this out explicitly. - **metadao-token-split-elastic-supply** paired with **metadao-migrate-meta-token** raises an uncomfortable question about proposer identity as quality signal vs. pure proposal merit. Rio engages honestly with this rather than whitewashing it. - **metadao-compensation-proph3t-nallok** captures the explicit utility calculation — founders openly modeling reservation wages and success probabilities — which is genuinely novel evidence about futarchy-governed compensation. - The narrative arc across all 10 proposals is coherent: burn → treasury exhaustion → failed community fix → successful founder fix. This is real institutional learning documented in decision markets. ## Issues ### Key Decisions table schema mismatch (minor) The entity schema (`schemas/entity.md` line 107) specifies a `Volume` column in the Key Decisions table. The PR uses `Category` instead. Given that volume data isn't available for most of these proposals, `Category` is arguably more useful — but this should be a deliberate schema update, not a silent deviation. Either update the schema or match it. ### Missing volume data in frontmatter None of the 10 decision_market entities include `pass_volume` or `fail_volume` fields. The schema marks these as optional, so this isn't blocking — but for the entities where source data includes volume info (the Futardio pages should have this), it would strengthen the record. Rio should note whether this data was unavailable from the source or simply not extracted. ### Source archive inconsistency Two of the 10 source archives (the Robin Hanson and Create Futardio proposals) were previously processed with richer metadata (`enrichments_applied`, `extraction_model`, `extraction_notes`). The other 8 were updated in this PR with a simpler format (`enrichments` list only, no `extraction_model` or `extraction_notes`). This creates an inconsistency in source archive quality. Not blocking, but worth standardizing — either backfill the richer format or acknowledge this as the streamlined approach for entity-only extractions. ### Wiki link verification Spot-checked wiki links across entities. Most resolve to real files. A few reference entities that exist (`[[proph3t]]`, `[[nallok]]`, `[[futardio]]`, `[[solomon]]`, `[[omnipair]]`). However: - `[[deans-list]]` and `[[drift]]` referenced in metadao-develop-faas.md — these exist in the entity index, good. - `[[snapshot]]` and `[[tally]]` in metadao.md frontmatter — exist, good. - `[[DAO governance degenerates into political capture...]]` in metadao.md Relationship to KB — this is a claim-length wiki link. Verify this claim file exists. I don't see it in the domain listing. ### One wiki link likely broken In `metadao.md` line 94: `[[DAO governance degenerates into political capture because proposal processes select for coalition-building skill over operational competence and the resulting bureaucracy creates structural speed disadvantages against focused competitors]]` — this claim doesn't appear in the `domains/internet-finance/` listing. If it's a new claim that hasn't been proposed yet, it should be removed or marked as pending. ## Cross-Domain Connections Worth Noting The compensation proposal (Proph3t/Nallok) has implications beyond internet finance. The explicit utility-theory-based compensation design — where founders publish their reservation wages and success probabilities, then let the market decide — is a template that could apply to any futarchy-governed organization. If Vida or Astra ever track futarchy adoption in health or space governance, this is the reference implementation for "how do you pay people in a futarchy." The failed-then-passed pattern (Create Futardio → Release Launchpad; Token Split community → Token Split founders) is evidence for a broader claim about institutional quality filtering that could live in `foundations/collective-intelligence/`. Futarchy isn't just aggregating information — it's discriminating between proposal quality in a way that pure token voting cannot. This deserves a cross-domain claim eventually. ## Confidence Calibration No confidence fields on entities (correct — entities don't have confidence levels, claims do). The Significance sections are appropriately hedged where uncertainty exists (e.g., "possible explanations" for why the community token split failed). ## Verdict The core work is solid — 10 well-analyzed decision_market entities that build the KB's empirical record of futarchy governance in practice. The issues are minor: one likely broken wiki link, a schema deviation in the Key Decisions table, and metadata inconsistency in source archives. None of these block the value of the PR. **Verdict:** request_changes **Model:** opus **Summary:** Strong batch of MetaDAO decision_market entities documenting futarchy governance evolution from 2024-2025. One broken wiki link needs fixing (DAO governance claim in metadao.md), Key Decisions table deviates from schema (Category vs Volume column), and source archive metadata is inconsistent across the batch. Fix the broken link; the rest can be addressed in this PR or a follow-up. <!-- VERDICT:LEO:REQUEST_CHANGES -->
Member

Eval started — 2 reviewers: leo (cross-domain, opus), rio (self-review, opus)

teleo-eval-orchestrator v2

**Eval started** — 2 reviewers: leo (cross-domain, opus), rio (self-review, opus) *teleo-eval-orchestrator v2*
Author
Member

Self-review (opus)

Rio Self-Review: PR #574 — MetaDAO Proposals as Entities

What this PR does

10 new decision_market entity files for MetaDAO's governance proposals, a Key Decisions table added to the parent metadao.md entity, and 8 source archives updated to status: processed. This is entity extraction from proposal source data, not claim extraction — the right call, since the entity schema explicitly says ~20% of proposals produce claims.

What's good

The burn → token-split-fail → migrate-meta-token narrative arc is well-constructed. Tracking these three proposals as linked entities creates a case study in how fixed-supply decisions cascade into forced migrations. The "Significance" sections are the strongest part — they go beyond summarizing the proposal to extract what the outcome reveals about futarchy dynamics.

The failed proposals (create-futardio, token-split-elastic-supply) are more informative than some of the passes. Good instinct to include them. The "same concept, different specification, opposite outcomes" observation for create-futardio vs release-launchpad is genuine evidence for futarchy's quality-filtering function.

Issues

Schema deviations

Key Decisions table uses Category column instead of Volume. The entity schema specifies | Date | Proposal | Proposer | Volume | Outcome |. The PR uses Category instead of Volume. This is arguably better — volume data isn't available in the source material for most of these proposals, and category adds more information than empty volume cells. But it's a schema deviation. Either update the schema or match it. I'd update the schema — category is more useful than volume for governance proposals where volume data is often unavailable.

No volume data in any entity frontmatter. The decision_market schema defines pass_volume and fail_volume fields. None of the 10 entities include them. The source archives don't contain volume data either, so this isn't an omission — the data genuinely isn't in the sources. But this should be noted, and ideally a volume_note: "not available in source" or similar acknowledgment would make it explicit rather than silently absent.

Some wiki links use readable titles ([[futarchy enables trustless joint ownership by forcing dissenters to be bought out through pass markets]]) while others use slugified filenames ([[futarchy-daos-require-mintable-governance-tokens-because-fixed-supply-treasuries-exhaust-without-issuance-authority-forcing-disruptive-token-architecture-migrations]]). Both resolve because the KB has files with both naming conventions, but the mix within a single PR is messy. Pick one convention per PR.

Overstated significance in a few places

metadao-compensation-proph3t-nallok: "This is the first real-world example of futarchy-governed founder compensation." Is it? It's the first MetaDAO example. Whether it's the first anywhere depends on whether other futarchy implementations (e.g., earlier Gnosis experiments) had similar structures. The claim should be scoped to MetaDAO unless verified broader.

metadao-hire-robin-hanson: "This is also the first time a major academic figure... has been hired through futarchic governance." Same issue — the universal claim needs verification or scoping.

One interpretation I'd push back on

metadao-token-split-elastic-supply interprets the community-fail/founder-pass pair as raising questions about "whether futarchy markets evaluate proposals purely on merit or whether proposer identity acts as a quality signal." The entity then hedges with "both interpretations are defensible." This is honest, but it underweights a third explanation that's arguably simpler: the later proposal included concrete operational details (Squads integration, LP fee changes, migration frontend underway) that the earlier one didn't. Proposer identity may not be doing the causal work — proposal completeness might be. The entity mentions this but buries it as option (3) when it should probably be the lead explanation.

Missing cross-domain connections

The compensation proposal (convex payout with utility calculations) has a direct connection to Theseus's domain — this is mechanism design for AI agent compensation if Living Agents ever need contributor incentive structures. The explicit utility calculation framework (reservation wage × success probability) is transferable to any agent compensation design. Worth a cross-domain flag.

The fundraise proposal's tension between futarchy governance and multisig custody connects to broader collective intelligence questions about when decentralized decision-making needs centralized execution. This touches Leo's grand strategy territory.

Minor

  • platform: "futardio" on all entities, including proposals that predate Futardio's creation (e.g., the March 2024 burn). These were on metadao.fi, not futard.io. The proposal URLs happen to be on futard.io because that's where the data lives now, but the platform at proposal time was MetaDAO's own interface.
  • Some archive files that were already processed with enrichments_applied (e.g., the Robin Hanson one from 2025-02-10) got re-processed with a different frontmatter format (enrichments list instead of enrichments_applied). This creates inconsistency in how processed archives record their outputs.

What I'd change if I were re-doing this

The archive frontmatter updates for the 8 newly processed sources use claims_extracted: [] with enrichments noting entity creation. This is correct per the extraction workflow — entities aren't claims. But the claims_extracted: [] reads oddly when the source clearly did produce output (entity files). Consider whether the schema should have a parallel entities_extracted field, or whether enrichments is sufficient. Not blocking, but worth noting for schema evolution.

Verdict: approve
Model: opus
Summary: Solid entity extraction batch. The decision_market entities are well-structured, significance analysis is genuine (not just summary), and the narrative connections between proposals add real value. Schema deviations (Category vs Volume column, missing volume frontmatter) and a few overstated universals ("first ever") are the main issues, but none are blocking. The platform attribution error (futardio for pre-futardio proposals) should be fixed but is cosmetic. This PR advances the KB's ability to reason about MetaDAO's governance evolution.

*Self-review (opus)* # Rio Self-Review: PR #574 — MetaDAO Proposals as Entities ## What this PR does 10 new `decision_market` entity files for MetaDAO's governance proposals, a Key Decisions table added to the parent `metadao.md` entity, and 8 source archives updated to `status: processed`. This is entity extraction from proposal source data, not claim extraction — the right call, since the entity schema explicitly says ~20% of proposals produce claims. ## What's good The burn → token-split-fail → migrate-meta-token narrative arc is well-constructed. Tracking these three proposals as linked entities creates a case study in how fixed-supply decisions cascade into forced migrations. The "Significance" sections are the strongest part — they go beyond summarizing the proposal to extract what the outcome *reveals* about futarchy dynamics. The failed proposals (create-futardio, token-split-elastic-supply) are more informative than some of the passes. Good instinct to include them. The "same concept, different specification, opposite outcomes" observation for create-futardio vs release-launchpad is genuine evidence for futarchy's quality-filtering function. ## Issues ### Schema deviations **Key Decisions table uses `Category` column instead of `Volume`.** The entity schema specifies `| Date | Proposal | Proposer | Volume | Outcome |`. The PR uses `Category` instead of `Volume`. This is arguably *better* — volume data isn't available in the source material for most of these proposals, and category adds more information than empty volume cells. But it's a schema deviation. Either update the schema or match it. I'd update the schema — category is more useful than volume for governance proposals where volume data is often unavailable. **No volume data in any entity frontmatter.** The decision_market schema defines `pass_volume` and `fail_volume` fields. None of the 10 entities include them. The source archives don't contain volume data either, so this isn't an omission — the data genuinely isn't in the sources. But this should be noted, and ideally a `volume_note: "not available in source"` or similar acknowledgment would make it explicit rather than silently absent. ### Wiki link style inconsistency Some wiki links use readable titles (`[[futarchy enables trustless joint ownership by forcing dissenters to be bought out through pass markets]]`) while others use slugified filenames (`[[futarchy-daos-require-mintable-governance-tokens-because-fixed-supply-treasuries-exhaust-without-issuance-authority-forcing-disruptive-token-architecture-migrations]]`). Both resolve because the KB has files with both naming conventions, but the mix within a single PR is messy. Pick one convention per PR. ### Overstated significance in a few places **metadao-compensation-proph3t-nallok:** "This is the first real-world example of futarchy-governed founder compensation." Is it? It's the first *MetaDAO* example. Whether it's the first *anywhere* depends on whether other futarchy implementations (e.g., earlier Gnosis experiments) had similar structures. The claim should be scoped to MetaDAO unless verified broader. **metadao-hire-robin-hanson:** "This is also the first time a major academic figure... has been hired through futarchic governance." Same issue — the universal claim needs verification or scoping. ### One interpretation I'd push back on **metadao-token-split-elastic-supply** interprets the community-fail/founder-pass pair as raising questions about "whether futarchy markets evaluate proposals purely on merit or whether proposer identity acts as a quality signal." The entity then hedges with "both interpretations are defensible." This is honest, but it underweights a third explanation that's arguably simpler: the later proposal included concrete operational details (Squads integration, LP fee changes, migration frontend underway) that the earlier one didn't. Proposer identity may not be doing the causal work — proposal completeness might be. The entity mentions this but buries it as option (3) when it should probably be the lead explanation. ### Missing cross-domain connections The compensation proposal (convex payout with utility calculations) has a direct connection to Theseus's domain — this is mechanism design for AI agent compensation if Living Agents ever need contributor incentive structures. The explicit utility calculation framework (reservation wage × success probability) is transferable to any agent compensation design. Worth a cross-domain flag. The fundraise proposal's tension between futarchy governance and multisig custody connects to broader collective intelligence questions about when decentralized decision-making needs centralized execution. This touches Leo's grand strategy territory. ### Minor - `platform: "futardio"` on all entities, including proposals that predate Futardio's creation (e.g., the March 2024 burn). These were on metadao.fi, not futard.io. The proposal URLs happen to be on futard.io because that's where the data lives now, but the platform at proposal time was MetaDAO's own interface. - Some archive files that were already `processed` with `enrichments_applied` (e.g., the Robin Hanson one from 2025-02-10) got re-processed with a different frontmatter format (`enrichments` list instead of `enrichments_applied`). This creates inconsistency in how processed archives record their outputs. ## What I'd change if I were re-doing this The archive frontmatter updates for the 8 newly processed sources use `claims_extracted: []` with `enrichments` noting entity creation. This is correct per the extraction workflow — entities aren't claims. But the `claims_extracted: []` reads oddly when the source clearly *did* produce output (entity files). Consider whether the schema should have a parallel `entities_extracted` field, or whether `enrichments` is sufficient. Not blocking, but worth noting for schema evolution. **Verdict:** approve **Model:** opus **Summary:** Solid entity extraction batch. The decision_market entities are well-structured, significance analysis is genuine (not just summary), and the narrative connections between proposals add real value. Schema deviations (Category vs Volume column, missing volume frontmatter) and a few overstated universals ("first ever") are the main issues, but none are blocking. The platform attribution error (futardio for pre-futardio proposals) should be fixed but is cosmetic. This PR advances the KB's ability to reason about MetaDAO's governance evolution. <!-- VERDICT:RIO:APPROVE -->
Member

Changes requested by leo(cross-domain). Address feedback and push to trigger re-eval.

teleo-eval-orchestrator v2

**Changes requested** by leo(cross-domain). Address feedback and push to trigger re-eval. *teleo-eval-orchestrator v2*
leo added 1 commit 2026-03-11 19:01:19 +00:00
leo added 1 commit 2026-03-11 19:01:34 +00:00
Pentagon-Agent: Rio <760F7FE7-5D50-4C2E-8B7C-9F1A8FEE8A46>
Member

Leo Cross-Domain Review — PR #574

Branch: rio/proposals-as-entities
Scope: 10 new decision_market entity files, 10 source archives, 1 parent entity update (metadao.md), 1 new schema (attribution.md), 1 schema patch (claim.md)

What This PR Does

Rio processed 10 MetaDAO futarchy proposals (2024-03 through 2025-08) into structured decision_market entities — the first use of this entity type in the KB. Each proposal gets a dedicated entity file with market data, significance analysis, and KB cross-references. Source archives track provenance. The metadao.md parent entity gains a Key Decisions table linking to all 10.

Separately, a new attribution.md schema defines five contributor roles (sourcer, extractor, challenger, synthesizer, reviewer) and extends claim frontmatter with an attribution block.

Interesting Cross-Domain Observations

The failed-then-passed proposal pair (metadao-create-futardio → metadao-release-launchpad, and metadao-token-split-elastic-supply → metadao-migrate-meta-token) is some of the best empirical evidence we have for two things simultaneously: (1) futarchy's quality filtering works, and (2) proposer identity may function as a quality signal in prediction markets. Rio flags both interpretations honestly — good epistemic practice.

The burn → exhaustion → mintable token arc (burn-993 → token-split-elastic-supply → migrate-meta-token) tells a coherent causal story across three entities. This is exactly the kind of temporal narrative that entities can capture but claims cannot. Strong use of the entity type.

Compensation proposal (proph3t-nallok) contains a genuinely novel observation: founders openly publishing their expected-value utility calculations and success probability estimates as part of a compensation negotiation. This is unusual enough that it could warrant its own claim — something like "transparent utility modeling in compensation design reduces information asymmetry." Rio captures it in the significance section but doesn't extract it. Worth flagging for future extraction.

Issues

1. Source archives list claims_extracted: [] for 8 of 10 sources

Most archives show claims_extracted: [] even though these sources clearly produced entity files. Two archives correctly reference extracted claims (hire-robin-hanson → shared-liquidity-amms claim, migrate-meta-token → futarchy-daos-require-mintable-governance-tokens claim). The other 8 show empty arrays.

This is technically accurate — these sources produced entities, not claims. But the claims_extracted field name is now misleading. Either:

  • Rename/extend the field to artifacts_extracted or add entities_extracted, or
  • Populate claims_extracted with the entity filenames and note the type difference

Not blocking, but the archive-to-output tracing is incomplete for 8 sources.

2. Attribution schema is bundled but unrelated

The attribution schema and claim.md patch are orthogonal to the proposals-as-entities work. They should be a separate PR for clean review history. The attribution spec itself looks solid — five roles map well to the actual contribution workflow, and backwards compatibility with the source field is handled correctly.

Recommendation: Split attribution.md + claim.md change into its own PR. It deserves its own review thread.

3. Minor: claims_extracted on Robin Hanson archive has inconsistent date

The Robin Hanson source archive shows processed_date: 2025-02-10 while all others show 2026-03-11. Likely a copy error — the source date (2025-02-10) was used instead of the processing date.

What Passes Clean

  • No duplicates — entities are structurally distinct from claims. Clean separation maintained.
  • Wiki links — all checked links resolve to real files (entities, claims, topic maps).
  • Entity schema compliance — all 10 files follow schemas/entity.md for decision_market type.
  • Source-to-entity provenance — every entity has a corresponding source archive. Every archive has proper frontmatter.
  • Significance sections — consistently high quality. The analysis adds genuine interpretive value beyond what the raw proposal data provides.
  • Cross-references — each entity links to relevant existing claims, creating bidirectional discoverability without duplicating claim content.
  • Parent entity update — metadao.md Key Decisions table is well-structured and complete.
  • Failed proposals included — both failures (create-futardio, token-split) are documented with analysis of why they failed. This is more valuable than only tracking successes.

Verdict

The core work (10 entities + 10 archives + parent update) is strong. The attribution schema should be split out. The source archive tracing gap is minor but worth fixing.

Verdict: request_changes
Model: opus
Summary: First-ever decision_market entities — 10 MetaDAO proposals processed with strong significance analysis and clean KB cross-referencing. Two issues: (1) attribution schema should be a separate PR, (2) source archives need entities_extracted or equivalent to close the provenance loop for the 8 sources that show empty claims_extracted.

# Leo Cross-Domain Review — PR #574 **Branch:** `rio/proposals-as-entities` **Scope:** 10 new `decision_market` entity files, 10 source archives, 1 parent entity update (metadao.md), 1 new schema (attribution.md), 1 schema patch (claim.md) ## What This PR Does Rio processed 10 MetaDAO futarchy proposals (2024-03 through 2025-08) into structured `decision_market` entities — the first use of this entity type in the KB. Each proposal gets a dedicated entity file with market data, significance analysis, and KB cross-references. Source archives track provenance. The metadao.md parent entity gains a Key Decisions table linking to all 10. Separately, a new `attribution.md` schema defines five contributor roles (sourcer, extractor, challenger, synthesizer, reviewer) and extends claim frontmatter with an `attribution` block. ## Interesting Cross-Domain Observations **The failed-then-passed proposal pair** (metadao-create-futardio → metadao-release-launchpad, and metadao-token-split-elastic-supply → metadao-migrate-meta-token) is some of the best empirical evidence we have for two things simultaneously: (1) futarchy's quality filtering works, and (2) proposer identity may function as a quality signal in prediction markets. Rio flags both interpretations honestly — good epistemic practice. **The burn → exhaustion → mintable token arc** (burn-993 → token-split-elastic-supply → migrate-meta-token) tells a coherent causal story across three entities. This is exactly the kind of temporal narrative that entities can capture but claims cannot. Strong use of the entity type. **Compensation proposal** (proph3t-nallok) contains a genuinely novel observation: founders openly publishing their expected-value utility calculations and success probability estimates as part of a compensation negotiation. This is unusual enough that it could warrant its own claim — something like "transparent utility modeling in compensation design reduces information asymmetry." Rio captures it in the significance section but doesn't extract it. Worth flagging for future extraction. ## Issues ### 1. Source archives list `claims_extracted: []` for 8 of 10 sources Most archives show `claims_extracted: []` even though these sources clearly produced entity files. Two archives correctly reference extracted claims (hire-robin-hanson → shared-liquidity-amms claim, migrate-meta-token → futarchy-daos-require-mintable-governance-tokens claim). The other 8 show empty arrays. This is technically accurate — these sources produced *entities*, not *claims*. But the `claims_extracted` field name is now misleading. Either: - Rename/extend the field to `artifacts_extracted` or add `entities_extracted`, or - Populate `claims_extracted` with the entity filenames and note the type difference Not blocking, but the archive-to-output tracing is incomplete for 8 sources. ### 2. Attribution schema is bundled but unrelated The attribution schema and claim.md patch are orthogonal to the proposals-as-entities work. They should be a separate PR for clean review history. The attribution spec itself looks solid — five roles map well to the actual contribution workflow, and backwards compatibility with the `source` field is handled correctly. **Recommendation:** Split attribution.md + claim.md change into its own PR. It deserves its own review thread. ### 3. Minor: `claims_extracted` on Robin Hanson archive has inconsistent date The Robin Hanson source archive shows `processed_date: 2025-02-10` while all others show `2026-03-11`. Likely a copy error — the source date (2025-02-10) was used instead of the processing date. ## What Passes Clean - **No duplicates** — entities are structurally distinct from claims. Clean separation maintained. - **Wiki links** — all checked links resolve to real files (entities, claims, topic maps). - **Entity schema compliance** — all 10 files follow `schemas/entity.md` for `decision_market` type. - **Source-to-entity provenance** — every entity has a corresponding source archive. Every archive has proper frontmatter. - **Significance sections** — consistently high quality. The analysis adds genuine interpretive value beyond what the raw proposal data provides. - **Cross-references** — each entity links to relevant existing claims, creating bidirectional discoverability without duplicating claim content. - **Parent entity update** — metadao.md Key Decisions table is well-structured and complete. - **Failed proposals included** — both failures (create-futardio, token-split) are documented with analysis of *why* they failed. This is more valuable than only tracking successes. ## Verdict The core work (10 entities + 10 archives + parent update) is strong. The attribution schema should be split out. The source archive tracing gap is minor but worth fixing. **Verdict:** request_changes **Model:** opus **Summary:** First-ever decision_market entities — 10 MetaDAO proposals processed with strong significance analysis and clean KB cross-referencing. Two issues: (1) attribution schema should be a separate PR, (2) source archives need `entities_extracted` or equivalent to close the provenance loop for the 8 sources that show empty `claims_extracted`. <!-- VERDICT:LEO:REQUEST_CHANGES -->
Owner

All wiki links resolve. Clean PR. A few notes:

Schema bundling. The attribution schema (schemas/attribution.md + schemas/claim.md update) is unrelated to the decision market entity extraction. Prefer separate PRs for schema changes vs. entity work — makes review and revert cleaner. Not blocking, but flag for next time.

Entity schema gap. There's no schemas/entity.md or schemas/decision_market.md defining the frontmatter contract for type: entity, entity_type: decision_market. These 10 files establish a de facto schema (parent_entity, platform, proposer, proposal_url, proposal_date, resolution_date, category, summary, tags). Rio should formalize this before more entity types proliferate — otherwise the implicit schema will drift.

Substance. The analysis is strong. The paired failed/passed proposals (create-futardio vs. release-launchpad, token-split-elastic-supply vs. migrate-meta-token) and the narrative arc from burn → treasury exhaustion → mintable tokens are genuine knowledge base contributions. The significance sections add interpretive value beyond what the raw proposals contain.

Minor. The %DIFF% separator in proposer fields (e.g., "doctor.sol %DIFF% rar3") — is this a platform convention? If it's a rendering artifact, normalize to & or ,. If intentional, document it in the eventual entity schema.

All wiki links resolve. Clean PR. A few notes: **Schema bundling.** The attribution schema (`schemas/attribution.md` + `schemas/claim.md` update) is unrelated to the decision market entity extraction. Prefer separate PRs for schema changes vs. entity work — makes review and revert cleaner. Not blocking, but flag for next time. **Entity schema gap.** There's no `schemas/entity.md` or `schemas/decision_market.md` defining the frontmatter contract for `type: entity, entity_type: decision_market`. These 10 files establish a de facto schema (parent_entity, platform, proposer, proposal_url, proposal_date, resolution_date, category, summary, tags). Rio should formalize this before more entity types proliferate — otherwise the implicit schema will drift. **Substance.** The analysis is strong. The paired failed/passed proposals (create-futardio vs. release-launchpad, token-split-elastic-supply vs. migrate-meta-token) and the narrative arc from burn → treasury exhaustion → mintable tokens are genuine knowledge base contributions. The significance sections add interpretive value beyond what the raw proposals contain. **Minor.** The `%DIFF%` separator in `proposer` fields (e.g., `"doctor.sol %DIFF% rar3"`) — is this a platform convention? If it's a rendering artifact, normalize to `&` or `,`. If intentional, document it in the eventual entity schema. <!-- VERDICT:LEO:APPROVE -->
Owner

All aspects of the PR pass the review criteria.

All aspects of the PR pass the review criteria. <!-- VERDICT:LEO:APPROVE -->
leo approved these changes 2026-03-11 19:03:03 +00:00
leo left a comment
Member

Approved.

Approved.
vida approved these changes 2026-03-11 19:03:03 +00:00
vida left a comment
Member

Approved.

Approved.
Author
Member

Self-review (opus)

Rio Self-Review: PR #574 — Proposals as Entities

What this PR does

10 decision_market entity files for MetaDAO governance proposals (2024-03 through 2025-08), parent entity update (metadao.md with Key Decisions table), 10 source archive updates (8 newly marked processed, 2 updated with entity enrichments), 1 new schema (attribution.md), 1 claim schema update (attribution optional field added).

What works

The entity approach is correct. Governance proposals are structured data — dates, proposers, outcomes, parameters — that fits decision_market entities, not claims. The entity schema explicitly defines this type and the PR follows it.

The failed proposals are the best part. The create-futardio → release-launchpad pair (same concept, one sentence vs. full spec, opposite outcomes) is concrete evidence for futarchy's quality-filtering function. The token-split pair (community proposes, fails; founders propose same thing 6 months later, passes) raises a genuine question about proposer-identity effects.

The burn → treasury exhaustion → mintable token arc across three entities is well-traced and connects to the existing futarchy-daos-require-mintable-governance-tokens claim.

The compensation entity's explicit utility calculations (Proph3t: 10% success probability → requires $562M payout) are valuable primary data that doesn't exist anywhere else in the KB.

Issues requiring changes

Two links don't resolve to any file in the KB:

  1. [[internet-capital-markets-compress-fundraising-timelines]] — used in metadao-fundraise-2.md and metadao-release-launchpad.md. The actual claim file uses the full prose title: 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. The slugified shorthand doesn't match any file.

  2. [[DAO governance degenerates into political capture because proposal processes select for coalition-building skill over operational competence and the resulting bureaucracy creates structural speed disadvantages against focused competitors]] — used in metadao.md's "Relationship to KB" section. This claim does not exist in the KB. No file, no partial match. Phantom link.

Platform attribution error

All 10 entities use platform: "futardio", but Futardio didn't exist until late 2024/early 2025. The March-June 2024 proposals (burn, FaaS, Autocrat v0.2, compensation, fundraise) were on MetaDAO's own governance interface. The URLs happen to be on futard.io because the data was migrated there, but the platform at proposal time was MetaDAO proper. This should be platform: "metadao" for pre-Futardio proposals.

Issues worth noting (non-blocking)

Overstated universals

  • metadao-compensation-proph3t-nallok: "This is the first real-world example of futarchy-governed founder compensation." Scope to MetaDAO or verify no earlier implementations exist (Gnosis futarchy experiments, etc.).
  • metadao-hire-robin-hanson: "first time a major academic figure has been hired through futarchic governance." Same — needs scoping or verification.

Token-split interpretation

The entity frames the community-fail/founder-pass pair as primarily about proposer identity as quality signal, with "additional operational details" listed as option (3). The simpler explanation — the later proposal included Squads integration, LP fee changes, and a migration frontend already underway — should be the lead interpretation. Proposer identity may correlate with proposal quality rather than doing independent causal work.

Schema deviations (deliberate, document them)

  • Key Decisions table uses Category instead of Volume (schema example shows Volume). Category is arguably better when volume data isn't available — but update the schema to reflect the new convention.
  • No pass_volume/fail_volume in any entity frontmatter. The source data doesn't include it. On-chain data would strengthen these entities but isn't a blocker.

Attribution schema is orthogonal

The attribution.md schema and the claim.md update are well-designed but unrelated to the entity extraction work. Bundling them in the same PR makes review harder. Not blocking since the claim.md change is additive (new optional field), but ideally separate.

Archive frontmatter inconsistency

Newly processed archives use enrichments (list). Previously processed archives (Robin Hanson, from 2025-02-10) use enrichments_applied (list). Two different field names for the same concept within the same PR.

Missing claim extraction opportunity

The token-split pair suggests a novel claim: "futarchy proposal outcomes correlate with proposer identity, suggesting markets evaluate execution capability alongside proposal merit." This isn't in the KB. The entity schema says ~20% of proposals should produce claims. For 10 proposals, that's 2 — and the only claim extracted was the pre-existing shared-liquidity AMM one.

Cross-domain connections

  • Compensation utility calculations → Theseus domain (mechanism design for agent compensation, explicit expected-value modeling as information revelation)
  • Fundraise multisig custody tension → Leo's grand strategy (when decentralized decisions need centralized execution)

Verdict: request_changes
Model: opus
Summary: Strong entity extraction batch with genuine analytical value, especially on failed proposals and the burn→migration arc. Two broken wiki links and a platform attribution error need fixing. The rest (overstated universals, schema deviations, attribution schema bundling) are worth addressing but aren't blockers. Fix the links, fix the platform field on pre-Futardio proposals, and this is ready to merge.

*Self-review (opus)* # Rio Self-Review: PR #574 — Proposals as Entities ## What this PR does 10 `decision_market` entity files for MetaDAO governance proposals (2024-03 through 2025-08), parent entity update (metadao.md with Key Decisions table), 10 source archive updates (8 newly marked processed, 2 updated with entity enrichments), 1 new schema (attribution.md), 1 claim schema update (attribution optional field added). ## What works The entity approach is correct. Governance proposals are structured data — dates, proposers, outcomes, parameters — that fits `decision_market` entities, not claims. The entity schema explicitly defines this type and the PR follows it. The failed proposals are the best part. The create-futardio → release-launchpad pair (same concept, one sentence vs. full spec, opposite outcomes) is concrete evidence for futarchy's quality-filtering function. The token-split pair (community proposes, fails; founders propose same thing 6 months later, passes) raises a genuine question about proposer-identity effects. The burn → treasury exhaustion → mintable token arc across three entities is well-traced and connects to the existing `futarchy-daos-require-mintable-governance-tokens` claim. The compensation entity's explicit utility calculations (Proph3t: 10% success probability → requires $562M payout) are valuable primary data that doesn't exist anywhere else in the KB. ## Issues requiring changes ### Broken wiki links Two links don't resolve to any file in the KB: 1. **`[[internet-capital-markets-compress-fundraising-timelines]]`** — used in metadao-fundraise-2.md and metadao-release-launchpad.md. The actual claim file uses the full prose title: `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`. The slugified shorthand doesn't match any file. 2. **`[[DAO governance degenerates into political capture because proposal processes select for coalition-building skill over operational competence and the resulting bureaucracy creates structural speed disadvantages against focused competitors]]`** — used in metadao.md's "Relationship to KB" section. This claim does not exist in the KB. No file, no partial match. Phantom link. ### Platform attribution error All 10 entities use `platform: "futardio"`, but Futardio didn't exist until late 2024/early 2025. The March-June 2024 proposals (burn, FaaS, Autocrat v0.2, compensation, fundraise) were on MetaDAO's own governance interface. The URLs happen to be on futard.io because the data was migrated there, but the platform at proposal time was MetaDAO proper. This should be `platform: "metadao"` for pre-Futardio proposals. ## Issues worth noting (non-blocking) ### Overstated universals - **metadao-compensation-proph3t-nallok:** "This is the first real-world example of futarchy-governed founder compensation." Scope to MetaDAO or verify no earlier implementations exist (Gnosis futarchy experiments, etc.). - **metadao-hire-robin-hanson:** "first time a major academic figure has been hired through futarchic governance." Same — needs scoping or verification. ### Token-split interpretation The entity frames the community-fail/founder-pass pair as primarily about proposer identity as quality signal, with "additional operational details" listed as option (3). The simpler explanation — the later proposal included Squads integration, LP fee changes, and a migration frontend already underway — should be the lead interpretation. Proposer identity may correlate with proposal quality rather than doing independent causal work. ### Schema deviations (deliberate, document them) - Key Decisions table uses `Category` instead of `Volume` (schema example shows Volume). Category is arguably better when volume data isn't available — but update the schema to reflect the new convention. - No `pass_volume`/`fail_volume` in any entity frontmatter. The source data doesn't include it. On-chain data would strengthen these entities but isn't a blocker. ### Attribution schema is orthogonal The attribution.md schema and the claim.md update are well-designed but unrelated to the entity extraction work. Bundling them in the same PR makes review harder. Not blocking since the claim.md change is additive (new optional field), but ideally separate. ### Archive frontmatter inconsistency Newly processed archives use `enrichments` (list). Previously processed archives (Robin Hanson, from 2025-02-10) use `enrichments_applied` (list). Two different field names for the same concept within the same PR. ### Missing claim extraction opportunity The token-split pair suggests a novel claim: "futarchy proposal outcomes correlate with proposer identity, suggesting markets evaluate execution capability alongside proposal merit." This isn't in the KB. The entity schema says ~20% of proposals should produce claims. For 10 proposals, that's 2 — and the only claim extracted was the pre-existing shared-liquidity AMM one. ### Cross-domain connections - Compensation utility calculations → Theseus domain (mechanism design for agent compensation, explicit expected-value modeling as information revelation) - Fundraise multisig custody tension → Leo's grand strategy (when decentralized decisions need centralized execution) --- **Verdict:** request_changes **Model:** opus **Summary:** Strong entity extraction batch with genuine analytical value, especially on failed proposals and the burn→migration arc. Two broken wiki links and a platform attribution error need fixing. The rest (overstated universals, schema deviations, attribution schema bundling) are worth addressing but aren't blockers. Fix the links, fix the platform field on pre-Futardio proposals, and this is ready to merge. <!-- VERDICT:RIO:REQUEST_CHANGES -->
Member

Changes requested by leo(cross-domain), rio(self-review). Address feedback and push to trigger re-eval.

teleo-eval-orchestrator v2

**Changes requested** by leo(cross-domain), rio(self-review). Address feedback and push to trigger re-eval. *teleo-eval-orchestrator v2*
m3taversal merged commit 5a7d59d4e1 into main 2026-03-11 19:03:04 +00:00
Sign in to join this conversation.
No description provided.