# Verifier DAO v2 philosophy

Proposed direction, 2026-09-06. This overview brings together the earlier drafts -- `verifier-dao-plans.md`, `verifier-dao-critique.md`, `verifier-dao-critique-response.md`, `verifier-dao-opinion.md` and `verifier-dao-second-opinion.md` -- including the subsequent discussion of their disagreements. Those drafts were removed in commit `46d1fcb` and remain recoverable from Git history under `roadmap-notes/` at its parent, `f91026a`.

The positions below are recommendations for review. Agreement on them will guide the detailed v2 plan. Exact thresholds, contract permissions, prices, and operating procedures come next. Where the discussion has not established a preferred answer, this document identifies the choice rather than carrying an old setting forward by default.

## 1. Purpose and scope

The DAO maintains Epoche's verifier and the tests used to judge it. It accepts contributions, evaluates releases, responds to defects, and pays for useful work when funding is available. Those jobs should continue without Bryan repeatedly approving or forwarding routine actions.

Agents perform the initial work and decisions. People can submit changes, supply context, challenge decisions, and exercise defined emergency powers. Each action must follow an authorized rule and leave enough evidence for someone else to understand or challenge it. This makes unattended operation possible while keeping a way to correct mistakes.

The verifier's product review and the DAO's release review are separate jobs. The product checks an agent against a stated policy. The DAO checks whether a proposed verifier release performs that job acceptably. A credential continues to mean that the submitted agent passed specified checks under a particular policy. It does not promise the absence of every possible defect.

Begin with safety. Other domains, such as privacy, can use the same processes once they have their own policy, relevant tests, competent reviewers, and funding for any promised work. Domain records stay distinct so success on safety tests does not imply qualification to review privacy. Closing a domain must state what happens to its existing credentials.

## 2. Jobs and execution

A role is a job with permission to perform particular actions. It can belong to an agent or a person. Several roles may initially share an operator, but the records must show that concentration of control.

| Job | Responsibility |
| --- | --- |
| Contributor | Propose code, tests, documentation, or other useful work. |
| Contribution maintainer | Assess scope, authorize quotes within a budget, and coordinate accepted changes. |
| Corpus reviewer | Check test inputs, expected results, and proposed changes to the exam. |
| Review council | Assess a release and issue a reasoned acceptance, rejection, or abstention. |
| Report reviewer | Reproduce defect reports, assess eligibility, and propose attribution and awards. |
| Appeal reviewer | Reconsider a disputed decision through a separate review assignment. |
| Executor | Perform an authorized merge, deployment, payment, or administrative transaction. |
| Guardian | Take specified protective actions during an incident. |
| Voting member | Exercise the governance permissions earned under the membership rules. |

Recorded decisions create jobs for available executors. A successful release review can authorize promotion after its objection window. An accepted payment milestone can authorize a payment. The executor checks that the action, target, and current permissions match the decision. Repeating or resuming a job must not repeat a payment or broaden its authority.

This separates a decision from the machinery that carries it out. The DAO can replace a failed executor without asking contributors to restart their work. A release approval does not give the executor general permission to modify release policy or send money elsewhere.

The public event history records proposals, decisions, execution results, and corrections. Detailed private evidence can remain behind access controls. Small working implementations should establish the evidence and event formats together, before every downstream job depends on them.

## 3. Contributions and public code

Use a public contribution repository for the verifier source, policies, public tests, and DAO records. Paid open-contribution work produces open-source results under an agreed license. Contributors can use AI. Disclosures should establish the right to submit the work and any relevant license obligations, without requiring a routine declaration that AI helped write it.

A contributor requests paid work before treating it as a funded assignment. An authorized maintainer job accepts a scope and quote within its budget. The request might begin as a labeled pull request; the underlying commitment should survive a later change of interface or Git provider. Unpaid contributions can follow the same technical review process without creating a payment obligation.

Keep changes to verifier behavior and changes to its tests separately inspectable. A contributor should not be able to make their patch pass by hiding an easier exam inside the same review. Documentation and other supporting work can earn payment and participation credit according to their accepted value.

Choose one authoritative merge history for each shared source tree. Synchronization with the private monorepo must preserve accepted changes and expose conflicts. Public reading and outside proposals remain compatible with restricting merge credentials to authorized agents.

## 4. Tests and evidence

The corpus is the collection of test inputs, expected results, and the policy reasons for those expectations. Its coverage must include attacks the verifier should reject and benign agents it should accept. A large count of similar cases can leave an entire kind of failure untested, so case count alone will not determine readiness.

Use fixed deterministic checks for behavior that can be tested without a model. Use live semantic tests to measure how the selected model judges prepared agents. Add budgeted adversarial agents that search for failures beyond the prepared collection. Each method answers a different question. Saved-response replay remains useful for testing the surrounding code, but does not measure current model behavior.

Every authoritative test result identifies the code, configuration, runner, and inputs it concerns. A signed receipt records those references, the observed results, and what the signer verified. Tests may run outside a trusted execution environment, or TEE, provided the signer has adequate evidence of their execution. Signing an arbitrary uploaded success report would only authenticate the report's receipt.

Grow coverage while building the first working evaluation path. Existing fixtures are a starting inventory, not proof of adequate live-model coverage. Choose whole-program or chunked source review through evaluation of missed context and cost. Budget for evidence storage, model calls, reruns, and active attack search so the required release process is affordable to repeat.

Changes that remove a case, relax a threshold, or turn an expected failure into a pass receive explicit review. Correcting a mistaken expectation is allowed, with a recorded policy reason. A change that affects a frozen release's exam invalidates the affected evidence.

Keep exploit-disclosure rules separate from held-out evaluation. The former controls when a discovered attack becomes public. The latter limits tuning to known tests. Publication should depend on the fix and exposure of affected credentials, with a defined limit on withholding details. Keeping a private copy for reruns does not require withholding the public case.

Customer code enters the public corpus only when the customer deliberately prepares and contributes a sanitized case. Private review submissions are not a source of test material the DAO can publish at will. Use contributor-owned or synthetic examples for ordinary testing and defect reproduction.

## 5. Council authority

An AI council supplies the initial release decision. Its output identifies acceptance, rejection, or abstention, with the evidence and policy reasons behind it. The proposed model does not require two human assessments before an otherwise qualified release can proceed.

Before receiving authority, a council must pass a recorded evaluation using real changes, known defects, harmless changes, and attempts to manipulate its decisions. This can happen offline. Waiting for an arbitrary number of live releases would make qualification depend on a separate launch review system without showing that the extra dependency improves decisions.

Use measured performance to choose the council. Different model names or families do not establish independent judgment. Evaluate missed defects, false rejections, and abstentions separately. A replacement must satisfy the agreed acceptance criteria, including important failure categories. It need not beat the incumbent on every aggregate score if it offers an explicitly accepted tradeoff in cost or performance.

The council examines test evidence and changes the tests may not cover. Submitted code, reports, and tool output are untrusted inputs, including when they address the council directly. Limit the council's action permissions and test attacks aimed at its review policy, benchmark, and objection rules. A well-formed decision alone does not establish that the reasoning was sound.

Changes to the council's authority or its qualification criteria require the separate governance process. The affected council cannot authorize its own expansion of power. Human specialists can perform assigned audits, investigate disagreements, or join a later review arrangement. Payment buys defined review work, without pretending an account label proves that a human wrote every sentence.

## 6. Objections and appeals

An accepted decision normally advances after its challenge window. An objection starts a defined examination of the decision. A qualifying objection can temporarily stop execution while that examination runs. It does not automatically reverse the decision or create an unlimited right to restart the process.

Separate reports with reproducible evidence from objections requiring interpretation. A single reporter can make a serious defect actionable by supplying credible evidence and a justified expected result. The DAO still checks both reproduction and the policy claim. Reproduction itself costs resources and may not settle whether the expected verdict is correct.

Interpretive objections go to a separate review assignment, which may use another council and additional human context. Eligibility can depend on earned participation or evidence quality. A raw count of accounts does not establish independent support, so the proposed two-or-three-member threshold remains a design question.

Keep ordinary appeals bounded. Refiling the same rejected argument should not restart the clock. New evidence of an active defect can enter the incident process even after an appeal ends. A guardian's temporary emergency pause has its own authority and review requirements.

Deposits or bonds can address repeated resource abuse if needed. Losing a reasonable objection does not by itself establish abuse. A forfeiture rule must identify the conduct it penalizes, such as fabricated evidence or repeated prohibited submissions. Apply the same principle to objections over payments, while allowing different thresholds for different consequences.

## 7. Releases and model changes

A release candidate is a proposed verifier version. The proposer freezes the code, configuration, and test versions so the review concerns an exact target. Authoritative tests run against that target. The release record combines their evidence with the council decision, objections, and the eventual execution result.

Changes to model selection, prompts, policy, encryption, attestation, or other sensitive behavior require the full evaluation process. A light process can cover changes that leave those behaviors and their tests unchanged. Classification follows the effect of a change, rather than its line count.

The candidate runs at a test deployment before promotion. It may produce clearly identified test results, but must not issue credentials accepted as production credentials. Deployment authorization, release approval, and permission to issue usable credentials are separate checks. The full v2 design must make them agree throughout the client and contract paths, including lookup failures and older receipt formats.

When tests, review, and objection conditions are satisfied, an executor performs the authorized promotion. The release record identifies the promoted version and a usable fallback, or states that no fallback exists. A defective predecessor cannot remain the fallback merely because it is older.

Model replacement is a routine operating expense to plan for. A provider change can alter verifier behavior even when Epoche's code is unchanged. Budget and schedule repeated evaluation, with an explicit temporary-substitution policy for outages. An unavailable model must not cause the executor to silently substitute an unevaluated one.

## 8. Incidents and customer remedies

Automated protection should begin when the relevant evidence condition is met. Stopping new work or credential issuance need not wait for the longer review used to authorize new code. The guardian retains a narrowly defined ability to pause new credential anchoring or revoke an individual credential.

Separate stopping issuance, invalidating existing credentials, and permanently revoking a release. They have different effects and recovery options. Broader or irreversible actions require their designated authority. Emergency replacement rules must identify the allowed replacement and decision, rather than exempt every admission transaction from review.

Keep enough image and test evidence to reproduce defects against older releases. Notify affected credential holders directly where contact is available and publish an incident record with appropriate limits on exploit details. Restore service under an evaluated release. Free re-review credits remain a proposed customer remedy, with their cost reserved alongside other service obligations.

Incident clocks must fit together. A longer objection window cannot postpone protection beyond the deadline for an active incident. Launch drills should exercise the actual executor and recovery paths using disposable release and credential identifiers for irreversible actions.

## 9. Identity and participation

Participants may use pseudonyms. Keep accepted work, decisions, permissions, and unpaid entitlements attached to a stable participant record while allowing account handles and keys to change. GitHub can supply an initial account reference, but participation must have a route for reporters and autonomous agents that do not use it.

Do not require employer emails, professional references, or financial-interest declarations as the default qualification system. Use observable authorship and prior involvement to identify direct conflicts. Remove affiliation-based independence promises that the DAO cannot support without collecting affiliation information.

Someone's own contribution should not count as an independent review of that contribution. An account-based system cannot reliably detect every hidden relationship, so reward and authority rules must also limit what coordinated accounts can gain.

Publish enough history to explain credit, decisions, and authority. Private records hold only information needed for access, payment, or verified administrative requirements. A public identity hash does not guarantee anonymity when linked work or transactions reveal its owner.

Wallet rotation and recovery preserve entitlements. A valid old-key signature can authorize ordinary rotation. Lost-key recovery requires another previously authorized basis for establishing control. A waiting period alone proves nothing. Hold disputed payments while recovery is decided, with explicit treatment of money already earned and a route suitable for agents without email.

## 10. Membership and governance

Contributor status and voting membership are separate permissions. Qualifying accepted work can earn governance influence, including useful documentation. Membership does not automatically grant release, treasury, or repository credentials.

Use contribution-based influence as the starting direction. Allocate credit once per accepted contribution, even when accounts share or split the work. Linear aggregation of fixed contribution credits is a promising way to prevent account splitting from multiplying those credits. The system must also prevent duplicated work and inflated valuations from creating artificial influence. Dollar fees should not automatically become voting weight without deciding who can set those fees.

A modest token balance can be considered as an eligibility condition, with the understanding that it does not establish person uniqueness. Time-based decay, delegation, and activity rules can keep governance usable as participants come and go. Their exact formulas remain open. Reputation may inform later authority through published rules; AI review does not require an opaque AI-generated reputation score.

Define active voting weight before selecting quorum. Different powers can require different participation and notice. An unreachable quorum creates another dependence on founder intervention, while a very low one lets a small group change consequential rules. Test the proposed thresholds against plausible participation.

Governance controls budgets, role appointments, and amendments to the DAO's rules. Founding authority must be explicit. Bryan can initialize the roles and permissions needed to start the system, with a stated replacement process. A retained human reviewer pool can begin with the three accepted founding appointments discussed in the notes. Building a human admission exam is not a launch requirement for an agent-led review system.

An on-chain roster or non-transferable membership credential can record voting permissions when contracts need to check them. Neither is a reason to redefine identity or invent a second membership qualification. Election, renewal, and rotation rules should follow the responsibilities of the remaining roles.

Preserve earned claims when settings change. Rules governing authority expansion and previously accepted obligations deserve stronger amendment protection than ordinary model or pricing settings. Publish who may change each rule, when the change takes effect, and which existing work it affects. Most changes should not require pausing the entire DAO.

## 11. Keys and infrastructure

Prefer agent-held keys for routine repository, deployment, and payment work. A TEE provides a protected environment in which the approved agent can hold and use a key. Recovery must check both the permitted code and the agent's current authorization. Previously approved code cannot regain a revoked permission merely by restarting.

Keep release authority and payment authority distinct. Safes or other bounded execution mechanisms may implement that separation. Exact owner counts, thresholds, and modules belong in the detailed design. Several keys under one person's upgrade and recovery control do not provide independent authority, even when they run on separate machines.

Reuse the existing registries and suitable governance components from the prior project where they enforce the chosen rules. Reuse does not require carrying over person-verification, token, or voting features that v2 has not selected. Move contract authority to the intended controllers before outside credentials or paid commitments depend on those permissions.

An executor can be replaced without giving its successor unrestricted power. Document who can admit new code, recover keys, change hosting permissions, and restore service after a failure. Test those paths before relying on unattended operation. Human hardware keys can support an initial or emergency arrangement with their powers stated openly.

Investigate agent-provisioned Git access using existing hosting and attestation infrastructure first. On-chain permission decisions can drive a job that grants or revokes repository access. A paid or self-hosted Git service remains an implementation option. A custom service or alternative-chain key store needs a demonstrated requirement that the simpler setup cannot meet.

Keep a small investigation into cloud cost access and shutdown controls. Local job budgets and resource limits provide immediate spending controls; delayed provider cost records can reconcile actual charges. Preserve enough funded capacity for incident handling and recovery when discretionary jobs reach their limits.

## 12. Funding and budgets

Bryan will not provide the proposed 5,000 USDC founder contribution. Remove that assumption from launch budgets and runway estimates. Public development and evaluation tooling can begin before funded rewards open. Their compute and hosting still need a budget, even if no contribution pool exists yet.

Prefer a continuously replenished contribution pool with explicit commitments. Numbered bounty rounds are optional accounting, not a prerequisite for paying work. The pool's available balance determines new commitments after protecting amounts already owed and the operating costs it has agreed to cover.

Automatically allocate an agreed share of earned service revenue to the pool. Include inference, infrastructure, and other measured costs when defining the available surplus. Customer top-ups may represent service still owed and cannot simply be treated as profit. Product prices remain Epoche's responsibility, while DAO budgets and the agreed revenue-share rule have their own amendment authority.

| Funding source | Proposed position and reason |
| --- | --- |
| Service revenue | A recurring source tied to actual usage. Measure its surplus without assuming an unverified growth forecast. |
| Sponsorship or outside seed | Seek funding from parties that value the verifier. Specify what they receive, including any token allocation or service commitment, without quietly granting governance control. |
| Prepaid service | Can supply cash earlier, but creates a delivery obligation. Reserve the cost of supplying the purchased service. |
| Project-token allocation | Can compensate work or help raise funds. Spendable external assets still require buyers, funders, or liquidity providers. |
| Development trade tax | Keep open as supplemental funding from trading activity. Compare net receipts, trader avoidance, and the ability to change or disable it before relying on it. |
| Virtual liquidity or a bonding mechanism | Require a concrete account of pricing, real assets, and who supplies capital. A formula alone cannot provide funds for an external bill. |

Funding work can proceed alongside the release tooling. Open paid intake when an actual funding arrangement supports the promised terms. If reporting opens earlier, clearly distinguish unpaid reports or contingent future rewards from funded bounty commitments.

## 13. Quotes and settlement

Quote paid work in dollars to the cent. Prefer EPOCHE as the contributor settlement asset, subject to usable liquidity and explicit conversion terms. Keep the quote unit, settlement asset, and operating reserve as separate choices. Paying contributors in EPOCHE does not require customers to acquire it to buy a review.

The quote must say what the recipient is promised. Tokens calculated using an agreed reference price provide different protection from a guaranteed dollar amount realizable after a swap. A funded USDC option may be offered where a buffer supports it. A recipient can explicitly accept token-price exposure, but the DAO must not hide that exposure behind a dollar quote.

An averaged price is a candidate for token conversion. Choose its source, conversion event, and manipulation controls against the value at risk and available liquidity. A lockup may change incentives to sell, but does not correct an overpayment caused by a manipulated price. A premium for accepting token risk remains an option to price, not an assumed safeguard.

Use bounded conversions for service expenses or protected recipient payouts. If the promised output cannot be obtained within the authorized cost, follow an agreed fallback or delay while preserving the entitlement. Fixed dollar promises need funds or executable liquidity to support them. Holding every reserve in EPOCHE would expose those promises to the same market decline that could accompany a verifier incident.

Operating buffers, payout protection, and the amount of token exposure remain central choices for this overview. Yield and buybacks can be considered for uncommitted funds after those obligations have coverage. They do not take priority over earned payments or customer service liabilities.

## 14. Contribution payments

Publish fee categories for accepted work and record the scope attached to each quote. Reward useful changes and coverage, with a review path for work that does not fit an existing category. An amended scope or payment promise requires a recorded agreement.

For substantial verifier changes, use Bryan's proposed full-fee holdback with a roughly 30-day observation target as the starting position. Smaller changes can use a smaller holdback or payment on acceptance. This keeps compensation exposed during initial evaluation while avoiding the old default of retaining part of every substantial fee for 90 days.

The observation period must concern working behavior. Time since merge is inadequate when deployment has not happened. Production review count is also inadequate when it consists of repeated easy inputs. Combine relevant evaluation evidence with a bounded observation period. Give the DAO a deploy, assess, or cancel deadline so its own delay cannot indefinitely withhold the contributor's fee.

Treat a contributor-funded stake separately from withheld compensation. A proposed 20-percent stake remains an optional mechanism, initially disabled unless it addresses a stated incentive problem. It adds contributor capital requirements and still needs evidence of the condition that permits forfeiture.

Set the payment observation period, repair obligation, and exclusion from rewards on one's own defects separately. The old 12-month repair obligation outlasts its held collateral, so v2 must explain what consequence remains after payment. Neither the repair obligation nor the self-bounty exclusion should silently disappear when a holdback ends.

## 15. Defect reports and attribution

A bounty report identifies an affected release, describes the defect, and supplies reproduction evidence. Private reporting protects exploit details before remediation. A timestamped commitment can establish priority before the reporter supplies the matching full report. A bare commitment does not reserve the advertised award.

The report reviewer evaluates reproduction, the policy violation, eligibility, and the proposed reward. A validated finding becomes a regression case so later releases can be checked against it. Bounties therefore fund both defect discovery and durable test coverage. Benign controls and tests for neglected behaviors remain worth commissioning even when they have not exposed a live defect.

Reward severity and useful findings within published funding limits. Group reports by demonstrated root cause. A single patch can fix several defects, so patch count cannot determine bounty count. Keep caps attached to defects, contributions, releases, and available commitments rather than reporter identities that can be split across accounts.

Pay accepted awards on their agreed schedule. Do not make every payment wait for a fix the DAO may delay. If attribution or duplicate grouping remains disputed, separate the undisputed amount from the contested amount under explicit terms. Review caps and award multipliers together with holdbacks and stakes so coordinated contributors and reporters cannot exploit inconsistent accounting.

Ordinary payment consequences should depend on an established defect and its attribution, without first deciding whether someone intended the mistake. Attribution requires its own standard. Revert-and-retest or release comparisons may provide evidence, but interacting changes can leave uncertainty. A disputed attribution goes to appeal; uncertainty should not silently become proof of contributor fault.

Keep intentional fabrication and coordinated extraction as separate misconduct questions. One honest failure does not remove membership. Repeated poor work can prompt a role review that accounts for severity, volume, and difficulty. Decisions that remove permissions must identify the affected role and allow correction or restoration on appeal. Early self-disclosure should preserve an incentive to report and repair defects.

## 16. Supporting incentives

These features can attach to the core processes as funding and observed needs justify them. Each needs a budget owner and activation decision. They do not inherit the old plan's automatic triggers.

| Feature | Proposed position and reason |
| --- | --- |
| Corpus purchases | Pay for accepted coverage, including benign controls and sanitized customer cases. Prioritize demonstrated coverage needs rather than a fixed case-count milestone. |
| Regression conversion work | Pay someone to turn another reporter's finding into a durable case when needed. Avoid paying the same recipient twice for the same promised work. |
| Targeted review assignments and contests | Use bounded commissions or prize budgets when they buy scrutiny the ordinary process lacks. Keep blanket per-assessment payments off the default path. |
| Review-fee refunds | Consider refunding an agreed submission charge for a qualifying report. The refund follows the published terms and preserves the distinction between service credit and money returned. |
| Larger bounties | Exposure-based or pre-release multipliers can attract useful testing. Fund them within the declared limits without spending reserves owed to customers. |
| Late-payment remedies | Preserve a defined consequence for missing a funded payment commitment. Set its amount and exceptions alongside recovery holds and dispute deadlines. |
| Customer re-review | Fund credits when a verifier defect invalidates a customer's credential. Epoche can separately price expedited work following customer misconduct. |
| Priority service and volume discounts | Keep these in product pricing. Capacity and measured service economics should justify them, with the resulting DAO share recorded. |
| Sponsor-designated budgets | Track funds intended for a domain. Separate treasuries can follow when shared accounting is insufficient. |
| Marketplace referral rewards | Consider rebates for integrations that produce useful paid adoption. Base them on verified activity and affordable service economics. |
| Citation credit and retrospective rewards | Credit accepted contributions and useful prior work under agreed terms. Do not divert an earned award after the fact merely because someone asserts influence. |
| Recurring AI attack testing | Budget ongoing search when it finds useful failures. Poor public-report quality can justify stronger intake controls without automatically closing the external reporting route. |

Keep automatic membership income and per-post rewards out of the proposed model because creating accounts or text does not establish useful work. Imported account popularity should not directly grant authority. Credential-holder bonds, insurance promises, a share of buyer-to-agent payments, and prediction-market governance remain outside this v2 scope. They create separate obligations or decision systems that this maintenance process does not require. Future consideration would need an explicit case for adding them.

## 17. Administration and public claims

Choose the least administrative structure that supports the intended activity. Ask counsel about the actual proposed payment and governance arrangement, including whether it needs a designated payer or entity. A contract executing transfers does not itself answer every question about responsibilities. The old entity prerequisite and document checklist should not survive solely because they appeared in v1.

Verify required payment eligibility, tax handling, and agreements before funded intake. Automate repeatable checks and protect private information. Keep the contribution license, report scope, payment promise, and recovery responsibilities understandable to participants. Detailed forms and storage layouts follow the verified requirements.

Use the DAO name to describe the intended organization while publishing who actually controls it at each stage. Describe credentials only in terms of the checks and policy they attest to. Changes to payment machinery do not expand the product's assurance or turn the pool into an insurance commitment.

Credentials in the capital-facing certification domains must accompany enforceable limits wherever funds are used. A favorable code review cannot replace the contract controls that restrict actual spending or access to assets.

## 18. Delivery and change

Build a small working path that freezes a change, evaluates it, produces trustworthy evidence, obtains a council decision, handles an objection, and executes an authorized outcome. Establish the evidence formats through that working path. Grow the corpus alongside it and test the council before granting release authority.

Open the public contribution path early. Develop funding arrangements and payment terms in parallel, then enable funded commitments when they have coverage. This sequence makes the release work useful to Epoche even if outside participation starts slowly. It does not assume outside funding is unavailable.

Before outside reliance, exercise release isolation, credential checks, incident handling, and recovery. Before paid intake, exercise quotes, reservations, settlement, attribution disputes, and wallet recovery. A prerequisite must exist before the action it protects, rather than use that action's first occurrence as its implementation trigger.

Review operation using missed defects, false rejections, appeal outcomes, execution delays, cost, and payment performance. Assign a coordinator and an authority that can adopt changes. The overall launch review has its own date; individual contribution milestones keep theirs.

Every replaceable feature needs an owner of the change decision, evidence requirements, and an effective date. The DAO should be able to replace a council, executor, model provider, Git host, or pricing source while preserving contribution history and earned claims. Settings can evolve as actual use reveals where the initial design fails.

### Positions to settle

The feature descriptions above provide the proposed direction. These choices most strongly affect the detailed plan:

| Choice | What needs agreement |
| --- | --- |
| Council authority | Qualification criteria, who grants authority, and the separate route for changing the council's own rules. |
| Intervention rights | Who can pause an action, what starts an appeal, and how ordinary challenges reach a final decision. |
| Governance influence | How accepted work earns credit, whether tokens affect eligibility, and who can change the resulting weights. |
| Founding and recovery powers | What Bryan retains initially and how the DAO replaces executors or controllers without depending on his availability. |
| Funding and settlement | Which funding source supports launch, what EPOCHE recipients are promised, and what reserves protect fixed obligations. |
| Conditional compensation | How the 30-day target relates to observed use, repair duties, self-disclosure, and any optional contributor stake. |
| Evidence and attribution | What qualifies a test result or defect attribution to control a release or payment, including how uncertainty is handled. |
| Launch scope | Which optional incentives are worth funding initially and which remain inactive while the core process proves useful. |

Once these positions are agreed, the full v2 plan can specify contracts, events, rate cards, thresholds, deadlines, and diagrams against one consistent model.

## Appendix A. Work products and decision authority

This appendix proposes a functional meaning for the reviews mentioned above. It separates planning, implementation, observations, and decisions. The names and the stopping rule are proposals for agreement before the full v2 specification.

### A.1 What a written review does

The current language uses "review" for both the act of examining something and the document produced afterward. Those are different things. Examining a patch may produce a merge decision. Examining a test case may produce a decision about its expected verdict. Examining a frozen release may produce permission to promote that release. A written explanation records the reasons for each decision.

The substantial work is investigating the relevant question and reaching a supported conclusion. That may require reading code, comparing policies, constructing counterexamples, or running experiments. Writing down the result makes that work available for execution, challenge, and later evaluation. The document's length does not determine its value or authority.

For example, a release assessment might discover that a patch passes the existing tests but skips a class of source files that the policy requires it to inspect. That finding can prevent an incorrect release and identify a missing test. A sentence saying "looks good" has not performed the same job.

Use the following names in this appendix. Each row describes a different function, even when one interface presents several together.

| Proposed name | Other possible names | What it produces |
| --- | --- | --- |
| Change brief | Work proposal; change specification | The problem, intended change, and acceptance conditions for proposed work. |
| Implementation package | Change set; completed change | The actual code or configuration change, supporting tests, and an explanation of what changed. |
| Case decision | Test acceptance decision; corpus decision | A judgment that a test input and expected result correctly express the policy. |
| Merge decision | Contribution acceptance decision; implementation decision | A judgment that a particular implementation meets its agreed requirements and may enter the codebase. |
| Test report | Evaluation results; execution report | What happened when identified tests ran against identified code and settings. |
| Release decision | Promotion decision; release authorization | Acceptance, rejection, or abstention for an exact release candidate, supported by evidence and reasons. |
| Challenge submission | Objection case; decision challenge | Evidence or an argument identifying an error in a particular decision. |
| Appeal decision | Reconsideration decision; challenge ruling | The disposition of a qualifying challenge and its effect on the original decision. |

A signed test receipt establishes the provenance specified in section 4. It can accompany a test report. It does not decide whether the policy is adequate or whether a release should go live.

A defect report is a separate input describing a failure. It may start a release challenge, an incident response, or a bounty decision. It is not the same work product as the council's assessment of a proposed release.

### A.2 Planning and implementation

A contributor can investigate a problem before submitting anything. Their private planning notes have no formal authority. The first submitted work product is normally a change brief, possibly with an implementation already attached if the contributor worked without a prior paid assignment.

For a small correction, the brief can be a few sentences in the contribution request. It identifies what is wrong, what should change, and how acceptance will be judged. Requiring a separate planning document for every small edit would create work without resolving additional uncertainty.

For a substantial or uncertain change, commission planning separately when it produces something another implementer can use. A useful planning contribution could compare approaches, establish the relevant policy interpretation, and specify tests that will distinguish success from failure. The contribution maintainer can accept and pay for that deliverable under its own quote.

Implementation can then be a distinct contribution by the same participant or someone else. Accepting the plan authorizes the agreed work or budget. It does not establish that the later implementation is correct. Accepting the implementation establishes its own milestone and does not automatically authorize production deployment.

The proposed rule is to split planning from implementation when the planning result changes what work the DAO is willing to commission, or makes that work transferable to another implementer. Otherwise, keep the brief and implementation under one assignment. If paid planning concludes that the proposed change should not proceed, it can still satisfy its agreed investigation task.

### A.3 Where the decisions occur

Consider a change intended to make the verifier reject agents containing an embedded private key while continuing to accept a harmless instruction about configuring a key. The wording below describes an illustrative policy and change, not an actual finding against the current verifier.

1. **Propose the change.** The contributor submits a change brief explaining the failure and desired behavior. The contribution maintainer decides whether to commission the work and on what terms. If the policy itself is unclear, the policy decision must be resolved before anyone treats one expected verdict as authoritative.

2. **Prepare the implementation and cases.** The implementer supplies the verifier change. A case contributor supplies the attack example, benign control, expected verdicts, and policy reasons. One participant can do both jobs, but the code change and the exam change remain separately inspectable.

3. **Decide whether the cases belong in the exam.** The corpus reviewer checks that the synthetic key represents the prohibited behavior and that the benign control really should pass. This produces the case decision. The reviewer may reject a mislabeled example even if it would make the proposed implementation look successful. Accepting a case establishes an expectation for evaluation; it does not establish that the verifier meets that expectation.

4. **Decide whether to accept the implementation.** The contribution maintainer, or its assigned evaluator, examines the implementation against the agreed scope, accepted cases, and required code checks. It issues the merge decision. The merge executor verifies that the decision covers the submitted revision before merging it. This changes the codebase, not the production verifier.

5. **Freeze and evaluate a release candidate.** The release proposer assembles the accepted changes and records the exact code, configuration, and exam versions. The test runner evaluates that target and produces test reports with the required provenance. A release can include several accepted contributions. Accepting each separately does not establish that their combination works.

6. **Make the release decision.** The council examines the proposed release, test reports, and relevant changes. It checks questions the test verdicts alone do not settle, including missing coverage, interactions, and inconsistent policy application. It issues an acceptance, rejection, or abstention with reasons tied to the frozen target. Required failing tests cannot be overridden merely by a favorable council judgment under the same release policy.

7. **Handle challenges.** An acceptance opens the applicable objection window. A qualifying challenge stops promotion while the designated appeal reviewer decides it. For example, someone may show that the implementation detects a literal key but overlooks an equivalent encoded value covered by the policy. The appeal decides the effect of that evidence on the candidate; it does not automatically accept the challenger's conclusion.

8. **Execute promotion.** The executor checks that the exact candidate has a valid acceptance, all required evidence and tests, a completed objection window, and no unresolved blocking condition. It then performs the authorized production transition and records the result. A rejection or unresolved abstention supplies no promotion authority.

The case and implementation work may proceed in parallel. Their decisions must be consistent before the release freezes. This does not require a separate council at every step. The roles identify different questions and permissions; the detailed plan can assign them to suitable agents or councils.

For a corpus-only change, the implementation is the changed test collection itself. It still needs a case decision, including special treatment when it makes the exam easier. A later candidate uses the accepted corpus version. Updating the corpus does not rewrite an old release's test history or automatically reapprove it. Any required re-evaluation of production is a separate job.

### A.4 How much weight each result carries

The work products do not enter a weighted average of opinions. Each answers a different question and has authority over a particular transition.

| Result | Decision weight | What it cannot establish |
| --- | --- | --- |
| Accepted change brief | Authorizes the agreed assignment or planning milestone. | That an implementation exists, passes tests, or may be deployed. |
| Implementation package | Supplies the proposed change and evidence for evaluation. Its author's explanation supports examination. | Permission to merge or promote itself. |
| Accepted case decision | Establishes the allowed corpus change and expected behavior under the stated policy. | That the candidate produces that behavior. |
| Accepted merge decision | Permits the exact contribution to enter the codebase once merge conditions hold. | That the combined production candidate is acceptable. |
| Test report meeting required criteria | Satisfies the corresponding measured release requirement, if its provenance and target are valid. | Coverage of every possible defect or permission to execute a release transaction. |
| Accepted release decision | Supplies the council's required authorization for the candidate, conditional on all other release requirements. | Permission to ignore failed requirements, unresolved challenges, or a changed target. |
| Qualifying challenge | Opens a defined reconsideration and, where specified, temporarily blocks the affected transition. | Automatic reversal of the challenged decision. |
| Appeal decision | Upholds or replaces the disputed decision within the appeal body's authority. | General power to rewrite the release policy or approve unrelated changes. |

The importance of a release decision comes from the permission attached to the deciding role and the evidence it must consider. It does not come from calling the explanation a "written review" or assigning its prose a numerical score.

The same distinction applies to payment. A separately commissioned investigation or decision can be a paid work item, including when its supported conclusion is rejection. Producing an unsolicited assessment does not create a fee or grant authority. Payment terms should specify the job being purchased and its acceptance conditions.

### A.5 From judgment to a state change

Subjective judgment enters through an explicitly authorized decision-maker applying a stated policy to a specific target. The programmatic process accepts that decision within a limited scope. It does not convert the explanation into a mathematical proof that the release is safe.

The proposed chain has four parts:

1. **Inputs.** Supply the exact proposal or frozen candidate, applicable policy, required test evidence, and any prior decisions on which it depends. The evaluator treats submitted material as untrusted input and investigates the questions assigned to its role.
2. **Decision.** The authorized evaluator produces a structured outcome and supporting reasons. Its decision identifies the target, policy version, evidence, action being authorized or denied, and the authority that issued it. An authenticated record, such as a signature from the role's authorized key, establishes who issued the decision. A council follows its configured agreement rule before issuing a collective result.
3. **Mechanical checks.** The state controller checks the decision's authentication and whether its issuer has the relevant permission. It verifies the required decision approvals, that the target still matches, and that the required evidence exists and comes from permitted sources. It also checks required test outcomes, timing, outstanding challenges, and whether execution has already occurred. Invalid or incomplete records do not authorize the transition.
4. **Execution.** Once those conditions hold, the executor performs only the permitted action. The result becomes another event in the history. If a prerequisite changes before execution, the controller must recheck whether the authorization still applies.

For example, an illustrative release decision might contain the following information. These are explanatory fields, not an implemented contract or selected schema:

```text
Target: candidate R17, exact code/configuration/exam references
Policy: release policy P4
Issuer: authorized release council C2
Outcome: accept
Authorized action: promote R17 after its remaining release conditions hold
Evidence: identified test reports and accepted case decisions
Reasons: the embedded-key case fails as expected, the benign control passes,
         and the inspected change preserves the required source coverage
```

The state controller can reject this record if the evidence belongs to another candidate, the issuer lacks authority, a required test failed, or a blocking challenge remains open. It cannot establish merely by checking the fields that the council correctly judged the source coverage. That judgment belongs to the council and can be challenged with contrary evidence.

A second model scoring how convincing the explanation sounds would be another judgment. It would not eliminate that limit. Use additional evaluators when they perform a defined, useful check, and treat them as part of the configured decision process rather than creating another compulsory assessment afterward.

### A.6 Where checking stops

Use a qualified decision-maker with bounded authority as the ordinary stopping point. Qualification and periodic evaluation establish why the DAO delegates that job to it. Required evidence, mechanical checks, and challenges limit what it can do and expose errors. None supplies an endless chain of guarantees about the next evaluator.

For discussion, use one ordinary appeal stage per challenged decision. A different review assignment examines the challenge and produces the operative result for that case. Its result receives the same permission, target, and process checks as any other authoritative decision. It does not require a third assessor to certify the second assessor's reasoning.

The final ordinary disposition can permit the action, reject it, or close the attempt as unresolved. Unresolved judgment is not permission to promote. Give the process a finite deadline and a bounded reassignment policy so it cannot remain in an invisible waiting state forever. A material revision can start a new proposal. Repeating the same closed challenge cannot restart the old one.

New evidence of a serious defect can still trigger the incident process, including after production promotion. Governance can replace a poor evaluator or revise policy through its separate authority. Those are exception and maintenance paths, not additional approvals required for every ordinary decision.

The delegation itself also has a starting point. The founding governance authority selects the initial policy, qualified decision-makers, and limits. Later governance can replace them under the charter. A benchmark provides evidence for granting authority; it does not appoint the council by itself. No extra council can remove the need to choose who initially has that power.

This leaves a real possibility of an authorized but mistaken decision. The proposed system accepts that possibility, limits the damage an individual decision can cause, and retains ways to challenge, stop, and correct it. Requiring someone to approve every approval would add delay without resolving the underlying need to entrust a bounded judgment to a decision-maker.

### A.7 What needs agreement

The main distinction to settle is between commissioning work, accepting code or tests, and authorizing a production release. Those functions should remain visible even when the same agents perform several of them or the interface combines their records.

The next decisions are whether to use the proposed names, when to commission planning separately, which evaluator holds each decision permission, and whether one ordinary appeal is the right stopping rule. Council size, payment amounts, schemas, and exact deadlines can follow once these functions and their authority are clear.