feat: M001-ENH mechanism spec + economic reboot mechanisms#19
feat: M001-ENH mechanism spec + economic reboot mechanisms#19CShear wants to merge 2 commits intoregen-network:mainfrom
Conversation
… spec Consolidate design material from phase-2/2.1 (M001-ENH), phase-2/2.3 (GOV-001), and phase-3/3.1 (protobuf + keeper) into a canonical mechanisms/ folder following the m010 pattern. Includes 13-section SPEC, JSON schemas (agent score, proposal lifecycle, KPIs), reference implementation with deterministic test vectors, and replay datasets grounded in real Regen Network credit types and classes. Also adds "type": "module" to package.json for ESM export support in reference-impl .js files (consistent with existing m010 ESM syntax). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Summary of ChangesHello @CShear, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request introduces the M001-ENH mechanism, a significant enhancement to the Regen Network's credit class approval process. It establishes a robust, agent-based pre-screening system designed to elevate the quality of credit class proposals and optimize governance efficiency. The changes encompass a comprehensive specification, standardized data models via JSON schemas, and a functional reference implementation with test data, all aimed at fostering a more structured and reliable evaluation framework for new credit classes. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request introduces the M001-ENH mechanism specification, reference implementation, and associated schemas and datasets. The documentation is comprehensive, and the new files are well-structured. Several inconsistencies and minor improvements have been identified in the specification and reference implementation, particularly concerning the explicit definition of transition logic and data structure alignment, which should be addressed for clarity and correctness. The changes also include enabling ESM support in package.json.
| - If no M010 score: `f_reputation = 500` (neutral default) | ||
| - Historical proposal success rate is a secondary factor: `f_reputation = 0.7 × m010_score + 0.3 × (historical_pass_rate × 1000)` |
There was a problem hiding this comment.
There's an inconsistency in how the M010 reputation score is scaled. This specification states that m010_score is 0-1 in v0, but 0-1000 in v1. However, the m001_score.js reference implementation and m001_agent_score.schema.json expect admin_reputation to be in the 0-1000 range directly. This implies that if m010_score is used as admin_reputation in v0, it needs to be explicitly scaled (multiplied by 1000) before being passed to the computeM001Score function. This discrepancy should be clarified in the documentation or handled within the implementation to prevent incorrect scoring.
References
- When specifying transition logic between different mechanisms (e.g., multipliers), explicitly define the function (e.g.,
max()) and the state-based conditions (phase-gating) that govern the transition to prevent implementation ambiguity.
| const clamp = (v, lo, hi) => Math.max(lo, Math.min(hi, v)); | ||
|
|
||
| const fMeth = clamp(factors.methodology_quality ?? 0, 0, 1000); | ||
| const fRep = clamp(factors.admin_reputation ?? 500, 0, 1000); |
There was a problem hiding this comment.
This line directly uses factors.admin_reputation assuming it's already scaled to 0-1000. This is consistent with the test vectors and the m001_agent_score.schema.json but conflicts with the SPEC.md and reference-impl/README.md which state that the M010 score is 0-1 in v0. Ensure that the input admin_reputation is consistently scaled to 0-1000 before being passed to this function, or implement the scaling logic here.
References
- When specifying transition logic between different mechanisms (e.g., multipliers), explicitly define the function (e.g.,
max()) and the state-based conditions (phase-gating) that govern the transition to prevent implementation ambiguity.
| "type": "integer", | ||
| "minimum": 0, | ||
| "maximum": 1000, | ||
| "description": "Admin/proposer reputation from M010 (weight: 0.3)" |
There was a problem hiding this comment.
The admin_reputation property is defined with a minimum: 0 and maximum: 1000. This aligns with the m001_score.js implementation and test vectors, but it's important to ensure this is consistent with the source of admin_reputation (M010 reputation signal) as described in SPEC.md and reference-impl/README.md, which mention a 0-1 scale for v0. This reinforces the high-severity issue identified in SPEC.md regarding score scaling.
References
- When specifying transition logic between different mechanisms (e.g., multipliers), explicitly define the function (e.g.,
max()) and the state-based conditions (phase-gating) that govern the transition to prevent implementation ambiguity. - When defining data structures or type definitions, ensure they are aligned with the project's central data standards repository (
regen-data-standards) to maintain coherence.
| @@ -0,0 +1,32 @@ | |||
| # m001-enh — Credit Class Approval Voting Enhancement (v0 advisory) | |||
|
|
|||
| m001-enh enhances the Regen Network credit class creator allowlist with **agent pre-screening**, **tiered approval thresholds**, and **deposit escrow** (v1). It builds on the existing `x/ecocredit` governance process with structured quality assessment before community vote. | |||
There was a problem hiding this comment.
The phrase "deposit escrow (v1)" here might be slightly redundant given that the "What it does not do (v0)" section explicitly states that deposit escrow is not on-chain in v0. Consider rephrasing for improved clarity, perhaps by removing "(v1)" from this introductory sentence.
| Where `data_available_factors` counts factors with non-default/non-estimated inputs: | ||
| - M010 reputation score exists (not defaulted to 500) | ||
| - Methodology document fully resolvable and parseable | ||
| - At least 3 existing classes for meaningful similarity comparison |
There was a problem hiding this comment.
The condition "At least 3 existing classes for meaningful similarity comparison" is a specific threshold. Consider adding a brief rationale for why '3' was chosen, or if this value should be configurable in the future.
| export function median(nums) { | ||
| if (!nums.length) return null; | ||
| const s = [...nums].sort((a, b) => a - b); | ||
| const mid = Math.floor(s.length / 2); | ||
| return s.length % 2 ? s[mid] : (s[mid - 1] + s[mid]) / 2; |
There was a problem hiding this comment.
The median function is defined but does not appear to be used anywhere within m001_kpi.js. If it's not intended for immediate use, consider removing it to keep the codebase clean and avoid dead code. If it's for future use, perhaps add a comment indicating its purpose.
| const expected = JSON.parse(fs.readFileSync(expectedPath, "utf8")); | ||
|
|
||
| const results = input.proposals.map(p => computeM001Score({ | ||
| proposal: p.proposal, |
There was a problem hiding this comment.
The condition factors.sufficient_classes !== false is functionally correct but can be simplified. For boolean checks, if (factors.sufficient_classes) is more idiomatic and readable.
if (factors.sufficient_classes) available++;… dead code - SPEC.md: clarify M010 score scaling (v0: multiply by 1000; v1: direct) - SPEC.md: add rationale for 3-class similarity threshold - README.md: rephrase deposit escrow v1 note for clarity - m001_kpi.js: remove unused median() function - m001_score.js: simplify confidence checks from !== false to truthy Fixes Gemini review on PR regen-network#19. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
1 participant
Summary
mechanisms/m001-enh-credit-class-approval/, consolidating design material from phase-2/2.1, phase-2/2.3, and phase-3/3.1"type": "module"for ESM support)What's in the M001-ENH spec
m001_agent_score,m001_proposal,m001_kpim001_score.js(scoring) +m001_kpi.js(KPI computation) with test vectorsv0_sample.json(full lifecycle) +v0_rejection_sample.json(edge cases)Test plan
npm run verifypassesnpm run check:indexpassesm001_score.jsself-test matches all 5 expected test vectorsm001_kpi.jsproduces correct KPI output from fixture data🤖 Generated with Claude Code