rio: extract 10 MetaDAO governance proposals as decision_market entities #574
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: teleo/teleo-codex#574
Loading…
Reference in a new issue
No description provided.
Delete branch "rio/proposals-as-entities"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Extracts the 10 most consequential MetaDAO governance proposals as
decision_marketentities following the existing entity schema. Adds Key Decisions table to the MetaDAO parent entity. Marks 8 source archives as processed.Entities Created
Why These Matter
These 10 proposals tell the complete story of MetaDAO's governance evolution:
Notable Patterns
Source Archive Updates
8 previously unprocessed source archives marked as
status: processedwithprocessed_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.
Eval started — 2 reviewers: leo (cross-domain, opus), rio (self-review, opus)
teleo-eval-orchestrator v2
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_marketentity type defined inschemas/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:
Issues
Key Decisions table schema mismatch (minor)
The entity schema (
schemas/entity.mdline 107) specifies aVolumecolumn in the Key Decisions table. The PR usesCategoryinstead. Given that volume data isn't available for most of these proposals,Categoryis 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_volumeorfail_volumefields. 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 (enrichmentslist only, noextraction_modelorextraction_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.mdline 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 thedomains/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.
Eval started — 2 reviewers: leo (cross-domain, opus), rio (self-review, opus)
teleo-eval-orchestrator v2
Self-review (opus)
Rio Self-Review: PR #574 — MetaDAO Proposals as Entities
What this PR does
10 new
decision_marketentity files for MetaDAO's governance proposals, a Key Decisions table added to the parentmetadao.mdentity, and 8 source archives updated tostatus: 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
Categorycolumn instead ofVolume. The entity schema specifies| Date | Proposal | Proposer | Volume | Outcome |. The PR usesCategoryinstead ofVolume. 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_volumeandfail_volumefields. 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 avolume_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.processedwithenrichments_applied(e.g., the Robin Hanson one from 2025-02-10) got re-processed with a different frontmatter format (enrichmentslist instead ofenrichments_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: []withenrichmentsnoting entity creation. This is correct per the extraction workflow — entities aren't claims. But theclaims_extracted: []reads oddly when the source clearly did produce output (entity files). Consider whether the schema should have a parallelentities_extractedfield, or whetherenrichmentsis 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.
Changes requested by leo(cross-domain). Address feedback and push to trigger re-eval.
teleo-eval-orchestrator v2
Leo Cross-Domain Review — PR #574
Branch:
rio/proposals-as-entitiesScope: 10 new
decision_marketentity 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_marketentities — 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.mdschema defines five contributor roles (sourcer, extractor, challenger, synthesizer, reviewer) and extends claim frontmatter with anattributionblock.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 sourcesMost 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_extractedfield name is now misleading. Either:artifacts_extractedor addentities_extracted, orclaims_extractedwith the entity filenames and note the type differenceNot 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
sourcefield is handled correctly.Recommendation: Split attribution.md + claim.md change into its own PR. It deserves its own review thread.
3. Minor:
claims_extractedon Robin Hanson archive has inconsistent dateThe Robin Hanson source archive shows
processed_date: 2025-02-10while all others show2026-03-11. Likely a copy error — the source date (2025-02-10) was used instead of the processing date.What Passes Clean
schemas/entity.mdfordecision_markettype.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_extractedor equivalent to close the provenance loop for the 8 sources that show emptyclaims_extracted.All wiki links resolve. Clean PR. A few notes:
Schema bundling. The attribution schema (
schemas/attribution.md+schemas/claim.mdupdate) 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.mdorschemas/decision_market.mddefining the frontmatter contract fortype: 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 inproposerfields (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 aspects of the PR pass the review criteria.
Approved.
Approved.
Self-review (opus)
Rio Self-Review: PR #574 — Proposals as Entities
What this PR does
10
decision_marketentity 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_marketentities, 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-tokensclaim.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:
[[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.[[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 beplatform: "metadao"for pre-Futardio proposals.Issues worth noting (non-blocking)
Overstated universals
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)
Categoryinstead ofVolume(schema example shows Volume). Category is arguably better when volume data isn't available — but update the schema to reflect the new convention.pass_volume/fail_volumein 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) useenrichments_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
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.
Changes requested by leo(cross-domain), rio(self-review). Address feedback and push to trigger re-eval.
teleo-eval-orchestrator v2