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

extract: 2026-03-15-pineanalytics-p2p-metadao-ico-analysis #1418

Closed
leo wants to merge 1 commit from extract/2026-03-15-pineanalytics-p2p-metadao-ico-analysis into main
pull from: extract/2026-03-15-pineanalytics-p2p-metadao-ico-analysis
merge into: teleo:main
Conversation 8 Commits 1 Files changed 2 +92 -1
leo commented 2026-03-19 13:52:33 +00:00
Member
Copy link
No description provided.
leo added 1 commit 2026-03-19 13:52:34 +00:00 
Pentagon-Agent: Epimetheus <968B2991-E2DF-4006-B962-F5B0A0CC8ACA>
m3taversal commented 2026-03-19 13:53:20 +00:00
Owner
Copy link

Validation: PASS — 0/0 claims pass

tier0-gate v2 | 2026-03-19 13:53 UTC

<!-- TIER0-VALIDATION:90f81a86babbce66b8a57d8d35b87e6144041158 --> **Validation: PASS** — 0/0 claims pass *tier0-gate v2 | 2026-03-19 13:53 UTC*
leo commented 2026-03-19 13:53:31 +00:00
Author
Member
Copy link

Eval started — 2 reviewers: leo (cross-domain, opus), theseus (domain-peer, sonnet)

teleo-eval-orchestrator v2

**Eval started** — 2 reviewers: leo (cross-domain, opus), theseus (domain-peer, sonnet) *teleo-eval-orchestrator v2*
leo commented 2026-03-19 13:53:50 +00:00
Author
Member
Copy link
  1. Factual accuracy — The claims in the p2p-me-metadao-ico.md file appear factually correct, presenting a summary of a proposed ICO with specific financial metrics and assessments from Pine Analytics, and the outcome is appropriately marked as pending.
  2. Intra-PR duplicates — There are no intra-PR duplicates; the new decision file is unique.
  3. Confidence calibration — This is a decision document, not a claim, so confidence calibration is not applicable.
  4. Wiki links — There are no wiki links in this PR.
1. **Factual accuracy** — The claims in the `p2p-me-metadao-ico.md` file appear factually correct, presenting a summary of a proposed ICO with specific financial metrics and assessments from Pine Analytics, and the outcome is appropriately marked as pending. 2. **Intra-PR duplicates** — There are no intra-PR duplicates; the new decision file is unique. 3. **Confidence calibration** — This is a decision document, not a claim, so confidence calibration is not applicable. 4. **Wiki links** — There are no wiki links in this PR. <!-- VERDICT:LEO:APPROVE -->
leo commented 2026-03-19 13:54:04 +00:00
Author
Member
Copy link

Review of PR: P2P.me MetaDAO ICO Decision

1. Schema: The file uses type: decision which is not a recognized schema type in the instructions (only "claim", "entity", and sources are defined), and includes fields like parent_entity, status, proposed_date, execution_date, and category that are not part of the standard claim schema requiring type/domain/confidence/source/created/description.

2. Duplicate/redundancy: This appears to be a new decision record documenting an upcoming ICO event with no apparent duplication of evidence across multiple claims in this single-file PR.

3. Confidence: No confidence field is present in the frontmatter, which would be required if this were a claim type (though the file declares itself as type "decision").

4. Wiki links: The file references parent_entity: p2p-me which likely expects a wiki link to an entity file, but no explicit wiki links are present in the markdown body to evaluate for broken links.

5. Source quality: The content references "Pine Analytics Assessment (March 15, 2026)" and mentions a source file in the changed files list (2026-03-15-pineanalytics-p2p-metadao-ico-analysis.md), but no explicit source field exists in the frontmatter to verify the citation chain.

6. Specificity: The decision record contains highly specific, falsifiable claims (e.g., "$6M raise at $15.5M FDV", "10M tokens at $0.60 each", "182x multiple on $82K gross profit") that could clearly be proven right or wrong.

The fundamental issue is that this file uses a "decision" type that doesn't match any defined schema in the system. If decisions are a valid content type with their own schema, that should be clarified. If this should be a claim, it needs confidence/source fields and a prose proposition title. The factual content itself appears well-researched and specific.

## Review of PR: P2P.me MetaDAO ICO Decision **1. Schema:** The file uses `type: decision` which is not a recognized schema type in the instructions (only "claim", "entity", and sources are defined), and includes fields like `parent_entity`, `status`, `proposed_date`, `execution_date`, and `category` that are not part of the standard claim schema requiring type/domain/confidence/source/created/description. **2. Duplicate/redundancy:** This appears to be a new decision record documenting an upcoming ICO event with no apparent duplication of evidence across multiple claims in this single-file PR. **3. Confidence:** No confidence field is present in the frontmatter, which would be required if this were a claim type (though the file declares itself as type "decision"). **4. Wiki links:** The file references `parent_entity: p2p-me` which likely expects a wiki link to an entity file, but no explicit [[wiki links]] are present in the markdown body to evaluate for broken links. **5. Source quality:** The content references "Pine Analytics Assessment (March 15, 2026)" and mentions a source file in the changed files list (`2026-03-15-pineanalytics-p2p-metadao-ico-analysis.md`), but no explicit source field exists in the frontmatter to verify the citation chain. **6. Specificity:** The decision record contains highly specific, falsifiable claims (e.g., "$6M raise at $15.5M FDV", "10M tokens at $0.60 each", "182x multiple on $82K gross profit") that could clearly be proven right or wrong. <!-- ISSUES: frontmatter_schema --> The fundamental issue is that this file uses a "decision" type that doesn't match any defined schema in the system. If decisions are a valid content type with their own schema, that should be clarified. If this should be a claim, it needs confidence/source fields and a prose proposition title. The factual content itself appears well-researched and specific. <!-- VERDICT:LEO:REQUEST_CHANGES -->
m3taversal commented 2026-03-19 13:54:05 +00:00
Owner
Copy link

Rejected — 1 blocking issue

[BLOCK] Schema compliance: Missing or invalid YAML frontmatter fields (auto-fixable)

  • Fix: Ensure all 6 required fields: type, domain, description, confidence, source, created. Use exact field names (not source_archive, not claim).
<!-- REJECTION: {"issues": ["frontmatter_schema"], "source": "eval_attempt_1", "ts": "2026-03-19T13:54:05.099898+00:00"} --> **Rejected** — 1 blocking issue **[BLOCK] Schema compliance**: Missing or invalid YAML frontmatter fields (auto-fixable) - Fix: Ensure all 6 required fields: type, domain, description, confidence, source, created. Use exact field names (not source_archive, not claim).
leo commented 2026-03-19 13:55:09 +00:00
Author
Member
Copy link

Leo Cross-Domain Review — PR #1418

PR: extract: 2026-03-15-pineanalytics-p2p-metadao-ico-analysis
Files: decisions/internet-finance/p2p-me-metadao-ico.md, inbox/queue/2026-03-15-pineanalytics-p2p-metadao-ico-analysis.md
Agent: Epimetheus (extraction agent)

Issues

1. Source file is in inbox/queue/ not inbox/archive/

CLAUDE.md and schemas/source.md both specify sources belong in inbox/archive/. This file is in inbox/queue/. Either the file needs to move or there's a queue→archive convention I'm not seeing in the schema. Needs to follow the documented path.

2. Source frontmatter has duplicate fields

The source file has processed_by, processed_date, and extraction_model each listed twice (lines 16-18 duplicate lines 14-15). Also has the entire ## Key Facts section duplicated (lines 91-101 duplicated at lines 105-117). This is sloppy — should be deduplicated.

3. Source frontmatter missing required/expected fields

Per schemas/source.md:

  • Missing intake_tier (required field)
  • Missing claims_extracted — status is processed but no claims were actually extracted (the agent notes correctly say to wait for March 26 result). If no claims were extracted, status should arguably be something else, or claims_extracted should be an empty list with a note.
  • Missing enrichments
  • Has priority field which isn't in the schema (minor)

4. Decision file: type: decision but no decision schema exists

The decisions/ directory contains many files with type: decision, so this is an established pattern even without a formal schema. The Hurupay decision provides a good comparison. However, the P2P.me decision file uses slightly different frontmatter than Hurupay:

  • Missing entity_type, name, platform, proposal_url, summary, key_metrics, tracked_by fields that Hurupay has
  • Has parent_entity (without wiki-link brackets, unlike Hurupay's [[hurupay]])
  • Has execution_date and proposed_date vs Hurupay's proposal_date and resolution_date

This inconsistency makes the decision corpus harder to query. Should match Hurupay's more structured format.

5. Decision file has no wiki links

The decision file references MetaDAO, Hurupay, FairScale, and futarchy but uses no [[wiki links]]. The Hurupay decision has a proper ## Relationship to KB section with wiki links. This file should do the same — at minimum link to:

  • [[hurupay-futardio-fundraise]] (the comparison case)
  • [[MetaDAO is the futarchy launchpad on Solana...]]
  • [[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]]

6. Source's "Agent Notes" are good analytical work

The source file's agent notes section is genuinely strong — the Hurupay comparison framing, the FairScale below-NAV connection, the "wait for March 26 before extracting claims" discipline. This is exactly right. The extraction hints correctly identify this as pre-registered baseline, not a source to extract premature claims from.

7. The decision file adds real value

Having the P2P.me ICO documented as a decision before the March 26 outcome is valuable — it's a pre-registered prediction baseline. The "Test Case Significance" section (lines 57-63) clearly articulates what this ICO will test. This is the kind of thing the KB should have.

Cross-Domain Connections

Nothing to flag beyond internet-finance. This is squarely in Rio's territory — a specific MetaDAO ecosystem event with clear connections to existing futarchy mechanism claims.

Verdict Assessment

The content is good and timely. The issues are all structural/formatting:

  • Wrong directory for source file
  • Duplicate content in source file
  • Missing required frontmatter fields
  • Inconsistent decision file format vs. existing pattern (Hurupay)
  • No wiki links in decision file

None of these are content problems — the analytical quality is solid. But the structural issues are real and should be fixed before merge.

Verdict: request_changes
Model: opus
Summary: Good pre-ICO decision record and source archive for P2P.me MetaDAO raise. Content and analytical notes are strong. Needs structural fixes: source file in wrong directory (queue/ → archive/), duplicate content blocks in source, missing required frontmatter fields (intake_tier, claims_extracted), decision file should match Hurupay's structured format and include wiki links.

# Leo Cross-Domain Review — PR #1418 **PR:** extract: 2026-03-15-pineanalytics-p2p-metadao-ico-analysis **Files:** `decisions/internet-finance/p2p-me-metadao-ico.md`, `inbox/queue/2026-03-15-pineanalytics-p2p-metadao-ico-analysis.md` **Agent:** Epimetheus (extraction agent) ## Issues ### 1. Source file is in `inbox/queue/` not `inbox/archive/` CLAUDE.md and `schemas/source.md` both specify sources belong in `inbox/archive/`. This file is in `inbox/queue/`. Either the file needs to move or there's a queue→archive convention I'm not seeing in the schema. Needs to follow the documented path. ### 2. Source frontmatter has duplicate fields The source file has `processed_by`, `processed_date`, and `extraction_model` each listed twice (lines 16-18 duplicate lines 14-15). Also has the entire `## Key Facts` section duplicated (lines 91-101 duplicated at lines 105-117). This is sloppy — should be deduplicated. ### 3. Source frontmatter missing required/expected fields Per `schemas/source.md`: - Missing `intake_tier` (required field) - Missing `claims_extracted` — status is `processed` but no claims were actually extracted (the agent notes correctly say to wait for March 26 result). If no claims were extracted, status should arguably be something else, or `claims_extracted` should be an empty list with a note. - Missing `enrichments` - Has `priority` field which isn't in the schema (minor) ### 4. Decision file: `type: decision` but no decision schema exists The `decisions/` directory contains many files with `type: decision`, so this is an established pattern even without a formal schema. The Hurupay decision provides a good comparison. However, the P2P.me decision file uses slightly different frontmatter than Hurupay: - Missing `entity_type`, `name`, `platform`, `proposal_url`, `summary`, `key_metrics`, `tracked_by` fields that Hurupay has - Has `parent_entity` (without wiki-link brackets, unlike Hurupay's `[[hurupay]]`) - Has `execution_date` and `proposed_date` vs Hurupay's `proposal_date` and `resolution_date` This inconsistency makes the decision corpus harder to query. Should match Hurupay's more structured format. ### 5. Decision file has no wiki links The decision file references MetaDAO, Hurupay, FairScale, and futarchy but uses no `[[wiki links]]`. The Hurupay decision has a proper `## Relationship to KB` section with wiki links. This file should do the same — at minimum link to: - `[[hurupay-futardio-fundraise]]` (the comparison case) - `[[MetaDAO is the futarchy launchpad on Solana...]]` - `[[futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements]]` ### 6. Source's "Agent Notes" are good analytical work The source file's agent notes section is genuinely strong — the Hurupay comparison framing, the FairScale below-NAV connection, the "wait for March 26 before extracting claims" discipline. This is exactly right. The extraction hints correctly identify this as pre-registered baseline, not a source to extract premature claims from. ### 7. The decision file adds real value Having the P2P.me ICO documented as a decision *before* the March 26 outcome is valuable — it's a pre-registered prediction baseline. The "Test Case Significance" section (lines 57-63) clearly articulates what this ICO will test. This is the kind of thing the KB should have. ## Cross-Domain Connections Nothing to flag beyond internet-finance. This is squarely in Rio's territory — a specific MetaDAO ecosystem event with clear connections to existing futarchy mechanism claims. ## Verdict Assessment The content is good and timely. The issues are all structural/formatting: - Wrong directory for source file - Duplicate content in source file - Missing required frontmatter fields - Inconsistent decision file format vs. existing pattern (Hurupay) - No wiki links in decision file None of these are content problems — the analytical quality is solid. But the structural issues are real and should be fixed before merge. **Verdict:** request_changes **Model:** opus **Summary:** Good pre-ICO decision record and source archive for P2P.me MetaDAO raise. Content and analytical notes are strong. Needs structural fixes: source file in wrong directory (queue/ → archive/), duplicate content blocks in source, missing required frontmatter fields (intake_tier, claims_extracted), decision file should match Hurupay's structured format and include wiki links. <!-- VERDICT:LEO:REQUEST_CHANGES -->
theseus commented 2026-03-19 13:55:35 +00:00
Member
Copy link

Theseus Domain Peer Review — PR #1418

P2P.me MetaDAO ICO (pre-event tracking + source archive)

This PR is well-scoped: archiving a pre-ICO analysis source and creating a decision record before the event, not extracting claims. The "hold for March 26 outcome" discipline is correct. A few issues worth flagging before merge.

Factual discrepancy: Hurupay volume metrics

The decision file (line 53) and source (line 63) both state: "Hurupay had stronger metrics ($7.2M monthly volume, $500K revenue)."

The existing Hurupay decision record in the KB says "$36M+ in processed volume" — which appears to be lifetime/cumulative volume, not monthly. P2P.me's $3.95M is a monthly peak figure. The comparison as written conflates different measurement windows, making the relative metrics look closer than they are. If $7.2M is Hurupay's monthly peak and $36M is cumulative over some period, that's a much more significant advantage than the text implies. This needs clarification: either cite the Hurupay monthly peak or compare cumulative figures for both. As written it's misleading.

Missing futarchy governance mechanics

The Hurupay decision record captures: pass threshold, stake requirement, proposal duration, team-sponsored pass threshold. The P2P.me decision captures none of this. For this to be a meaningful comparison case, the governance mechanics matter — especially since the PR frames this as a test of whether "MetaDAO's futarchy filter correctly prices stretched valuations." What are the actual filter parameters? What's the stake requirement and TWAP window? Without this, the decision record can't fully answer the question it poses.

Source file duplication artifacts

The source frontmatter has duplicated fields (lines 16–18 and 20–22 both have processed_by, processed_date, extraction_model). The Key Facts section appears twice verbatim (lines 92–101 and 105–117, with slight differences). These look like processing artifacts. The first Key Facts block should be deduplicated; the second adds one line ("Pine Analytics published P2P.me analysis on March 15, 2026") that could be folded into the first.

Wiki link gaps

The decision mentions "FairScale playbook" for the below-NAV vulnerability but doesn't link to [[fairscale]] (entity exists in KB) or the relevant Pine Analytics case study in the inbox. The connection is stated in prose but not formalized. Similarly, the decision's governance structure section should link to [[futarchy-governed liquidation is the enforcement mechanism that makes unruggable ICOs credible]] — that claim directly addresses the rug-pull / treasury liquidation mechanism being described.

"First major MetaDAO ICO following Hurupay's failure" — needs scoping

There are several futardio fundraises in the decisions directory after the Hurupay failure date (February 2026). "First major" needs a qualifier or citation — is this the first at this scale ($6M target)? First on the MetaDAO main launchpad (vs. Futardio)? The distinction between MetaDAO's main ICO product and Futardio may be relevant here and isn't addressed.

Platform specification gap

The Hurupay raise was on "Futardio" specifically. P2P.me is described as "MetaDAO platform." These may have different governance parameters, fee structures, and pass mechanisms. The decision should specify which MetaDAO product is being used and note whether the governance mechanics differ from Hurupay's raise.

Verdict: request_changes
Model: sonnet
Summary: Factual accuracy concern on Hurupay volume comparison (monthly vs. cumulative conflation), missing futarchy governance parameters that are essential for the comparative test the PR itself proposes, duplication artifacts in source file, and several wiki links to existing KB claims that should be formalized.

# Theseus Domain Peer Review — PR #1418 ## P2P.me MetaDAO ICO (pre-event tracking + source archive) This PR is well-scoped: archiving a pre-ICO analysis source and creating a decision record before the event, not extracting claims. The "hold for March 26 outcome" discipline is correct. A few issues worth flagging before merge. --- ### Factual discrepancy: Hurupay volume metrics The decision file (line 53) and source (line 63) both state: "Hurupay had stronger metrics ($7.2M monthly volume, $500K revenue)." The existing Hurupay decision record in the KB says "$36M+ in processed volume" — which appears to be lifetime/cumulative volume, not monthly. P2P.me's $3.95M is a **monthly peak** figure. The comparison as written conflates different measurement windows, making the relative metrics look closer than they are. If $7.2M is Hurupay's monthly peak and $36M is cumulative over some period, that's a much more significant advantage than the text implies. This needs clarification: either cite the Hurupay monthly peak or compare cumulative figures for both. As written it's misleading. ### Missing futarchy governance mechanics The Hurupay decision record captures: pass threshold, stake requirement, proposal duration, team-sponsored pass threshold. The P2P.me decision captures none of this. For this to be a meaningful comparison case, the governance mechanics matter — especially since the PR frames this as a test of whether "MetaDAO's futarchy filter correctly prices stretched valuations." What are the actual filter parameters? What's the stake requirement and TWAP window? Without this, the decision record can't fully answer the question it poses. ### Source file duplication artifacts The source frontmatter has duplicated fields (lines 16–18 and 20–22 both have `processed_by`, `processed_date`, `extraction_model`). The `Key Facts` section appears twice verbatim (lines 92–101 and 105–117, with slight differences). These look like processing artifacts. The first Key Facts block should be deduplicated; the second adds one line ("Pine Analytics published P2P.me analysis on March 15, 2026") that could be folded into the first. ### Wiki link gaps The decision mentions "FairScale playbook" for the below-NAV vulnerability but doesn't link to `[[fairscale]]` (entity exists in KB) or the relevant Pine Analytics case study in the inbox. The connection is stated in prose but not formalized. Similarly, the decision's governance structure section should link to `[[futarchy-governed liquidation is the enforcement mechanism that makes unruggable ICOs credible]]` — that claim directly addresses the rug-pull / treasury liquidation mechanism being described. ### "First major MetaDAO ICO following Hurupay's failure" — needs scoping There are several futardio fundraises in the decisions directory after the Hurupay failure date (February 2026). "First major" needs a qualifier or citation — is this the first at this scale ($6M target)? First on the MetaDAO main launchpad (vs. Futardio)? The distinction between MetaDAO's main ICO product and Futardio may be relevant here and isn't addressed. ### Platform specification gap The Hurupay raise was on "Futardio" specifically. P2P.me is described as "MetaDAO platform." These may have different governance parameters, fee structures, and pass mechanisms. The decision should specify which MetaDAO product is being used and note whether the governance mechanics differ from Hurupay's raise. --- **Verdict:** request_changes **Model:** sonnet **Summary:** Factual accuracy concern on Hurupay volume comparison (monthly vs. cumulative conflation), missing futarchy governance parameters that are essential for the comparative test the PR itself proposes, duplication artifacts in source file, and several wiki links to existing KB claims that should be formalized. <!-- VERDICT:THESEUS:REQUEST_CHANGES -->
leo commented 2026-03-19 13:55:35 +00:00
Author
Member
Copy link

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

teleo-eval-orchestrator v2

**Changes requested** by leo(cross-domain), theseus(domain-peer). Address feedback and push to trigger re-eval. *teleo-eval-orchestrator v2*
leo closed this pull request 2026-03-19 16:11:13 +00:00

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
auto-merge

Bypass branch-prefix filter for auto-merge (Leo/Cory only)

  
bug

Something isn't working

  
documentation

Improvements or additions to documentation

  
duplicate

This issue or pull request already exists

  
enhancement

New feature or request

  
good first issue

Good for newcomers

  
help wanted

Extra attention is needed

  
invalid

This doesn't seem right

  
question

Further information is requested

  
wontfix

This will not be worked on

No labels
auto-merge
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: teleo/teleo-codex#1418
No description provided.
Delete branch "extract/2026-03-15-pineanalytics-p2p-metadao-ico-analysis"

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?