# Epoche DAO handbook Operating rules and procedures for verifier maintenance, community participation, and funding. ## 1. Purpose and flows The DAO maintains Epoche's verifier, its policies, and its test corpus. The verifier checks service code against a stated policy. These services accept requests over a network and may use AI agents or ordinary application code. The corpus contains example inputs, expected results, and the policy reasons for those expectations. Contributors improve both, report defects, and earn rewards under funded terms. A release candidate is an exact proposed verifier version, including its code, model, configuration, and test versions. The DAO evaluates it in an isolated test environment. When its required checks pass, its member challenge window finishes, and no blocking case remains, an authorized executor promotes it to production. These are optimistic updates. Members have a defined opportunity to challenge a tested change before it takes effect. Routine progression does not require a person to approve each step. Missing tests, missing authority, and unresolved blocking evidence prevent progression even when nobody objects. Start with the safety domain. A domain is a separately defined policy and the releases qualified to apply it. Privacy and later domains need their own tests, qualification, budget, and credential meaning. Closing a domain must state whether existing credentials remain usable and how customers learn of the change. The DAO also maintains the implementation that protects submitted code, produces evidence, and enforces credential checks. Updating schemas alone cannot do those jobs. A schema specifies the shape of a record. Policy specifies what behavior qualifies. ### Technical terms | Term | Meaning in this handbook | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Credential | A record attesting that identified code or an agent satisfied the specified checks. Its validity also depends on the applicable current authorization and revocation rules. | | Registry | A record system, often an on-chain contract, that stores authorized releases, keys, credentials, or their status. Each registry's role must be explicit. | | Hash | A digest used to identify exact data, such as a source tree or configuration. Matching a hash establishes identity of the referenced content under the hash scheme. It does not establish that the content is safe. | | Trusted execution environment, or TEE | A protected execution environment that can isolate a worker and its secrets under the platform's guarantees. This handbook also calls its protected worker environment an enclave. | | Attestation | Evidence about the code and settings running in an environment. A verifier checks that evidence against the expected identity and current permission. | | Quorum | The required participation for a governance decision. The separate decision threshold determines which result wins among the eligible votes. | | Authority epoch | A version number for current permissions. Replacing authority increments it so a queued action under an obsolete assignment cannot execute. | Governance and management belong to the same broad responsibility of controlling the DAO, but they should use different permissions. Governance changes the rules or grants authority. Examples include changing the funding split, adopting a new verification policy, or authorizing a replacement council. Administration applies existing rules and budgets. Assigning an already-funded task, renewing an authorized service, or paying an earned milestone can be administrative work. Both can execute automatically after authorization. A deliberate governance decision might require a member vote. A transaction executor then carries it out. Conversely, an automated council can exercise substantive judgment. "Automatic" does not mean "requires no judgment," and "requires a decision" does not mean someone must manually submit the resulting transaction. There are two recurring operations beneath that purpose: - Changing the verification system through evaluated releases. - Using an approved release to evaluate an individual agent and produce the relevant evidence or credential. They share policies, infrastructure, and registries. They have different state machines. An individual customer review should not open a DAO release challenge window or require a governance vote. During founding operation, the release challenge window uses the public eligibility rule in section 9. It does not depend on contribution scores or voting membership. After governance membership activates, members gain its adopted rights while the public factual-report route remains available. ### Core flow inventory | Flow | Starts with | Completion and connected work | | ------------------------------------------ | ----------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | F1. Ordinary verifier update | A proposed code, configuration, model, or compatible schema change. | A confirmed production release or a closed attempt. Uses corpus, challenge, infrastructure, and contribution-payment subflows. | | F2. Corpus update | New cases or changes to inputs, expectations, or evaluation criteria. | A versioned corpus change accepted under the relevant policy. Can join F1 or finish independently for use by later releases. | | F3. Credential issuance and checking | A customer's request to review or deploy an agent, or a request to check its credentials. | A result, credential, deployment record, or explicit failure. Uses approved releases and product payment rules. | | F4. Defect report and bounty | A report against an identified release. | A recorded disposition and any award entitlement. A validated finding starts regression work and may start an incident. | | F5. Incident and emergency patch | A demonstrated failure or authorized protective alert. | Containment, evaluated restoration, and follow-up, or an explicit continued service restriction. Can begin before bounty eligibility is decided. | | F6. Contribution compensation | An accepted paid assignment and its milestones. | Settlement, a justified adjustment, or a recorded unresolved entitlement. Usually runs alongside F1 or F2 rather than after the entire release process. | | F7. Customer remedy | A service failure or incident affecting identified customers. | Automatic service credit under an existing rule, or an authorized discretionary refund and its execution. | | F8. Budgets and operational administration | A budget proposal, resource request, or task assignment. | A funded allocation or an explicit rejection. Supplies spending authority to other flows. | | F9. Rule and authority changes | A proposed change to policy, splits, voting, council authority, or recovery powers. | An authorized amendment with an effective date and any necessary migration. May require an F1 implementation before activation. | | F10. Infrastructure and access recovery | A failed worker, lost key, empty gas wallet, or unavailable service. | Restored capability, a replacement with valid authority, or a declared inability to continue safely. Every execution flow can call this subflow. | A challenge is a shared subflow, not a separate organizational purpose. It can challenge a corpus decision, release, payment attribution, or proposed amendment. Its evidence and permitted consequences depend on the parent flow. Funding collection is another shared subflow. The current direction includes review-fee allocations, the 1% EPOCHE buy/sell tax, and routing those incoming funds between the bounty pool and burning according to the threshold. Applying the accepted routing rule is automatic administration. Changing its percentages or threshold is F9. ## 2. Roles and authority ### Authority belongs to an assignment Use these actor names throughout the state tables: | Actor | Meaning and limits | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Contributor | An independently acting person, agent, or person using agents. May also be a member. Submission alone grants no execution authority. | | Member | A participant eligible to exercise the specified challenge or governance rights. Membership alone does not grant a treasury or deployment key. | | State controller | Software that checks transition conditions and records the resulting state. It cannot waive a requirement because a worker reports difficulty. | | Maintainer | The authorized role that scopes work, approves assignments within its budget, and handles implementation acceptance where judgment is needed. | | Policy or corpus council | An authorized evaluator of test expectations, policy interpretation, or unresolved coverage. Its assignment determines which question it can decide. | | Runner | A worker authorized to execute identified tests and provide the required evidence. It has no general release-approval power. | | Challenge council | The separately assigned authority that decides a qualifying challenge within a bounded appeal process. | | Executor | A worker with permission to perform a specific merge, provisioning action, contract call, or payment after authorization. | | Guardian | A key or process authorized for specific protective actions. Its ability to stop issuance does not imply permission to admit arbitrary new code. | | Governance authority | The authorized members or stated founding arrangement that adopts rules and grants or replaces consequential permissions. | | Report authority | A delegated role that determines report eligibility, defect attribution, and awards within published terms. | | Budget authority | A delegated role or governance body that approves the relevant allocation or discretionary remedy. Budget-controller software enforces its limits and reservations. | | Operations worker | A scoped executor that provisions services, reconciles provider state, and performs authorized recovery. | | Incident coordinator | The assigned role that tracks containment, restoration, notices, and follow-up. Coordination alone grants no extra transaction permission. | An external AI contributor and a DAO executor may run similar models. Their authority is entirely different. An executor's permission comes from its role and key assignment. Running an agent in a protected environment does not grant it DAO authority. A contributor can supply useful evidence without receiving any such key. Independence must be stated relative to a task. The author of a change cannot supply an independent challenge ruling on that change merely by running another agent. A council also cannot grant itself wider authority. Requiring independent input is justified for specific decisions, not for every routine machine action. ### Use separate dimensions Classify each step along the dimensions below. Evaluation can be full, targeted, or unnecessary for a record-only action. Authority, evidence source, and execution mode describe different properties. | Dimension | Values to record | Why it matters | | ------------------ | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Work performed | Submission, computation, judgment, execution, or observation. | Identifies what actually happens. One logical step may contain distinct jobs of different kinds. | | Evaluation depth | None, targeted, or full. | Measures the scope of substantive checking. Mechanical input validation still applies when depth is none. | | Input source | Contributor, DAO worker, member, provider, or several sources. | States where evidence comes from. It does not establish authority. | | Decision authority | Existing rule, delegated role, challenge authority, or governance. | Determines what can authorize the transition. | | Execution mode | Event-driven, deliberate submission followed by automation, or exceptional human operation. | Separates making a decision from transporting or executing it. | | Effect | Record only, bounded spending, test deployment, production exposure, irreversible action, or rule change. | Helps determine permissions, delays, and recovery requirements. | | Timing | No additional wait, evidence collection, challenge window, execution delay, or payment observation. | States why the transition waits and what ends that wait. | These dimensions are independently useful, but not every combination should be allowed. For example, a record-only observation needs no treasury signature. An irreversible production action needs the appropriate authority even if no new judgment is required. A contributor-supplied report does not acquire decision authority merely because its schema is valid. The targeted evaluation path is the light path discussed in earlier drafts. A challenge window is an explicit transition requirement selected because of the action's effect and the opportunity needed to detect errors. It does not follow automatically from whether an AI performed the work or whether the evaluation was full. For the compact tables below, work codes are `S` for submission, `C` for computation, `J` for judgment, `X` for execution, and `O` for observation. Evaluation depth is written in words. A row containing `C` and `J` identifies both computation and judgment. The row states when judgment is required. Full candidates require a scoped coverage decision before merge. Routine production eligibility still follows the recorded rule without another subjective release verdict. ### Permission boundaries Each role assignment records its controller, allowed actions, domain, budget ceiling where applicable, expiry, and replacement authority. If one operator controls several roles, publish that relationship rather than counting its keys as independent decision-makers. | Permission | Authorized holder | Boundaries | | ----------------------------------------------- | ------------------------------------------ | -------------------------------------------------------------------------------------------------------- | | Accept a paid scope | Maintainer within an allocated budget | Cannot exceed the available reservation or change the contributor's agreed settlement terms. | | Produce authoritative test evidence | Qualified runner | Cannot change expectations, choose only favorable runs, or promote a release. | | Resolve a test expectation or coverage question | Assigned policy or corpus council | Must identify the question and policy. Changing policy requires F9. | | Merge and deploy for testing | Scoped repository and deployment executors | Can act only on eligible revisions and test-only identities. | | Promote a release | Production executor under the release rule | Must verify the complete promotion condition for the exact candidate. | | Decide a challenge | Separate challenge assignment | Cannot change unrelated settings or spend outside the case's authority. | | Contain an incident | Guardian under the incident rule | Pause, credential revocation, release distrust, and new release admission are separately granted powers. | | Pay an entitlement | Payment executor | Exact recipient, asset, amount or conversion limit, and entitlement identifier. | | Change permissions or rules | Governance authority | Follow notice, quorum, effective-date, and existing-obligation protections. | A role can belong to software, a person, or a stated combination. Routine agents should hold only the access their jobs need. A member's governance rights do not grant access to customer code or treasury keys. The state controller coordinates the recorded workflows. The promotion controller is the narrower on-chain contract that enforces queued release permissions. An executor connects them by checking off-chain eligibility and submitting the permitted contract action. ## 3. Contributions and work products 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 survives 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. ### Planning and implementation A small contribution can begin with a change brief attached to its implementation. The brief names the problem, affected behavior, intended result, test evidence, and dependencies. It does not need a separately paid planning stage. Commission a separate implementation specification when resolving uncertainty is substantial work that another contributor can use. Its acceptance conditions should identify the questions it resolves and the instructions or design it delivers. Accepting that specification does not promise its author the implementation assignment. Quote implementation separately when another party does it or the work needs a separate budget decision. Payment follows the accepted scope. An implementer may supply a test report as part of the package without creating a second paid contribution. An independently commissioned evaluation can be a distinct paid assignment. Payment should buy useful work, without depending on whether a human or an AI wrote its prose. ### Names and effects Use these primary names throughout the records. Alternative names describe the same function if an interface needs a shorter label. | Work product | Contents and place in the flow | Decision effect | Alternative names | | ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------- | | Change brief | Problem, intended behavior, scope, evidence, and dependencies at U01. | Allows classification and a scope decision. It does not authorize production. | Change proposal, task brief | | Implementation specification | A separately commissioned design or investigation before implementation, when needed. | Can satisfy its own paid planning milestone. | Design document, implementation specification | | Implementation package | Exact source revision, configuration changes, proposed cases, and reproduction instructions at U04. | Supplies the target for validation and merge acceptance. | Change package, patch package | | Case decision | Input, expected result, policy reason, and any disputed interpretation at U05 or F2. | Permits use of the expectation for candidate testing. Activation follows the corpus procedure. | Expected-result decision, corpus decision | | Coverage decision | Exact diff, affected behaviors, mapped checks, and unresolved coverage gaps. Required at U06 for a full candidate. U02 opens the task. | Establishes the required evaluation for that revision. It cannot waive a failing requirement or authorize production. | Coverage assessment, evaluation requirements | | Test report | Exact tested inputs and versions, prescribed runs, observed results, and authenticated execution evidence. | Supplies measurable evidence to any rule whose requirements it satisfies. | Evaluation results, test evidence record | | Merge decision | The controller's result from applying merge requirements to an exact revision at U06. | Authorizes that merge. It can be generated automatically from test evidence. | Merge authorization, acceptance record | | Release decision | The controller's result after applying production requirements at U12 and the execution checks at U14. | Establishes eligibility, then permits the identified production action. | Promotion authorization, production eligibility record | | Challenge submission | A specific alleged error, target, requested correction, and supporting evidence. | Starts qualification. Only a qualifying case blocks its permitted transition. | Objection, counterexample submission | | Challenge decision | The assigned authority's ruling and reasons for the disputed question. | Upholds acceptance, requires correction, or leaves the case unresolved. | Appeal decision, dispute ruling | The test report, merge decision, and release decision can refer to the same evidence. They differ in function and timing. A merge requires the agreed implementation checks. Production also requires an exact tested deployment, a completed valid challenge window, and current execution authority. Do not commission three essays to record those three facts. ### Where evaluation stops Tests give measurable evidence that a candidate met the checks actually run. The controller can use that evidence directly to decide acceptance under the agreed policy. That is enough for the routine release rule. No additional subjective council approval applies to every passing report. Judgment establishes coverage for a full candidate and resolves expectations, classification exceptions, or challenges that an existing rule cannot settle. The assigned council receives the exact question and evidence. It returns an authenticated acceptance, rejection, or abstention with reasons and its permitted effect. The controller checks identity, assignment, target, required agreement, and validity. It does not ask another council to re-evaluate every sentence. The stopping point is a qualified decision authority, a bounded challenge process, and an executor that checks the resulting permission. New evidence can reopen an active safety problem through the incident process. An endless sequence of reviewers is not required to make an ordinary decision final. ## 4. Records and clocks Keep separate records for a proposal, each implementation revision, each release candidate, and each payment entitlement. One release can contain several contributions. One contributor can complete accepted work even when a later combined release fails. Linking the records preserves that distinction. Each flow instance carries its current state, exact input versions, applicable rule version, authorized action, evidence references, and any deadlines. Execution jobs also carry an identifier used to prevent duplicate effects. This identifier lets another worker resume the job without issuing the same payment twice. Use one recorded source of truth for an authorization. A queue delivers work, and Git holds source and files, but neither can contradict the authoritative permission record. The promotion controller holds queued action identity, executor authority, delay, cancellation, and execution status. The authenticated off-chain records hold evaluation, coverage, and challenge facts that its executor checks. Database and transport choices remain implementation details within that split. The DAO also has operating states, such as normal operation, degraded operation, and a scoped pause. These restrict individual flows. A pause can stop affected credential issuance while reports and recovery continue. It should not freeze every action merely because one service is unavailable. ### Distinct clocks | Clock | Starts when | Purpose and completion | | -------------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Work deadline | The paid scope and assignment are accepted. | Limits how long the implementer or DAO may leave the assignment unfinished. The terms define extension and cancellation. | | Evaluation period | The exact candidate is available to the required runners. | Collects prescribed tests, samples, and attack-search work. Completing elapsed time alone does not complete missing evaluation. | | Member challenge window | Members can access the candidate, required baseline results, and evidence needed to challenge it. | Gives members a real opportunity to object before activation. It cannot expire while the essential test access is unavailable. | | Execution delay | A valid authorization is queued under a rule requiring delayed execution. | Provides notice before a consequential action. The executor must still check current authority when it acts. | | Payment observation period | The accepted contribution reaches the agreed observable-use milestone. | Determines when conditional compensation matures. It is separate from the pre-production challenge window. | | Recovery deadline | A job enters a recorded recovery state. | Bounds retries and escalation before the attempt closes or a continuing service restriction is declared. | The thirty-day period concerns conditional compensation. A release can go live before that payment matures. Standard and emergency release clocks have separate purposes and settings. Testing and challenges can overlap after the required baseline results are available. If further scheduled attack testing must finish before release, promotion waits for it even if the member window has closed. A finding can block the candidate at any time. A material change to the target requires new relevant evidence and a fresh opportunity to challenge the changed target. ### Required record contents The names below specify logical records. They do not prescribe a database or claim an API already exists. | Record | Required contents | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Work assignment | Participant, scope, acceptance conditions, quote, license terms, resource budget, rule version, deadlines, and linked revisions. | | Candidate | Domain, source tree and build hashes, model and configuration references, corpus and policy versions, coverage decision or targeted-classification proof, predecessor, and proposed actions. | | Evaluation | Candidate identifier, runner and runner version, complete prescribed run list, inputs, expected and observed results, failures, unavailable runs, costs, and evidence authentication. | | Judgment | Target and question, decision-maker's assignment, disposition, reasons, evidence, rule version, expiry, and allowed effect. | | Authorization | Exact action and target, issuing authority, applicable rule, expiry, replay protection, and any required predecessor state or delay. | | Execution | Authorization identifier, worker assignment, attempts, external transaction or job identity, confirmed outcome, and reconciliation status. | | Challenge or incident | Affected target, report evidence and access policy, qualification, blocking scope, assigned authority, clocks, decisions, and follow-up. | | Payment entitlement | Accepted quote and milestone, recipient record, asset and conversion terms, reserved amount, due or disputed portions, and settlement outcome. | Publish an event when a record changes state. Keep the prior version and the evidence that justified the change. Correct an erroneous record with a linked correction rather than erasing its history. Public events can identify confidential evidence by hash and controlled-access reference. Authenticate decision payloads with their intended system, action type, and target. An on-chain authorization also identifies the intended chain and contract. Apply an expiry and a single-use identifier where reuse could duplicate or redirect an effect. The controller must compare the current state when committing a transition so two workers cannot act on incompatible snapshots. Record pending external actions before dispatch. After an interruption, reconcile the transaction or provider job before issuing another effect. A worker lease expiring does not prove that its earlier action failed. ## 5. Tests and councils 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. ### Evaluation requirements Set evaluation requirements before observing the candidate's results. Each requirement identifies a behavior, relevant cases, acceptable outcomes, repetition policy where the model varies, and the evidence needed to establish completion. Safety failures and false rejections must remain visible separately. An aggregate score must not conceal a failed mandatory requirement. Full evaluation covers changes to models, prompts, policy, encryption, attestation, credential validity, and other behavior that can change what the verifier accepts or exposes. Targeted evaluation is available when the maintainer can establish a narrower effect under the classification rule. A small diff can still require full evaluation. | Evaluation method | Required purpose and evidence | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Deterministic checks | Exercise parsing, signatures, policy plumbing, access restrictions, and other behavior with fixed expected outcomes. Store the actual run results. | | Live semantic evaluation | Run the selected model against the prescribed attack and benign cases. Record model and request settings, repeated trials, and unavailable responses. | | Adversarial search | Give attack agents a bounded task, environment, budget, and stopping rule. Record attempted search and findings. Silence from a failed search worker is incomplete work. | | Integration checks | Establish that the evaluated build, test isolation, registries, credential readers, and proposed deployment agree. | An example case may contain a synthetic embedded private key that the stated policy prohibits. Its expected result is rejection. A paired benign case can describe how to configure a key without containing one, with acceptance as its expected result. The actual policy must justify both expectations. Matching those expectations measures those cases, not every possible program. Require the full prescribed result set, including failures and incomplete runs. Distinguish a transport retry from a fresh model trial. A contributor cannot rerun until the desired answer appears and report only that attempt. Changes to trial counts or thresholds after observing results need a recorded rule decision and any required reevaluation. Pin provider versions where possible and record the provider evidence available. If a provider cannot guarantee stable behavior under an identifier, define periodic reevaluation and drift handling. An outage cannot silently replace the verifier's model with an unevaluated substitute. Budget recurring model evaluation as an operating cost. ### Coverage of the actual change Every candidate needs a mapping from changed behavior to the checks that exercise it. A contributor's label does not establish the scope. The controller compares the actual source, dependency, deployment, model, prompt, and permission changes with the adopted classification rules. U02 opens the coverage task and identifies likely affected behavior. If code has not been written yet, its output is a preliminary evaluation requirements. U06 verifies the exact implementation diff before merge. A full candidate requires a coverage decision from a qualified council assigned separately from its author and scope approver. If U02 already assessed the same exact diff, U06 can reuse that decision after checking its references. The coverage council reads the actual changes and identifies each affected behavior, the relevant existing tests, new tests or integration checks needed, and behavior the available tests cannot establish. Network access, secret handling, model settings, prompt changes, and permission changes deserve explicit treatment. A passing corpus run cannot demonstrate that an unrelated new outbound connection is harmless. The decision either establishes adequate checks for the specified scope, requires additional evidence, or leaves a gap unresolved. Missing coverage prevents merge eligibility. A policy change can alter requirements through F9, but the council cannot disguise that change as a passing test. Once the required checks are established and pass, no second coverage opinion is required at U12. Targeted candidates can use published mechanical classification rules without a council task. The founding rule permits targeted evaluation only for changes whose limited effect can be established through those rules. Unknown paths, changed dependencies, or uncertain behavioral effects escalate to full evaluation. Later rules can permit more targeted changes after their scope checks have been demonstrated. A material revision invalidates affected coverage evidence. U07 checks combined contributions against the actual merged tree so individually acceptable changes do not bypass examination of their interactions. ### Evaluation cost Measure the first complete evaluation before adopting it as a repeatable production requirement. Record model calls, retries, live trials, attack-search work, runner time, evidence storage, hosting, council work, and cost of the challenge and recovery allowance. Report cost per attempt and per accepted release so repeated failures remain visible. The release-policy decision includes that measurement, a funded per-attempt limit, and a recurring evaluation budget. Test a provider-price increase or failed-attempt scenario before committing the budget. If the required checks exceed the allowance, keep the attempt incomplete and change funding or future policy through its proper authority. Do not remove a check midway through a failing run to make the bill fit. Token trading receipts are not required to fund the first rehearsal. Any actual compute source can fund it under a bounded authorization. Record that source without assuming it is a founder contribution. ### Council qualification An agent council is a group of authorized AI evaluators assigned to a question that requires judgment. Qualify each council for its intended work before granting it authority. Its benchmark should include real changes, planted defects, harmless changes, ambiguous policy cases, false positives, and attempts to influence its own permissions or evaluation rules. Qualification can run offline. Record missed defects, false rejections, abstentions, cost, and repeatability. Use cases the council has not simply memorized from its qualification training. Different model brands do not prove independent reasoning or independent key control. Governance grants the assignment after the council meets the adopted criteria. The assignment defines the agreement rule, treatment of disagreement, deadline, replacement route, and appeal authority. The council cannot expand its own powers or lower its own qualification standard. A replacement council can offer an explicitly accepted cost or performance tradeoff while still meeting mandatory criteria. Treat source code, submitted reports, and tool output as untrusted input. A sentence inside a contribution cannot change a council's system instructions or grant a tool permission. Test those attacks against the actual tools and decision interface before the council receives authority. The decision interface separates trusted instructions from submitted material. Tools produce a structured inventory of changes and evidence references. The council can inspect the underlying raw diff and source as untrusted attachments. A summary is a navigation aid and cannot replace inspection of a sensitive change. Tool output can also contain hostile text, so its format alone does not make it safe. Require a typed output containing the assignment, exact target, question, disposition, required checks or corrections, evidence references, reasons, and permitted effect. Reject invalid fields and effects outside the assignment. The council has no general shell, treasury, or release permission merely because its output can influence a decision. Assign benchmark maintenance to an evaluation maintainer distinct from the council being qualified. That role rotates planted defects, creates fresh variants, controls private benchmark access, and records which cases have been exposed. Requalify after a material model, prompt, tool, or council-configuration change. Budget benchmark maintenance and requalification as recurring operations. During founding operation these roles can share an operator, which provides task separation without proving independent control. Human specialists can receive defined audit or investigation assignments. A human admission exam and a fixed number of human comparisons are not prerequisites for the automated release path. ## 6. Ordinary verifier updates F1 covers a normal change under an established verification policy. New policy meaning, incompatible schemas, and changes to DAO authority branch into F9 before they can become operative. Deploy the candidate for isolated testing before starting its release challenge clock. Members need something reproducible to examine. Requiring them to challenge an unimplemented idea and then offering no challenge opportunity for the resulting code would protect the wrong decision. ### U01 through U07: submission to frozen candidate | Step and resulting state | Work and depth | Required action and successful next step | Other branches | | ----------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | U01. `SUBMITTED` | S + C, none | Contributor submits the target domain, change, evidence references, and authenticated identity. Controller checks completeness, duplicates, and submission limits. Go to U02. | Malformed material becomes `NEEDS_INPUT`. An unchanged duplicate links to the existing case. A prohibited submission is rejected. Unanswered requests for input expire. | | U02. `CLASSIFIED` | C with scoped J, targeted | Inspect affected components and classify the proposed change. Open its coverage task. A full candidate needs a council coverage decision on the actual diff by U06. Record corpus, schema, policy, and compatibility dependencies. Go to U03. | Uncertain scope escalates to full evaluation. An unwritten implementation receives only a preliminary specification. A policy dependency enters F9. Rejection, withdrawal, or dependency timeout closes the attempt. | | U03. `WORK_AUTHORIZED` | J + X, targeted | Maintainer accepts the scope, resource allowance, and any paid quote. For paid work, reserve the accepted commitment. Record contributor agreement to the terms. Go to U04. | Unpaid work skips contributor compensation but still needs compute authorization. Insufficient budget becomes `WAITING_FOR_BUDGET` with a deadline. Changing the quote requires agreement. No accepted obligation is invented from a repository push. | | U04. `IMPLEMENTATION_SUBMITTED` | S + C, targeted | Contributor completes the assignment or supplies work already prepared. Controller records the exact revision and links any proposed cases. Go to U05. | Missing work returns to the contributor. Changes create another revision. The work deadline leads to an agreed extension or cancellation, preserving accepted milestones. | | U05. `CORPUS_VALIDATED_FOR_TESTING` | C + J, targeted or full | Reuse the existing corpus or validate the changed cases against the policy. A corpus council decides new expectations and weakenings. Identify a fixed corpus version for this candidate. Go to U06. | A mislabeled case returns for correction. A policy change returns to F9. A proposed corpus change can be accepted for candidate testing while its activation still waits for the challenge process described below. | | U06. `MERGE_ELIGIBLE` | C, plus required J for full candidates, targeted or full | Check the exact diff and resulting evaluation requirements. Full candidates require the scoped coverage decision. Targeted candidates require proof that the mechanical classification rule applies. Run required implementation checks. Passing all requirements permits U07. | Missing coverage blocks eligibility. Failed behavior returns to U04. A changed diff repeats affected coverage and checks. A council cannot waive a required failure under the unchanged policy. | | U07. `CANDIDATE_FROZEN` | X + C, none | Executor merges the authorized revision or assembles accepted revisions. Verify the resulting source tree. Record the exact code, model, configuration, corpus, and applicable rule versions. Go to U08. | A conflict or rebase that changes evaluated content returns to U06. A competing release may require a new base and evaluation. Merging does not make production use this candidate. | U05 has two distinct effects. It establishes a defensible expectation for testing the candidate. It does not let an unchallenged change to the exam quietly become the new production standard. For a corpus change coupled to F1, use the same release challenge window to challenge both the code and its proposed exam. Activate the corpus version with the successful release. A standalone F2 update gets its own scoped activation window. Use one shared window for coupled code and corpus changes. Publish every removal, relaxed threshold, and changed expected result as a separate item with its policy reason. The shared window lasts at least the longer of the release and corpus durations. Coupling a weakening to a patch cannot shorten its challenge opportunity. The implementation must distinguish candidate-use permission from corpus activation. Existing production releases retain the corpus and policy history under which they were accepted. For a policy dependency at U02, F9 can authorize implementation and candidate testing of the proposed rule before making it operative. That authorization releases the dependency. Final activation still requires the linked policy and implementation conditions. Requiring the unbuilt policy to be active before its implementation can begin would create a circular dependency. ### U08 through U17: testing to completion | Step and resulting state | Work and depth | Required action and successful next step | Other branches | | --------------------------------- | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | U08. `TEST_DEPLOYMENT_AUTHORIZED` | C + X, targeted | Check the candidate's build identity, provisioning budget, and test-only permissions. Authorize any registration needed for testing without granting production credential authority. Go to U09. | If clients or contracts cannot distinguish this test deployment from production, fix that prerequisite before exposing it. Authority or funding failures enter F10. | | U09. `TEST_READY` | X + C, targeted | Provision the candidate, register its test identity, and verify reachability and isolation. Confirm that it cannot issue credentials accepted as production credentials. Go to U10. | Failed provisioning retries within its budget. An isolation failure disables the test endpoint and returns to U08. A prolonged outage closes or reschedules the attempt. | | U10. `BASELINE_EVALUATED` | C, full or targeted | Run all baseline tests required by the classification. Store authenticated evidence for the frozen target. Compute pass, fail, or incomplete under the configured rule. Go to U11 on pass. | A real test failure returns to U04 or rejects the candidate. Missing output enters recovery, not pass. Fixed rerun rules handle model variation without choosing only favorable runs. | | U11. `CHALLENGE_OPEN` | X + O, none | Publish the exact candidate, coverage decision, results, and separately listed corpus changes. Verify the public and any confidential challenge access. Start the applicable window using founding or member eligibility. Continue prescribed attack testing. | C01 receives challenges and C02 qualifies them. A factual failure blocks directly. Missing required access stops qualifying time. A material correction returns to U04 and reopens the window for the changed target. | | U12. `RELEASE_ELIGIBLE` | C, none | At the end of the valid window, check all required evaluation is complete, no blocking challenge remains, and the target and policy references still match. Go to U13. | Incomplete work waits within its deadline. A material revision returns to U04 and repeats the applicable validation, freeze, evaluation, and challenge steps. An unresolved case cannot advance by timeout. | | U13. `PROMOTION_QUEUED` | C + X, none | Register the exact action hash, candidate and evidence references, predecessor, rule version, and expiry in the promotion controller. Confirm registration and wait the controller-enforced delay. Go to U14. | A revoked key, changed authority epoch, pause, cancelled proposal, or stale predecessor invalidates execution. Unknown queue writes enter reconciliation. | | U14. `APPROVAL_CONFIRMED` | X + C, none | The authorized attested executor rechecks off-chain requirements and submits the queued action. The promotion controller checks its on-chain conditions and calls the registry. Confirm the intended registry state before U15. | Missing off-chain evidence blocks signing. Contract rejection returns to the failed condition. Unknown outcome enters reconciliation. Routine execution uses no founder countersignature. | | U15. `PRODUCTION_ACTIVE` | X + C, targeted | Route production use to the authorized candidate and verify endpoint, version, and credential behavior. Record the actual activation time and start relevant contribution-observation milestones. Go to U16. | Partial activation enters incident or deployment recovery. Keep service on a still-approved predecessor where allowed. Otherwise pause the affected operation. Do not label a partially switched service healthy. | | U16. `OBSERVING` | O + C, targeted | Monitor the release, maintain the usable fallback, and collect the post-activation evidence required by policy and payment terms. | A defect starts F4 or F5. Payment attribution is decided in F6. Monitoring failure is incomplete observation, not evidence of good behavior. | | U17. `RELEASE_COMPLETE` | C + X, none | Complete the deployment handover and retention tasks. Close unused candidate resources. Record the release outcome and continue ordinary production monitoring. | Payment cases and later incidents can remain open under their own identifiers. Closing the deployment attempt does not erase unpaid obligations or prevent later reports. | The release classification can reduce the test scope for a limited change. It cannot remove the checks needed to establish which version is being deployed or who authorized it. Full and light paths share the same logical states and differ in their evidence requirements. ### Promotion condition The final promotion executor at U14 applies the following conjunction. U12 establishes evaluation and challenge eligibility. U13 queues the authorized action and satisfies any remaining execution delay. The delay does not have to be complete merely to enter the queue. The following pseudocode defines the promotion condition: ```text promotion_allowed = exact_candidate_is_identified and applicable_policy_is_valid and required_tests_pass and required_evidence_is_available_and_authenticated and required_judgments_are_resolved_if_any and valid_challenge_window_is_complete and no_blocking_challenge_or_incident_is_open and required_execution_delay_is_complete and production_transition_is_currently_authorized ``` If no step requires substantive judgment, `required_judgments_are_resolved_if_any` adds no council task. A successful report does not create transaction authority on its own. The controller evaluates the complete rule and the executor acts within the authority already granted to that workflow. ### Full and targeted examples A model replacement enters U01 with its intended behavior and cost. U02 assigns full evaluation. The contributor supplies the model settings and any separately identified cases. After the merge checks, U07 freezes the candidate. U09 verifies isolated test access. U10 runs the required live and fixed tests. Members can challenge the results during U11. If the required work passes and the valid window completes, U14 confirms production authorization and U15 switches the serving version. A linked contribution holdback begins at its agreed observable-use milestone. A documentation correction that does not change the build can finish after its own acceptance checks and compensation milestone. It need not manufacture a production release. A limited diagnostic change that does produce a new build can use targeted evaluation if classification establishes that verifier behavior and trust checks remain unchanged. It still passes through candidate identity, deployment, challenge, and production authorization requirements. The light path reduces relevant test scope, not the meaning of production approval. ## 7. Signatures and execution Signatures have different jobs. Submission authentication identifies who requested work. An evidence signature identifies the runner and the facts its evidence process attests to. A decision authorization identifies the role permitting a scoped action. A transaction signature authorizes a particular on-chain operation. A confirmed execution record establishes what actually happened. A worker does not need to publish an on-chain transaction for every observation. It does need authenticated, attributable records wherever the controller relies on its work. An externally supplied signature is useful evidence only within the permission assigned to its issuer. The requirements below specify the role that must provide each authorization. The founding arrangement uses the scoped controller and executor described below. Adopt the concrete keys and profile before operation. Adding human signatures solely because the executor is an agent would contradict the automated model. | Step | Evidence and authorization | Signature or confirmation | Wait and intervention | | ---- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | U01 | Complete submission and identity reference. | Authenticated request, which may use the repository's accepted identity mechanism. | No challenge window. Contributor supplies missing information. | | U02 | Actual affected paths where available, compatibility, classification, and preliminary coverage requirements. | Controller record and scoped coverage assignment for a full candidate. | An unimplemented specification cannot supply final diff evidence. Required policy decisions use F9. | | U03 | Accepted scope, quote, resource budget, and available reserved funds. | Authenticated contributor acceptance and maintainer authorization. A reservation transaction if that is where the budget is enforced. | No extra vote or challenge window for spending already delegated within the approved budget. New budget authority uses F8. | | U04 | Exact implementation revision and task references. | Authenticated submission record. | Work deadline applies. Contributor action supplies the implementation. | | U05 | Case inputs, expectations, policy reasons, and weakening classification. | Corpus decision from the assigned authority where needed. Existing unchanged cases retain their version reference. | No mandatory additional serial window for cases coupled to this candidate. Policy changes use F9. | | U06 | Exact diff, required checks, full-candidate coverage decision or valid targeted classification, and resolved scope gaps. | Runner evidence, scoped council coverage decision for full candidates, and controller merge authorization. | Missing coverage or failed checks block merge. No additional release-verdict task. | | U07 | Authorized revision and verified resulting tree. | Repository execution receipt and immutable candidate references. | No extra delay. Changed merge content requires re-evaluation. | | U08 | Build identity, permitted test capabilities, spending allowance. | Deployment authorization and any required registry transaction signatures. | An admission delay applies only if the governing authority rule requires it. No general production approval is granted here. | | U09 | Deployment identity, reachability, and isolation checks. | Authenticated deployment and registration results. | Bounded provisioning retries. No member clock yet. | | U10 | Required outcomes, complete run set, provenance, and fixed target. | Authenticated runner evidence and any required enclave or provider evidence. | Evaluation period. A model outage enters recovery. A failed test does not become a discretionary pass. | | U11 | Accessible exact candidate and evidence, separate corpus-change notice, and working challenge route. | Window-opening event and authenticated challenges under the current founding or member rule. | Count qualifying access time only. Member voting need not be active during founding operation. | | U12 | Complete evaluation, expired valid window, resolved challenges. | Controller eligibility record tied to the candidate and rule version. | Missing prerequisites continue to block. No additional universal council signature. | | U13 | Exact action payload, evidence references, predecessor, rule version, expiry, and current authority epoch. | Executor queue transaction and confirmed controller state. | Founding operation queues after U12 and waits its configured execution delay. Safe overlap requires a later adopted rule. | | U14 | Complete off-chain predicate and controller-enforced queue, delay, authority, pause, and exact-target conditions. | Attested executor transaction and confirmed registry state. | No routine founder signature. Revoked or stale authorizations fail even after the timer expires. | | U15 | Expected live version, valid production authorization, and endpoint checks. | Authenticated routing result and activation confirmation. | Bounded activation checks. Failure invokes recovery or incident handling. | | U16 | Live-use evidence, monitoring, and milestone facts. | Attributable observations and any payment-condition decision. | Post-activation observation. Incident intervention occurs only on its defined trigger. | | U17 | Resource cleanup, retained reproduction evidence, and handover completion. | Completion record. | No new challenge window. Linked payments and incidents retain their own states. | The exact action should identify the target and permitted effect. Permission to pay an accepted reward cannot authorize a different recipient or amount. Permission to register a test build cannot authorize a production release. The executor must check current authority again if permissions changed while the job was queued. The sequence above queues promotion after U12. Overlapping the execution delay with U11 is an optional optimization only if the mechanism still prevents execution until all U12 conditions hold. An early queued transaction must not become executable merely because its own timer ends. ### Promotion authority Use a dedicated promotion controller as the registry owner for the automated route. Admit a narrowly scoped executor key to that controller under the attestation and role policy. Bryan's founding key initializes and recovers authority. It does not countersign ordinary U14 transactions. The current repository's [version registry](/handbook-sources/EpocheVersionRegistry.sol) restricts release approval to its owner. That code fact does not establish which address owns a deployed instance. The required controller and ownership migration must be implemented and verified before claiming unattended promotion. | Check | Enforcement location | | ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Caller is an admitted executor with current, unexpired authority | Promotion controller checks the role and authority epoch. Admission verifies the worker's expected code and attestation before granting the role. | | Exact proposed operation | Controller checks a committed action containing chain, target registry, function, full release payload, predecessor, rule version, and a single-use identifier. No arbitrary-call permission. | | Registration and notice delay | Controller records queue time, earliest execution, and expiry. Registration alone does not authorize immediate execution. | | Cancellation, pause, or authority replacement | Controller rejects cancelled, paused, stale, or consumed actions. An authority change invalidates queued work under the old epoch. | | Tests, coverage, evidence access, and qualifying challenge time | Attested executor checks the authoritative records before queueing and again before signing execution. Evidence hashes make those records identifiable. They do not make the contract interpret their contents. | | New blocking evidence | State controller prevents eligibility and the executor refuses to sign. Authorized cancellation or guardian action records an on-chain block where needed. | | Actual production permission | Executor confirms the registry result after the controller executes. U15 separately confirms the serving version and credential behavior. | The normal controller can call only the permitted registry approval operation with the frozen payload. Guardian pause and revocation routes have separate permissions. Payment and rule amendments use separate authority. Recovery can revoke or replace an executor, and must not silently substitute an arbitrary release payload for a queued one. This split trusts the admitted executor's enforcement of off-chain facts. A compromised executor might assert false results unless another enforced constraint stops it. Attestation admission, restricted code and tools, current-role checks, evidence retention, challenges, and recovery reduce that risk. A hash on-chain does not prove test execution or an honest coverage judgment. If the controller cannot reliably cancel a queued action on new blocking evidence, it must not admit that action for unattended execution. The founding route disables prequeueing during U11. A future overlap optimization must retain the full eligibility check at execution and an effective cancellation path. ### Where contributions from others enter People and independent agents can add observations from U01 onward. Before freezing, those observations can improve the implementation or case selection. During U11, an observation can support a formal challenge. After production activation, it can become a defect report or incident input. Counter-assessments are supporting evidence. Their existence does not automatically pause a release or assign their author a fee. The submitter must use the applicable challenge or commissioned-work route to obtain those effects. An ordinary discussion comment can remain a comment. Required DAO workers sign evidence or execute actions at the stages assigned above. Member silence is relevant only to a valid challenge window. Silence from a required runner, decision-maker, or signer means missing work and triggers recovery. It cannot satisfy a required authorization. ### Requirements across flows The same authentication rules apply to the T, C, K, E, P, B, R, A, G, and H steps below and to payment-state transitions. Each submission authenticates its source. Each authoritative computation records its runner and evidence. Each discretionary decision authenticates the assigned authority and permitted effect. An off-chain executor verifies that authorization before acting. A contract executor supplies the required transaction signatures and confirms the resulting state. An observation requires an attributable record rather than a transaction merely to prove someone observed it. Each flow table identifies additional waits and intervention. A row with no new window still obeys its job deadline and any delay required by the permission it exercises. Retry allowances and recovery outcomes follow section 18. ## 8. Corpus updates F2 changes the collection of test inputs and expectations. Record code changes and corpus changes separately even when they belong to the same fix. A correct implementation can expose a mistaken test, so changing an expectation is allowed when its policy reason is explicit. | Step | Work and depth | Required actor, evidence, and transition | Failure or wait | | -------------------------- | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | T01. Submit | S + C, none | Contributor supplies case inputs, expected results, policy references, provenance, and requested payment if any. Controller authenticates the submission. | Incomplete cases return for correction. Private material without permission cannot enter the public corpus. | | T02. Classify | C with conditional J, targeted | Controller identifies new coverage, duplicates, removals, relaxed thresholds, or changed expectations. Maintainer accepts any funded scope through F6. | Duplicate coverage can be rejected or credited only for additional value. Unclear policy moves to T03. | | T03. Validate expectations | C with conditional J, targeted or full | Corpus authority checks schema and reproduction. The assigned council decides new or disputed expectations against the policy. Record a case decision. | A mistaken expectation returns to T01. New policy meaning branches into F9 before operative use. | | T04. Freeze for testing | X + C, targeted | Corpus executor records an immutable proposed version and candidate-use permission. Runner evaluates its cases against relevant verifier versions. | An actual production-policy failure starts F4 or F5. Missing evidence enters F10. | | T05. Open challenge | O, targeted | Controller publishes accessible case evidence and the proposed effect. For a coupled update, use U11. Otherwise open the corpus activation window. | C01 through C05 handles qualifying objections. Unavailable evidence stops the access clock. | | T06. Authorize activation | C, targeted | Controller checks accepted expectations, complete required evidence, applicable policy, and no unresolved blocker after the valid window. | Material changes repeat relevant validation and challenge opportunity. Unresolved cases close without activation. | | T07. Activate | X + C, none | Authorized executor updates the canonical corpus reference and confirms it. Coupled changes activate with the identified release. | Reconcile an uncertain write. Do not announce a version active merely because the job was submitted. | | T08. Record completion | C + X, none | Controller preserves case attribution, old corpus versions, and accepted payment milestones. | Payment failures continue in F6 without undoing the accepted case history. | A standalone corpus version can govern future candidates while production continues under its recorded release history. It does not retrospectively claim that an older release passed new tests. If the new case demonstrates an existing policy violation, treat that finding on its merits through the defect or incident flow. The public and held-out portions of a corpus both need versioned expectations and a permitted evaluator. Members must receive enough evidence and access to exercise the promised challenge right. Where a private exploit prevents ordinary disclosure, the policy must identify confidential access or authorized reproduction and how the case can be challenged. Do not count a nominal public window when its essential evidence is inaccessible. An embargo temporarily withholds exploit details while the DAO contains a defect. Record who can access the evidence, what ends the embargo, the maximum withholding period, and who can authorize an extension. A retained private reproduction copy and public disclosure are separate decisions. Publish a sanitized regression case when its disclosure conditions hold. ### Confidential case examination Use a published confidential examination rule for held-out or embargoed cases. Commit to each case's input, expected result, policy reference, and a random secret value before the candidate evaluation. Including that secret value makes guesses about a short hidden input harder to confirm from the public hash. Keep the exact package available to the authorized evaluators and record the commitments in the corpus version. The public record supplies the relevant policy, a sanitized account of the behavior, evaluation method, observed result, case commitment, and any limits on public reproduction. Members and founding participants can submit counterexamples or challenge the policy interpretation through C01 without receiving all hidden inputs. Before U11, assign a confidential examiner separately from the case author and original decision-maker. The examiner must be able to inspect the committed inputs and reproduce the disputed result against the exact candidate. It returns an authenticated case decision with a public explanation and restricted evidence where disclosure remains unsafe. Its qualification and appeal rules follow the ordinary scoped council process. This provides a narrower public challenge right than disclosure of every case. Publish that limitation. Do not claim a commitment alone lets the public verify the expected result. During founding operation, separate assignments can remain under one operator, so confidential examination is not proof of independent institutional control. If required confidential access or reproduction capability is unavailable, the confidential requirement remains incomplete and the applicable challenge clock stops. Define the access class when accepting the case, before its result is known. A maintainer cannot conceal a failed public case by changing its access class during the release. Rotate exposed holdouts and budget fresh variants. Disclosure follows the exploit and credential-exposure rule, not automatic reveal on activation. An unresolved live exploit can still make publication unsafe after a new version is deployed. Retain the separate embargo deadline, extension authority, and sanitized-publication obligation. ## 9. Challenges and appeals Use one recorded case per challenge, linked to the exact target and rule. Its scope determines whether it can block a release, contest a payment amount, or only request a correction to records. | Step | Checks and action | Result or failure | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | C01. Receive | Authenticate the submitter, identify the target and claimed error, and check completeness and duplicates. | Complete submissions go to C02. Missing details return to the submitter with a deadline. An observation without a requested decision remains nonblocking. | | C02. Qualify | Apply the published eligibility rule. Reproduce a supplied example where practical. Establish whether the claimed expectation follows from the existing policy or requires judgment. | A demonstrated required-test failure blocks eligibility directly. A qualifying interpretive challenge goes to C03. Unsupported or ineligible submissions receive a recorded disposition. | | C03. Pause and assign | Record the affected transition as blocked and assign an authorized challenge council separate from the disputed decision's author. | The appeal job has a deadline and a permitted replacement assignment. Lack of participation enters recovery. It does not count as rejecting the challenge. | | C04. Decide | Examine the specific claim and evidence. Apply the bounded appeal process already discussed. | Uphold the challenged outcome, require correction, or record an unresolved case. Losing an argument is not automatically abuse. | | C05. Apply | Controller checks the decision's authenticity, scope, and effect. Executor performs any authorized record or permission change. | Upheld acceptance returns to the parent flow after its remaining conditions hold. Correction requires a new relevant candidate revision. An unresolved release case closes the attempt without promotion at its deadline. | The original challenge window need not restart after a rejected challenge when members already had the full required access and the candidate is unchanged. It also must not become shorter because evidence or the endpoint disappeared while the case was open. Record actual qualifying access time. Before closing the window, reconcile the intake record through its cutoff time. A complete, specific challenge received before that cutoff must receive its C02 disposition before U12 can finish. Give qualification the profile's decision deadline and bounded replacement allowance. A malformed submission or unchanged duplicate receives its mechanical disposition without reopening the window. If a timely substantive case remains unresolved after its permitted assignments, close the candidate attempt. A processing backlog cannot turn an unanswered challenge into consent. An accepted challenge that changes code, expectations, or release requirements requires the relevant earlier steps again and a renewed opportunity to examine the changed target. Duplicate challenges share the underlying case where appropriate. New substantive evidence remains admissible, including through F5 after a release is live. The founding eligibility and deadlines appear below and in section 20. Later member rights use the governance amendment procedure. One authenticated reporter can submit a demonstrated serious defect without a second account. The assigned runner checks reproduction and the policy expectation. During founding operation, the published qualification rule below also accepts interpretive submissions. Later membership rules can define additional intervention rights without treating account count as proof of independence. ### Founding challenge eligibility The founding window is open to any authenticated participant. A stable pseudonymous signing identity is sufficient for intake. Neither a token balance nor contribution voting weight is required to submit a factual or interpretive challenge. C02 checks completeness, target, duplication, and whether the evidence alleges a specific unmet requirement or policy error. A runner verifies reproducible claims. A separately assigned qualified council decides the admissibility of interpretive claims under the founding rule. A bundle does not verify itself, and authentication does not establish its conclusion. A demonstrated required failure blocks directly. A qualifying interpretive challenge receives its scoped pause and independent task assignment. General disagreement without an identified requirement remains nonblocking discussion. Publish rejection reasons and allow the ordinary appeal of a qualification decision so intake authority cannot quietly suppress every objection. Bryan appoints the initial qualification and challenge assignments through founding authority. Their rules work before contribution-based membership exists. Replacement after a missed deadline follows the preauthorized recovery rule. If an unresolved blocking question cannot be decided by the allowed assignments, close the candidate attempt without promotion. The system must demonstrate that these routes can receive, qualify, and decide a real challenge before opening a founding window. Publish notices to the designated public channel and provide the applicable evidence access. Do not require someone to object before a valid window may finish. Low participation still limits the scrutiny the window receives, so baseline tests, coverage examination, and prescribed adversarial work remain required. ### Finality and abuse Use one ordinary appeal with a separate assignment and a decision deadline under the founding profile. Record the initial authorities before enabling blocking challenges. Repeating a rejected argument does not create a new appeal. A new reproducible defect can still enter incident handling. The challenge decision must identify the disputed claim and the consequence it permits. A payment challenge can reserve a contested amount without pausing an unrelated release. An active defect can block the affected release before its reporter's reward is decided. Keep contributor deposits and challenge bonds disabled unless governance adopts a specific abuse-control rule. Losing a reasonable challenge does not establish abuse. Any forfeiture or restriction must name the prohibited conduct, evidence, affected permission or money, and appeal route. ## 10. Credential operations F3 applies an already approved verifier to an individual request. It shares domain policy and infrastructure with release work. It does not open a member challenge window for every customer review. | Step | Work and depth | Required actor, evidence, and transition | Failure or wait | | ------------------------ | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | | K01. Receive request | S + C, none | Customer or authorized client supplies the operation, domain, input references, and authentication. Service controller records a unique request. | Invalid input returns a specific error. Duplicate delivery retrieves the existing request. | | K02. Check prerequisites | C, targeted | Service checks the required release authorization, credential dependencies, input schema, and secure submission requirements for that operation. | Invalid prerequisites reject the operation. Unavailable current trust information produces an unknown or incomplete result. | | K03. Authorize resources | C + X, none | Billing checks the accepted service quote and available credit or payment. Controller reserves the needed job resources. | Insufficient funds wait or expire under service terms. Retry cannot charge the same request twice. | | K04. Perform operation | C, operation-specific | Authorized verifier, builder, or runtime worker performs the identified checks against fixed request inputs. | A policy failure produces a failing result. A worker or inference outage enters F10 and remains incomplete. | | K05. Authenticate result | C + X, targeted | Authorized evidence producer signs the result and its exact input, release, policy, and output references. | Inconsistent references or missing execution evidence block issuance. | | K06. Record or register | X + C, none | Authorized service executor submits any required on-chain record and confirms the intended state. | Unknown transaction outcome enters reconciliation. A test identity cannot register a production-accepted result. | | K07. Return and account | X + C, none | Service returns the actual result, finalizes the agreed charge, and records any automatic remedy. | Failed delivery can retry using the same result. F7 handles credits or refunds under the applicable terms. | Evaluation depth at K04 follows the product operation. It is not the DAO's full-versus-targeted release classification. | Operation | Output and dependency | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Domain code review | A signed result or credential stating whether the submitted code meets the named domain's policy under the identified verifier release. One operation per domain; see the certification-domain register below. A pass in one domain cannot substitute for another. | | Build verification | Evidence connecting the reviewed source to the built image. It depends on the applicable prior review and build checks. | | Runtime registration | A record connecting an instance and its signing key to the admitted image and required runtime evidence. | | Credential checking | A valid, invalid, or unknown result after checking the required evidence and current registry facts. This operation does not issue a new credential or require a service charge by default. | Each implemented operation needs its exact output schema and dependency checks. A signed code assessment, a build proof, and a runtime registration establish different facts. Clients must check the chain of facts required for their use rather than treating any signed record as a complete substitute. ### Certification-domain register Seven domains exist. Each is an independently selected review with its own profiles, rule block, corpus directory and semantic policy. They are **peers**: no domain implies another, no combined result is issued, and a domain that was not requested is reported as not evaluated rather than omitted. Governance consequences follow at the end of this subsection. | Domain | Protocol id | Profiles | Rule block | Corpus | | ----------------------- | ----------------------- | ------------------------------------------------------------------------------------------ | --------------------------------------------- | ----------------------- | | Execution Integrity | `safety` | `typescript.precise.v1`, `python.precise.v1`, fallback `generic.semantic.v1` | `EPC-0xx` (shared: every profile takes these) | `safety` | | Privacy Integrity | `privacy` | `typescript.privacy.v1`, `python.privacy.v1`, `typescript.privacy.v2`, `python.privacy.v2` | `EPC-1xx` | `privacy` | | Accreditation Integrity | `accreditation` | `typescript.accreditation.v1`, `python.accreditation.v1` | `EPC-2xx` | `accreditation` | | Strategy Substance | `strategy-substance` | `typescript.strategy.v1`, `python.strategy.v1` | `EPC-3xx` | `strategy-substance` | | Capital Integrity | `capital` | `typescript.capital.v1`, `python.capital.v1` | `EPC-4xx` | `capital` | | Historical Robustness | `historical-robustness` | `typescript.historical.v1`, `python.historical.v1` | `EPC-5xx` | `historical-robustness` | | Accredited Custody | `accredited-custody` | none | none | none | Protocol ids and profile ids are frozen. A profile's policy version is a hash of its definition, so renaming one orphans every credential issued under it. Execution Integrity therefore keeps the id `safety` and the profile suffix `precise` although its published name is Execution Integrity; the rename is presentation only. Rule ids are equally permanent: a rule that stops applying is retired in place rather than renumbered, because finding ids appear in issued credentials. A profile takes the shared `EPC-0xx` rules plus the rules scoped to its own domain, and nothing else. That filter is what lets a new domain add rules without moving any existing profile's policy version, and it must stay exact. | Domain | What a pass establishes | What it does not establish | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Execution Integrity | Complete source inventory, reproducible pinned dependencies, no embedded credentials, no unresolved dynamic code, declared network destinations and authority, completed semantic review, and a result for every declared invariant | That the code is safe, correct or scam-free, or that its financial behaviour is acceptable | | Privacy Integrity | Input-derived logging, direct persistence calls and outbound destination declarations were checked within the recorded limits | Leak-proofing, non-retention, regulatory compliance, or absence of covert channels | | Accreditation Integrity | Every capital-admission path found by the review routes through the declared verification, and failure is fail-closed to non-admission | That any investor is accredited, that an offering is lawful or exempt, that anti-money-laundering controls were evaluated, or that capital cannot be received — a token transfer is a push and cannot be declined | | Strategy Substance | A decision procedure exists, declared signals are consumed, the action space matches, declared risk controls are implemented, and delegation is declared | That the strategy is good, original or likely to profit. There is no score, grade or ranking | | Capital Integrity | Beneficiaries, strategy-supplied execution detail, operations outside the declared mandate, budget durability, owner recovery and reference integrity were checked against the mandate | A ceiling on loss or theft, that the enforcement framework is running, that the deployed account matches the reviewed source, or that counterparties are unaffiliated | | Historical Robustness | The committed harness evaluates the procedure the agent trades with, and reported numbers follow from it under stated assumptions | Any statement about future performance, that the dataset is truthful, or that overfitting was assessed | | Accredited Custody | Delivered as a field on the Accreditation Integrity report rather than a separate credential | — | Every domain's credential carries machine-readable limitation codes naming what its analysis could not reach. Those codes are part of the claim rather than a footnote to it: a credential that omitted them would assert more than its review established. Three outcome rules apply across every domain and are not negotiable per domain. A supported violation of an applicable mandatory requirement is a failing result. Essential evidence that cannot be obtained — an unreachable registry, an RPC outage, an unresolved disagreement — is inconclusive, never a finding against the submitted source; both withhold the credential. And zero recognised analysis targets is inconclusive or not-evaluated, never a pass: a review that reached nothing must not be reported as a review that found nothing. ### Governance consequences of the domain set Corpus versions, case routing and confidential-case access are scoped per domain under F2. Seven domains means seven governed corpora, and the qualification question is per domain rather than global: a participant qualified to decide an Execution Integrity case is not thereby qualified to decide a Capital Integrity one. There is no qualified pool for the newer domains and there will not be one when they first issue. The operating rule during founding is that a domain with no qualified participants routes to the owner, each decision records that it did so, and a published qualification rule replaces the fallback once a pool exists. A governance record that implied a qualified council existed would be fiction, so the fallback is stated rather than assumed. Two domains carry external dependencies the DAO does not control. Accreditation Integrity depends on an accreditation issuer whose determination the review verifies but never evaluates, and its claim language needs counsel input before issuance rather than after. Capital Integrity's full claim is available only on the approved enforcement implementation; a source review alone establishes the behavioural half and its limitation codes say so. ### Per-domain pricing is a DAO parameter A review's price is set by the DAO and held on chain in [DomainPriceRegistry](/handbook-sources/DomainPriceRegistry.sol), not as a platform constant. A Capital Integrity review with chain reads, simulations and adversarial tests is not the same product as a basic source review, and pricing it identically was an artifact of there having been one kind of review. Three properties matter for governance. An unpriced domain **reverts** rather than quoting zero, because zero is a real price meaning free and a registry returning it for an undecided domain would give that domain's reviews away. Price changes are **timelocked**, so an integrator sees one coming instead of being repriced between reading a price and acting on it. A matured change is applicable by **anyone**, because the delay is the control and requiring the proposer to return would make the effective price depend on who was paying attention. Quotes are pinned: a caller receives a price with an expiry and settles against that quote, so a governance change reaches the registry and never work already accepted. This is also the second reason the measured reviewer reads chain state itself — the price must be read from somewhere, and a reviewer that already reads the chain needs no second path. ### Trust and compatibility Production permission must agree across the verifier, deployment registry, credential registry, clients, and contract consumers. Test admission cannot grant production issuance. A credential reader must apply relevant release distrust and individual revocation rules when checking current validity. Define what existing credentials mean after a release is superseded, paused, distrusted, or permanently revoked. Stopping new issuance does not by itself specify the validity of past credentials. Unknown registry state must remain unknown where a fresh check is required. A compatible schema addition can use F1 with the appropriate checks. A change that alters credential meaning or breaks readers requires an F9 migration decision. Publish the new schema version, accepted reader versions, activation conditions, and treatment of old records. Test old and new readers before activation. A new schema must not silently reinterpret an old credential. Capital Integrity has opened, and the rule that anticipated it still governs: enforceable limits must live in the systems that spend or hold funds. A favorable code review alone cannot enforce a spending limit in another contract, which is why the domain's full claim requires the approved enforcement implementation and why a source-only review records that limitation in the credential. ## 11. Incidents and emergency patches Emergency work is a distinct route with preauthorized powers and shortened exposure to delay. It still requires evidence that the proposed fix addresses the incident and does not give its executor unrestricted release authority. Bounty adjudication does not need to finish before containment. A report can demonstrate a serious defect even when its reporter's eligibility or award amount is disputed. The incident record and bounty record link to the same evidence but control different actions. | Step | Evaluation and authority | Action and branches | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | E01. Receive and establish urgency | Automated reproduction or targeted judgment under an incident policy. An unauthenticated assertion alone does not authorize arbitrary shutdown. | Identify the affected operation and evidence. A credible urgent condition moves to E02. Unconfirmed reports continue through F4 with bounded reproduction work. | | E02. Contain | A preauthorized guardian or incident executor applies the narrow protective rule. Authenticate the action and record the incident. | Stop affected work or new credential issuance. Separately determine whether existing credentials need distrust or individual revocation. Missing capability enters F10 immediately. Continue unaffected services where the scope permits. | | E03. Choose restoration path | Targeted decision by the incident authority. Check whether a predecessor is still approved, usable, and unaffected. | Restore that predecessor under an existing rollback permission, or keep the affected operation paused while producing a patch. Never restore a known-defective fallback merely to exit the pause. | | E04. Authorize emergency work | Incident maintainer defines the bounded fix, resource budget, and any paid scope. Corpus authority establishes the demonstrated failure's expected result. | Link the work to the incident and authorize an emergency candidate. Broader feature changes return to F1. Funding limits still apply. | | E05. Build and test | Full fixed checks where feasible, reproduction of the original defect, and targeted semantic and regression checks for the affected behavior. Evidence must identify the exact patch. | A passing result proceeds. Failure returns to the implementer. Missing required inference or runner evidence enters recovery. The incident authority cannot declare a missing required check successful. | | E06. Authorize expedited promotion | Apply the emergency policy's scoped authority and any required signatures. Record which ordinary waiting requirements were shortened or deferred and why. | Permit only the identified patch and actions. A policy exception beyond predelegated authority requires the proper higher authority. If that authority is unavailable, remain contained. | | E07. Deploy and verify | Authorized transaction and routing jobs, with confirmed state and live checks. | Restore only after the candidate is approved and the required checks confirm it is serving correctly. Partial activation remains an incident and can return to E02 or E03. | | E08. Complete follow-up | Observe the fix, perform specifically deferred extended tests, notify affected users, and evaluate remedies. | Keep the incident open until required follow-up is complete or an explicit continuing restriction is recorded. A failed follow-up returns to containment. Record the final outcome and linked reward or refund obligations. | E05 must still test the demonstrated failure and the behaviors needed for a defensible restoration. The emergency policy can reduce a long public window or a broad attack-search budget. It should identify what may be deferred, the substitute evidence required now, and the deadline and consequence for missing follow-up. A short emergency notice or challenge opportunity can be useful if urgency permits it. It cannot postpone the protective stop it is supposed to support. New contrary evidence remains actionable immediately after restoration. Do not wait for a post-release window to close before containing a demonstrated new failure. The emergency authorization path must exist before the incident. If the same unavailable quorum is required for every ordinary and emergency action, describing the fix as urgent does not supply the missing permission. Governance must decide in advance which bounded powers survive that outage. ### Protective actions | Action | Effect and required limit | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Pause affected work | Stop the identified service or job class while unaffected reporting and recovery continue. | | Stop new credential anchoring | Prevent new accepted records from the affected release or domain. Define existing-credential treatment separately. | | Revoke an individual credential | Invalidate a specific credential under its granted authority and recorded reason. Use disposable identifiers when testing an irreversible action. | | Distrust or revoke a release | Apply the defined effect to credentials associated with that release. Broader or irreversible effects need their own permission and notice rule. | | Roll back production | Select an explicitly authorized, usable, unaffected predecessor and confirm actual routing. | | Admit an emergency patch | Approve only the identified evaluated fix through the expedited permission. This is broader than permission to pause. | The incident record identifies an accountable coordinator, affected releases and credentials, containment times, permitted restoration, evidence access, and follow-up deadlines. Contact affected credential holders directly where contact information is available. A public status record should describe the impact even while exploit details remain private. Retain enough build and test evidence to reproduce a defect against an older release. A fallback is usable only while its authorization, hosting, dependencies, and known behavior remain suitable. Check those conditions during ordinary operation so an emergency does not discover that the recorded fallback no longer runs. ## 12. Funding and the token EPOCHE coordinates community participation by paying for useful work and funding bug bounties. Customers can purchase agent-code reviews with EPOCHE at dollar quotes. Contributor settlement uses the asset and conversion terms in the accepted quote. Holding the token alone does not grant repository, release, or treasury permission. The selected recurring funding sources are a share of purchased review fees and a 1% buy/sell tax on the EPOCHE token. The tax applies to a covered buy and to a covered sell. When uncommitted reward inventory reaches its target and protected reserves have coverage, designated incoming fees and taxes go to a burn address. When inventory falls below target or reserve coverage fails, those inflows replenish the pool. The exact crossing and equality rules appear below. ### Revenue and obligations Keep customer service liabilities, operating reserves, accepted contributor payments, and uncommitted bounty funds separately accounted for. Customer top-ups can represent work still owed. Do not treat the full top-up as earned revenue available for bounties or burning. The review-fee allocation must provide for inference, infrastructure, and other service costs. Select its exact fraction and accounting basis before enabling the automatic transfer. The operating portion continues to pay service costs while the designated pool portion follows the pool-or-burn rule. Launch funding does not include a 5,000 USDC founder contribution from Bryan. Launch budgets must use actual funding. Public development can begin before funded rewards open, but compute and hosting still require an operating allowance. Use a continuously replenished pool with recorded commitments. A budget ceiling is permission to spend up to a limit, not proof that assets exist. Available funds are assets the DAO can spend under their terms after existing obligations and required reserves are accounted for. New reservations must not promise funds already committed elsewhere. ### Pool and burn routing Use a token-denominated target for uncommitted EPOCHE reward inventory. Protect operating reserves and accepted liabilities through a separate reserve check. This separates the number of tokens retained for future rewards from the assets needed to meet actual payment promises. The target counts spendable, unreserved EPOCHE assigned to the bounty pool. It excludes tokens already reserved for accepted work, disputed awards, or another restricted purpose. It excludes customer service balances, gas funds, and operating reserves. Those balances can share custody only if the accounting and permission checks preserve their allocation. The reserve check establishes coverage for customer liabilities, due and conditional commitments, adopted remedies, and the operating and emergency targets. Cover fixed asset liabilities in that asset or under funded protection specified by the promise. Do not count a volatile token balance at an optimistic spot price as guaranteed dollar coverage. Token-quantity liabilities can be reserved in tokens under their accepted terms. Apply this accounting rule to every pool-to-burn decision. The token target and the separate reserve amounts require funded operating estimates before activation. The burn decision uses the reserve check's current accounting revision and authenticated result. It does not continuously convert the inventory target into dollars through a price oracle. | Condition | Automatic action | Accounting requirement | | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | Reserve coverage is established and uncommitted reward tokens are below target | Refill to target from the designated incoming tokens, then burn any excess from that inflow. | Record the actual token quantities allocated to each destination. | | Reserve coverage is established and reward inventory is at or above target | Burn designated incoming tokens. | Existing pool assets and reservations remain in place. Equality counts as a full inventory. | | A new reservation or payment leaves reward inventory below target | Resume replenishment on subsequent designated inflows. | The reservation or payment updates the accounting revision before the next routing decision. | | Protected reserves are short, stale, or unknown | Route designated inflows to the pool and disable burning until coverage is established. | Record the shortfall or unknown state. Receiving EPOCHE does not by itself settle an external-asset obligation. | | Conversion or transfer fails | Preserve the pending amount and its intended allocation for reconciliation. | Report only confirmed transfers as funded or burned. | Split an inflow that crosses the target. For illustration, an uncommitted balance of 900 EPOCHE, a target of 1,000, and an incoming allocation of 250 sends 100 to the pool and 150 to burning if the reserve check passes. These are illustrative token quantities, not launch settings. If reserves are short, all 250 goes to the pool pending the authorized remedy for that shortfall. Compute each allocation against the latest balance and reservation state. Commit the allocation atomically where possible. Otherwise reserve the inputs and prevent another worker from using the same available balance until the transfer is reconciled. An unsolicited deposit or a retained shortfall inflow can leave the pool above target. The threshold governs designated incoming funds, so it is not a hard ceiling on all treasury assets. Any new liability, reservation release, withdrawal, changed service promise, or expired reserve evidence invalidates the prior coverage result where it changes the calculation. If some obligations are recorded off-chain, the controller trusts the admitted accounting worker to report them correctly. State that trust boundary and reconcile assets against the ledger. The burn contract cannot discover an omitted customer liability from a balance read. Keep reserve evidence short-lived under an explicit accounting policy. The founding proposal accepts it for at most 24 hours and invalidates it sooner when the relevant ledger changes. A stale result routes funds to the pool, where they remain available for correction. It cannot permit burning. The pool is a temporary supply sink. It holds EPOCHE outside the market until reward payments make those tokens available to recipients. Burning permanently removes tokens from circulation. This mechanism does not guarantee a token price or a dollar value for the retained inventory. For review fees received in another asset, the designated share needs an authorized conversion if it is to become EPOCHE for rewards or burning. Name that operation plainly. It spends earned service revenue buying EPOCHE, and the burn route then removes the purchased tokens from circulation. Conversion follows pricing, liquidity, and cost limits. Unconverted funds remain recorded separately and are not reported as burned. Define covered buys and sells, collection points, permitted exemptions, and amendment authority in the token implementation. The selected 1% rate does not require a tax on every wallet-to-wallet transfer. Verify the actual chosen contract and trading routes rather than assuming a general fee-on-transfer implementation. ### Token and settlement readiness Retain the 1% buy/sell tax and EPOCHE review payments as selected product mechanics. Their activation requires a tested token and actual supported payment routes. The first release-controller rehearsal can run without issuing a token or relying on trading revenue. Test the tax together with contributor payouts, customer payments, treasury conversions, and fee-funded burning. Include every tax, trading fee, slippage limit, rounding rule, exemption, and recipient net amount in the simulation. Verify each proposed router, bridge, or venue with the chosen implementation before relying on it. Confirm support for each specific route before using it. For example, a sale with a gross value equivalent to $100 and only a 1% sale tax leaves $99 before other fees and price movement. If the quote promises $100 realizable after sale, the funding and conversion calculation must cover those costs. A promise of a fixed token quantity instead leaves the recipient with the disclosed exit costs and price exposure. If no tested route supports the promised net payout within its limit, disable that settlement route. Use only an already funded fallback in the accepted terms or obtain a revised agreement. Governance can reconsider the tax if measured results make it unsuitable. A worker cannot waive the selected tax or invent a treasury exemption to make its payout test pass. Launch funding can include trading receipts, outside funding, and review fees. Treat every source as available only when its assets and commitments exist. Simulated tax receipts can exercise accounting during rehearsal, but they are not revenue. ### Collection procedure | Step | Work and authority | Result or failure | | -------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | | P01. Recognize receipt | Controller authenticates a confirmed tax receipt or earned review-fee allocation under the current rule. | Duplicate events cannot create a second allocation. Unearned customer credit remains a liability. | | P02. Calculate allocation | Controller applies the active fee share, current reserve check, uncommitted token target, and split-crossing rule. | Stale or unknown coverage disables burning and routes designated inflows to the pool. Record the rule and accounting revision. | | P03. Convert if required | Scoped executor uses the approved pricing source, asset route, and cost limit. | Failed or excessive-cost conversion remains pending under its fallback. | | P04. Transfer | Executor sends only the designated amount to the pool or burn destination. | Reconcile uncertain transfers before retrying. | | P05. Confirm and reconcile | Controller verifies the external result and updates balances and public accounting. | A discrepancy blocks reliance on the disputed available balance and starts F10. | Steps can execute atomically where the implementation permits. Their accounting effects must remain distinguishable even then. No step requires a vote merely to apply the active routing rule. Changing the rate, split, threshold, or authority uses F9. ### Additional funding Sponsorship, outside seed funding, prepaid service, and funded token allocations can support launch or a domain budget. State the assets received and what the funder receives in return. Funding need not buy governance influence. A prepaid service commitment needs a reserve for delivering the service. Any proposed liquidity mechanism must identify who supplies spendable assets and what obligations it creates. Virtual reserves cannot pay an external invoice by themselves. Assess each liquidity proposal on its specified mechanism. Evaluate the concrete arrangement and its capital source. Keep forecasts separate from funding authority. Model service volume, margins, trading receipts, token prices, and operating costs as scenarios. Enable commitments from actual covered funds. Yield, buybacks, or other treasury uses can apply to uncommitted assets only after the relevant budget decision. ## 13. Quotes and compensation 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. 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. Select operating buffers and payout protection before accepting the promises they support. A premium for accepting token risk remains an optional pricing decision. Payment is a linked state machine with its own obligations. Closing a release attempt or deleting its test deployment must not delete money already earned. | Payment state | Trigger in the work lifecycle | Consequence | | ----------------------- | -------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | `QUOTED` | Scope and price are proposed before paid implementation. | No obligation exists until the required acceptance. The quote states settlement, milestones, and cancellation terms. | | `RESERVED` | U03 accepts the assignment and the contributor agrees. | Reserve the authorized commitment and resource allowance. Stop other jobs from promising the same funds. | | `ACCEPTED_CONDITIONAL` | The specified acceptance milestone is confirmed, often U07 for a code contribution. | Record accepted work and allocate any conditional fee. Pay an acceptance portion only if the original terms permit it. | | `OBSERVING` | U15 or another explicitly agreed observable-use milestone. | Start the holdback observation period. Record the actual start, relevant release, and required evidence. | | `DUE` | The agreed conditions are met, or a dispute or cancellation decision establishes a payable amount. | Create a scoped payment job. The ledger retains the entitlement until settlement succeeds. | | `DISPUTED` | A qualifying dispute concerns attribution, milestone completion, recipient control, or amount. | Reserve the contested amount. Pay undisputed portions where the terms permit. Use a deadline and the relevant decision authority. | | `SETTLED` | Confirmed payment to the authorized destination. | Record the transaction and amount once. A retry cannot create a second entitlement. | | `CANCELLED_OR_ADJUSTED` | An authorized decision applies the accepted terms. | Release only unearned reservations. Preserve previously earned amounts and reasons for any authorized forfeiture. | A raw push cannot create compensation. A push can trigger validation. If the validated merge matches an existing paid assignment, its confirmed acceptance event can allocate the promised conditional payment automatically. The event references the approved quote, accepted revision, contributor, and milestone so the payment rule has something specific to enforce. A release failure involving someone else's contribution cannot silently forfeit every contributor's compensation. A payment cliff means a specified portion first becomes payable when its conditions and date are met. Record that schedule in the accepted quote. ### Quote requirements Every paid assignment states the work and its acceptance criteria, dollar quote, settlement asset, conversion event, approved pricing source, maximum token or swap spend, reservation method, milestone dates, and cancellation terms. It also states any holdback, repair duty, self-bounty exclusion, and dispute process. If the recipient is promised a realizable dollar amount, reserve the assets or executable protection that supports it. If the recipient accepts a token quantity calculated from a reference price, say when that quantity becomes fixed and who bears later price changes. Do not promise unlimited token issuance to satisfy a fixed dollar quote in an illiquid market. Price averaging is a possible conversion input. It needs manipulation and liquidity checks appropriate to the payout. A contributor lockup does not correct a payment calculated from a manipulated price. A funded fallback or recipient-approved amendment can resolve a failed conversion. An executor's cost ceiling cannot erase a due entitlement. The quote also states whether its dollar amount is gross or net of the selected token tax, trading fees, and conversion costs. The token and settlement rows in the configuration register refer to the same end-to-end test. Optional customer payment in EPOCHE remains an Epoche pricing capability, and does not require every customer to acquire the token. ### Holdbacks and repair For substantial verifier work, the founding schedule holds the full accepted fee for thirty days from its observable-use milestone. Smaller work can use a smaller holdback or payment on acceptance. Adopt each category's required evidence and milestone before accepting a funded quote. These payment periods are separate from release challenge windows. For illustration, a $1,000 assignment with a full conditional fee pays nothing merely because its code merges. Acceptance records the $1,000 conditional entitlement. If the terms start observation on production activation, that event starts its thirty-day period. Satisfying the period and required evidence makes the fee due under the agreed conversion terms. The example does not set a production price or token amount. The DAO must reach a deploy, assess, or cancel decision by the assignment's deadline. If it never deploys accepted work, the agreed alternate milestone or cancellation rule determines payment. Observing repeated easy requests is insufficient when the terms require evidence about a different behavior. Keep contributor-funded collateral separate from withheld compensation. A proposed 20% stake remains disabled unless adopted for a stated incentive problem. Define any deductions by evidence, attribution, applicable limits, and appeal. Reserve undisputed amounts while deciding a contested portion. Select repair duties and the period excluding authors from rewards for their own defects separately. The v1 twelve-month repair term is not an automatic v2 default. If duties outlast held compensation, identify the remaining enforcement, such as later role eligibility or a separately funded repair assignment under the agreed terms. Paying the holdback does not silently end all duties. Early self-disclosure should make repair and containment easier. A contributor cannot earn a new bounty merely by planting or rediscovering a defect in their own paid work. Do not make an honest self-report automatically more costly than concealment. State how self-disclosure affects any repair fee, holdback adjustment, or role consequence before accepting the assignment. ### Settlement authority The controller converts a due entitlement into one scoped payment job. The executor checks current recipient control, payment eligibility, destination, amount, asset, and conversion limits. It records the external transaction and verifies settlement. A job retry must reuse the entitlement identifier. A financial dispute concerns a named amount or condition. Resolve it through the assigned authority and bounded challenge route. Keep a payment due if the transfer failed. Cancellation releases only amounts that the accepted terms permit the DAO to cancel. ## 14. Defect reports and bounties F4 pays for demonstrated defects under published terms and sends validated findings into the corpus. A report can also trigger immediate protection through F5 before the award is settled. | Step | Work and depth | Required actor, evidence, and transition | Failure or wait | | -------------------------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | | B01. Receive | S + C, none | Reporter submits privately through an authenticated reporting route. Controller records the target release, report or commitment hash, and priority time. | Missing data returns for correction. A bare commitment reserves no arbitrary award. | | B02. Complete and reserve | C + X, targeted | Reporter supplies the matching complete report before the deadline. Controller checks advertised scope and applies the funded reservation rule. | A mismatched or expired commitment loses its priority under the terms. Unfunded contingent awards must be labeled as such. | | B03. Reproduce | C with conditional J, targeted | Assigned runner reproduces the failure against the identified version. Report authority checks the claimed policy violation when interpretation is needed. | Infrastructure failure enters F10. A failed reproduction requests correction or reaches a recorded rejection. Serious evidence starts F5 immediately. | | B04. Determine eligibility | C with conditional J, targeted | Report authority checks scope, duplicates, author exclusions, root cause, severity, and available reward terms. | Uncertain attribution remains a separate question. One patch fixing several cases does not prove one root cause. | | B05. Record award | J or C under a fixed schedule, targeted | Authorized report decision records findings, award amount, funding reservation, recipient, and due conditions. | An unsupported claim is rejected with reasons. A qualifying dispute invokes C01 through C05 for the contested amount. | | B06. Preserve regression | X + C, targeted | Maintainer opens or links F2 work for the accepted finding and records disclosure conditions. | Do not delay all reporter pay merely because a separate regression implementer or patch is late. | | B07. Settle | X + C, none | F6 pays the accepted award under its schedule and confirms the result. | Preserve due entitlements and disputed portions across transfer failures. | | B08. Close and disclose | C + X, none | Report authority records final disposition and publishes permitted evidence when the embargo ends. | Incident and repair work can remain open under their own identifiers. | ### Scope and award terms Publish covered domains and releases, qualifying defects, reproduction requirements, reservation conditions, priority rules, award tiers, maximum aggregate commitments, payment schedule, and appeal deadlines before advertising funded rewards. A queue for possible future funding does not guarantee compensation or priority over an already funded obligation. Reward severity and useful findings within those declared limits. Keep caps attached to demonstrated defects, affected work, releases, and available commitments. Account-based caps alone are easy to evade with more accounts. Avoid promising a fresh maximum reward for every duplicate symptom. Group reports by demonstrated root cause. A shared fix is evidence to examine, not the grouping rule. Separate the undisputed award from a dispute about an additional defect or contributor attribution. Do not make every accepted award wait for a patch the DAO controls. The earlier dollar bounty tiers and per-case fees remain historical proposals. Select a funded schedule for v2 rather than treating v1 amounts as promised launch rewards. Review that schedule together with holdbacks, optional collateral, and self-bounty exclusions so linked contributors and reporters cannot extract more than the intended funded liability. ### Attribution and consequences Report validation answers whether a defect exists. Attribution answers which accepted work caused it and which quoted consequence applies. Compare releases, reproduce the failure, and use revert-and-retest when informative. Interacting changes can leave responsibility uncertain even when the defect is certain. Adopt the attribution standard before it can reduce payment. A finding must identify the applicable term, responsible contribution, causal evidence, and amount at issue. Uncertainty cannot silently become proof of fault. An appeal can correct attribution without denying the underlying defect. Routine payment consequences can follow established defect attribution without proving intent. Fabricated evidence, planted defects, and coordinated extraction are separate misconduct questions. One honest error does not remove membership. Repeated poor work can justify a scoped role review that considers severity, work volume, and difficulty, with notice and appeal. Corpus work remains useful even without an active bounty finding. Commission benign controls and missing behavior categories alongside attack regressions. Customer code enters that work only through an explicit, sanitized contribution. ## 15. Customer remedies F7 records service credits and refunds separately from incident protection. An existing product rule can authorize an automatic remedy. A discretionary incident refund requires an explicit decision by the designated budget authority, which may be a member or human role. Agents can prepare the affected-request list and execute the authorized batch. Adopting or expanding an automatic remedy rule requires a coverage check before the DAO offers the promise. Specify eligible exposure, maximum liability or an enforceable exposure limit, funded reserve, and how each new service request increases the obligation. Reserve capacity at intake where the promise requires it. Stop accepting new covered exposure when the allowance is exhausted. Previously promised remedies remain owed under their terms. F8 establishes the funded allocation and F9 adopts changes to the promise. A budget check only when a refund comes due would be too late. The DAO cannot cure an unfunded promise by deleting its entitlement after the failure. | Step | Work and authority | Required outcome or failure | | ------------------------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | R01. Identify affected requests | Controller or incident coordinator links service records to a failure and the applicable terms. | Verify request identity and avoid disclosing customer source code. Uncertain eligibility goes to the assigned decision-maker. | | R02. Establish remedy | Controller applies an adopted objective rule, or budget authority decides the discretionary remedy. | State eligible requests, amount, service credit or asset refund, payment method, and funding source. No decision means no discretionary award. | | R03. Reserve | Budget controller checks coverage and records one entitlement per affected request or recipient. | A budget shortage cannot erase an automatic remedy already promised under service terms. It enters funding recovery. | | R04. Execute | Scoped service or payment executor grants credits or transfers the authorized funds. | Partial batches record each result separately. Retry cannot repay completed entries. | | R05. Confirm and notify | Controller verifies the credit balance or transfer and notifies the affected customer. | Unknown transactions remain unconfirmed. Disputed eligibility uses a bounded challenge. | | R06. Reconcile | Budget controller records actual cost and closes settled entries. | Due and disputed entries persist even if the incident closes. | A service credit pays for later service. A wallet refund returns an asset under the accepted settlement terms. They are different promises. A review-fee refund for a qualifying bounty report also needs explicit eligibility and method rather than an assumed cash refund. Free re-review after a verifier defect remains a feature to fund and activate. Estimate the inference and infrastructure cost when authorizing those credits. Containment and restoration continue while the DAO decides any discretionary compensation. ## 16. Participation and governance 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. 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. Accepted work history may inform later authority through published rules. AI evaluation 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. 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. ### Contribution credit The starting approach allocates a fixed amount of credit to each accepted contribution and divides it among the credited participants. Splitting one participant into several accounts must not multiply the contribution's total credit. The same work cannot earn full credit again through another submission or renamed task. Record the credit-setting authority, rationale, affected work, allocations, and correction route. If paid scope influences credit, protect against inflated quotes and reciprocal assignments. Linear aggregation alone does not prevent those attacks. Documentation can qualify when its accepted value warrants credit. Before enabling votes, select credit categories, active-weight calculation, any decay or delegation, eligibility conditions, quorum, decision threshold, and notice periods. Define a snapshot so the outcome cannot change merely because accounts transfer tokens or receive unrelated credit midway through a vote. Test the rules against low participation and coordinated accounts. An optional person-uniqueness check or modest token requirement needs a separate adoption decision. Neither replaces work attribution. Do not collect employer affiliations and then promise independence through rules that v2 has otherwise removed. ### Budgets and administration F8 allocates actual resources and delegates spending within limits. The bounty pool, operations allowance, gas allowance, and emergency reserve can use shared custody if the accounting and permissions protect each allocation. | Step | Work and authority | Required outcome or failure | | ------------------------ | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | A01. Propose allocation | Requester identifies purpose, asset source, amount, term, recipient role, and existing commitments. | Controller rejects incomplete or duplicate requests. | | A02. Check coverage | Controller compares the request with available assets, protected obligations, and allowed use of sponsor funds. | Insufficient funds require a smaller request, an identified funding source, or rejection. | | A03. Decide | Delegated budget authority handles permitted reallocations. Governance handles changes beyond that authority. | Record the decision, notice or vote requirements, and expiry. Failed quorum grants no new budget. | | A04. Authorize spending | Controller records the allocation. Authorized executor applies any required account or contract limits. | Confirm the permission actually changed before allowing new commitments. | | A05. Reserve and spend | Maintainers and workers commit only within the funded allocation and their permissions. | Budget exhaustion stops new spending. Existing earned claims remain recorded. | | A06. Reconcile and renew | Budget controller compares commitments, transfers, service costs, and remaining assets. | Escalate discrepancies. Renewal or expanded authority returns to the appropriate decision step. | Ordinary task assignment within an existing budget requires no new member vote. Publish recurring accounts showing receipts, fee and tax routing, burns, commitments, payments, disputed amounts, operational costs, and remaining available funds. The reporting cadence is a launch setting. ### Rule amendments F9 changes policy or organizational authority. Applying a rule is administration. Changing a review-fee percentage, token-tax rule, council permission, or pool threshold is an amendment. | Step | Work and authority | Required outcome or failure | | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- | | G01. Submit amendment | Proposer supplies old and new rules, rationale, affected permissions and obligations, and proposed effective date. | Incomplete changes return for correction. | | G02. Assess effects | Controller and assigned specialists identify migration, implementation, credential, budget, and authority consequences. | Missing material effects require more information. The affected council cannot decide its own authority expansion. | | G03. Publish notice | Governance controller publishes the exact proposal and evidence under the applicable notice and challenge rules. | Material changes restart the required examination opportunity. Evidence access failures stop the relevant clock. | | G04. Decide | Current governance authority applies eligibility, snapshot, quorum, and decision rules. | Rejection or deadline without quorum closes the proposal. An already-authorized recovery rule is the only fallback. | | G05. Implement and test | Scoped executors perform the authorized preparation and F1 evaluates required code changes. | The decision can permit development and candidate testing while activation remains conditional. Failed implementation cannot activate the rule. | | G06. Activate | Controller confirms the effective date, implementation evidence, resolved blockers, and current authority. Executor applies the exact amendment. | Confirm actual state. Failed migration follows its planned recovery procedure and preserves the prior rule where possible. | | G07. Reconcile transition | Controller updates rule references and verifies affected roles, in-flight work, and obligations. | Record exceptions explicitly. Previously earned entitlements survive unless their accepted terms permit the specific adjustment. | An amendment that needs code must avoid circular prerequisites. G04 can authorize building and testing the proposed policy. Its final effect waits for G06 and the linked release conditions. U02 can proceed on that preparation authority without pretending the unbuilt rule is already operative. For coupled policy, corpus, and release changes, record the exact combination authorized to become active. The existing governing rule permits the coordinated activation. Stage preparatory writes where necessary, then confirm all required references before routing production at U15. If the implementation cannot switch every system atomically, its rollout must prevent use of an inconsistent combination and treat a partial switch as recovery or an incident. The new policy cannot supply its own missing activation authority. Rules for authority expansion and changes affecting earned claims deserve stronger protection than ordinary operating settings. Select the exact thresholds and protected scope in the charter. Do not perpetuate v1 restrictions on USDC, human approvals, or contribution scoring solely because they were described as locked rules. ### Founding and transition The founding configuration has one controlling operator, Bryan, who appoints the initial controller, runner, council, executor, guardian, and recovery roles. Routine work executes automatically. Until control is distributed through an explicit handover, those role assignments do not establish independent distributed authority. Bryan's founding hardware key admits and replaces role keys, initializes the promotion controller, and exercises the stated recovery powers. Routine release and payment keys belong to scoped workers. The first passing-candidate drill must use the routine executor through the same authority mechanism intended for operation. A founder transaction at U14 would test a different workflow. Founding challenge eligibility is public and defined in section 9. Contribution credit can be recorded immediately, while weighted voting, token eligibility, delegation, and membership formulas remain disabled until adopted. Public challenges therefore do not wait for governance scoring. Recovery initially works when a worker is unavailable or refuses while the founding authority remains available. It does not guarantee recovery from Bryan's own refusal or loss of all founding recovery capability. Preauthorize additional controllers and an independent recovery route before claiming resistance to obstruction by the founding operator. Record every retained power, replacement rule, notice requirement, and proposed handover condition. A handover identifies the new controllers, demonstrates their independent admission and recovery control where independence is claimed, tests replacement without the departing controller, and revokes obsolete authority. Reconcile queued jobs under the new authority epoch. If a human reviewer pool is retained, three accepted founding appointments can establish it. That does not add a mandatory human layer to normal release decisions. The coverage and challenge councils qualify for their scoped work before receiving authority. ## 17. 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. ### Custody and replacement A TEE protects the execution and secrets of admitted code under its platform's guarantees. It does not decide which role that code currently holds. Admission must check the expected code identity and the current role authorization before releasing credentials or accepting its signed actions. Separate repository credentials, deployment access, release transaction authority, payment access, and recovery permission. Record who can upgrade the workers or recover their keys. Multiple enclaves under one unrestricted recovery key still share that authority. The detailed custody implementation must specify controller contracts or wallets, signer thresholds where used, allowed call targets, limits, key renewal, revocation, and recovery. Do not inherit the old two-human-signature arrangement as a prerequisite. Evaluate suitable existing registries and governance components against these requirements before adding custom custody. ### Recovery flow F10 can start at any execution step. The flow records the original job so recovery resumes the correct action and preserves completed effects. | Step | Work and authority | Required outcome or failure | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | H01. Detect and scope | Controller records the failed capability, original step, last confirmed effect, and affected services. | Separate unavailable evidence from an actual failed behavior test. Apply scoped containment if required. | | H02. Reconcile | Executor or operations worker checks whether the external action already succeeded. | Unknown effects remain unconfirmed. Do not issue a second payment or incompatible deployment. | | H03. Retry or replace worker | Controller uses the remaining time, cost, and retry allowance. | Replacement must already have suitable authority or proceed to H04. Stop stale workers from acting. | | H04. Restore authority | Preauthorized recovery role authenticates replacement code or participant control and applies bounded permission changes. | Lost authority cannot be restored by elapsed time alone. If no valid recovery route exists, record the capability as unavailable. | | H05. Verify capability | Runner or operations worker tests the restored key, service, budget, or endpoint under its actual permission. | Failure returns to a permitted retry or reaches the recovery deadline. | | H06. Resume or close | Controller rechecks the original action's current prerequisites, then resumes it once or records a closed attempt or continued restriction. | Preserve accepted payment obligations and incident evidence. Restored infrastructure does not make a stale candidate eligible. | Provide separate gas funding within an operating allowance. A gas funder pays transaction costs without receiving release authority. An empty allowance needs a named funding source or an explicit inability to execute. The controller cannot create ETH from an approved budget number. Keep incident and recovery capacity outside discretionary attack-search allowances. Before depending on cloud-level shutdown controls, verify what the chosen provider actually offers and how quickly its cost records update. Local job limits are enforceable sooner than delayed billing data. ## 18. Failure handling ### Common recovery states Every executable job needs a deadline, retry allowance, spending limit, and recovery owner. Its permitted outcomes include successful completion, correction, cancellation, and explicit inability to proceed. The parent flow records which outcome occurred. Use the following shared states without losing the original step: - `WAITING_FOR_INPUT`: a named contributor or authority must supply something specific before a deadline. - `RETRYING`: the failure is considered temporary and the next attempt remains within its budget. - `RECOVERY_REQUIRED`: automatic retries have failed or authority must change. Record the permitted recovery actor and action. - `RECONCILING`: an external action may have succeeded. Establish its actual outcome before attempting another effect. - `PAUSED_FOR_SAFETY`: an identified condition prevents the affected operation from continuing. - `CLOSED_UNRESOLVED`: this attempt cannot safely complete under its rules. Preserve the evidence, reason, and separately recorded obligations. These states make stalled work visible and actionable. They do not turn timeout into permission or turn a failed payment attempt into cancellation of a debt. ### Failure requirements | Failure and affected steps | Automatic response | Authorized recovery or intervention | Deadline outcome | | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Gas wallet lacks ETH. U08, U14, settlement, and recovery transactions. | Check gas before dispatch. Request a bounded top-up from an already-authorized operating allowance. Queue the original action once. | Treasury or operations authority supplies funds if the allowance is empty. A gas funder can pay transaction costs without receiving release authority. | Mark the action unfunded if no source exists. Keep unpaid entitlements due. Do not promote on the strength of an unsubmitted transaction. | | TEE server is unavailable. Runner, council, or signer jobs. | Detect loss of service, end the worker's assignment when permitted, and assign an authorized replacement. | Recover or replace the key through the previously approved attestation and role policy. Revoke obsolete access when required. | Close the candidate attempt or keep the affected service paused if no authorized replacement exists. | | Inference endpoint fails. U02, U05, U10, challenges, and E05. | Retry within count, time, and cost limits. Preserve completed valid runs and mark missing runs incomplete. | Use only a substitute allowed by the applicable policy. A change to the verifier's own selected model creates a changed candidate requiring evaluation. | Unfinished required work prevents acceptance. Never infer a pass from an empty response or expired request. | | Required signers coordinate a refusal. U14, governance changes, and discretionary payments. | Publish missing participation and invoke any preauthorized replacement or recovery route. The ordinary executor cannot manufacture the missing signatures. | A separate recovery authority replaces or restores capability under its existing rules. It cannot depend on consent from the same blocking quorum. | Without such a route, the action remains unauthorized. Close the attempt where possible and declare the affected capability unavailable. | | A key is lost or compromised. Submission, execution, governance, or payout. | Disable compromised authority where the incident rules permit. Stop using an uncertain recipient key for disputed payments. | Use authenticated role replacement or participant recovery. Update permissions before resuming queued actions. | Preserve pending work and entitlements. A delay alone is insufficient evidence to grant a replacement key. | | A transaction's outcome is unknown. U14 and all transfers. | Enter `RECONCILING`. Read the expected state and transaction identity before resubmitting. | Operations resolves inconsistent provider observations under the confirmation policy. | Keep the result unconfirmed. Retrying without reconciliation risks duplicate effects. | | Chain access or required confirmations are unavailable. U08, U14, issuance, and payments. | Retry permitted providers and retain pending jobs. Stop transitions that require fresh confirmed state. | Restore access. Follow an explicit product policy for any already-issued evidence that cannot be checked. | Do not label an unknown validity check valid. Defer the action or close the attempt without granting new authority. | | Git push, build, or merge fails. U04 through U07. | Retry transport or build work where the same inputs remain valid. Record tool failures separately from failed behavior tests. | Contributor or maintainer resolves conflicts. A changed source tree returns to evaluation. | Cancel an unfinished assignment under its terms after the deadline. Accepted earlier milestones remain recorded. | | Two executors race or events are delivered twice. Any execution. | Use the action identifier and current state to claim one execution. Reject stale assignments and repeated effects. | Reconcile any external outcome already produced. Restore the correct permission record. | One recorded outcome per authorized effect. Never allocate a second reward because the same event was delivered twice. | | Test endpoint or essential evidence disappears during the window. U11 and C01 through C04. | Stop counting unavailable access time and attempt restoration. A member-window expiry cannot clear this condition. | Restore equivalent access to the same target and disclose the interruption. | Extend for missing qualifying access or restart when equivalence cannot be established. Close the candidate if access cannot be restored. | | A council abstains, disagrees, or misses its deadline. Conditional judgments and challenges. | Apply its recorded agreement rule and bounded reassignment allowance. An abstention is not an acceptance. | The designated replacement or appeal authority handles the specific unresolved question. | Record unresolved and close the affected attempt. Existing production continues only if independently permitted. | | Candidate or policy becomes stale. U07 through U15. | Detect changes to the base, target, permissions, or applicable rule. Suspend obsolete eligibility. | Re-evaluate the changed dependency or obtain an explicit transition rule through governance. | Supersede or close the stale attempt. Do not reuse signatures for a different candidate. | | An actual test failure is found. U06, U10, U11, or E05. | Record the failure and prevent the affected transition. | Implementer corrects the code or corpus authority resolves a mistaken expectation under the proper rules. | Reject or supersede the candidate if no accepted correction arrives. Infrastructure retry limits must not be used to rerun away real failures. | | Deployment only partly succeeds. U15 or E07. | Compare contract authorization with actual routing and endpoint state. Disable the affected route where necessary. | Complete activation or restore a still-authorized fallback through the proper permissions. | Declare continued degraded or paused service. Retain the actual state of every completed action. | | Token conversion cannot obtain the required payout within its limit. F6 and F7. | Stop the conversion and retry only under the agreed pricing and cost limits. | Use a funded fallback permitted by the quote or obtain the recipient's agreement to amended settlement. | Entitlement remains due or disputed under its terms. An execution limit cannot erase it. | | A resource budget is exhausted. Testing, attack bots, hosting, or appeals. | Stop discretionary work and new spending commitments. Keep required unfinished evaluation incomplete. | Authorized budget authority adds funds or reduces future scope through a valid rule change. | Close the attempt or maintain containment. Preserve a separately authorized allowance for essential incident and recovery work. | The failure table applies before, during, and after an action. Before dispatch, check authority and funds. During execution, track the assignment and deadline. After interruption, reconcile the actual effect before choosing a retry or reversal. A successful off-chain job cannot compensate for a failed on-chain authorization, and the reverse can also leave a partial deployment. ### Availability and deliberate obstruction Removing routine human signatures reduces opportunities for people to stall individual releases. It does not eliminate control concentrated in hosting, key recovery, governance, or upgrade authority. To protect routine operation, preauthorize bounded routine execution, keep replaceable workers, and provide recovery through an authority that does not require the failed actors' cooperation. Recovery permissions are consequential powers. They need explicit limits and notice because an actor who can replace signers may also take control through that replacement. There is a hard limit to the promise of continuous progress. If every authority needed to act refuses, and no independent recovery authority already exists, software cannot both respect the authorization rule and execute anyway. A contract does not acquire permission from elapsed time unless that permission was built into its rules beforehand. The achievable requirement is therefore that a failed attempt reaches a visible resolution and that common failures have a preauthorized recovery route. It is not a guarantee that every proposed update will eventually reach production. Sometimes the correct resolution is rejection, cancellation, or a continued pause. The DAO should remain able to receive reports and pursue recovery without pretending the blocked capability is healthy. ## 19. Supporting programs 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 automatic activation triggers from earlier rules. | 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 operating 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 the DAO's maintenance responsibilities. They create separate obligations or decision systems that this maintenance process does not require. Future consideration would need an explicit case for adding them. ### 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 the 1% buy/sell tax, EPOCHE service payments, contributor settlement, fee-funded token purchases and burning, and whether a designated payer or entity is needed. A contract executing transfers does not itself answer every question about responsibilities. Require an entity or document only when the activity calls for it. 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. ## 20. Implementation and launch The handbook defines required behavior. Check the running code against these requirements during implementation and each release audit. Record the code and configuration that enforce each requirement. ### Required implementation | Workstream | Required deliverable | Dependency it satisfies | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Public contribution path | Authoritative merge history, contributor access, source and corpus separation, licensing, and conflict-safe synchronization where needed. | Outside work can enter U01 without bypassing acceptance or creating an implicit payment. | | Records and controller | Versioned records, authenticated events, rule checks, job deduplication, deadlines, and resumable execution. | U, T, B, R, A, G, H, and payment flows preserve their state across worker failure. | | Evaluation | Prescribed deterministic and live tests, reproducible inputs, authenticated reports, budgeted adversarial search, and coverage reporting. | Required evidence can control progression without a universal subjective approval. | | Council qualification | Benchmarks, assignment scopes, agreement rules, injection tests, replacement, and bounded appeals. | Conditional judgment has a qualified authority and a stopping point. | | Test deployment | Reachable candidate, immutable identity, funded resources, and test-only credentials throughout readers and contracts. | Members can examine U11 without admitting unapproved production evidence. | | Production authorization | Scoped controllers, transaction enforcement, confirmed activation, valid fallbacks, and coherent client and registry checks. | U14 and U15 refer to the same approved release. | | Credential lifecycle | Domain-specific outputs, source/build/runtime dependencies, old-format treatment, and effective revocation and distrust. | F3 reports validity consistently before and after an incident. | | Challenges and incidents | Intake, evidence access, blocking scope, guardian permissions, emergency admission, direct notices, and follow-up. | Serious evidence receives protection without waiting for award adjudication. | | Funding and settlement | Earned-revenue accounting, reservations, reserve checks, due entitlements, bounded conversion, and confirmed payouts. | Paid intake opens only for promises supported by actual funding and tested settlement. | | Token activation | Implemented 1% covered buy/sell tax, supported payment and conversion routes, pool/burn routing, and net-payout tests. | Token-dependent capabilities activate after those checks. Release-controller rehearsal uses simulated receipts without requiring a token launch. | | Participation | Stable identities, public work credit, scoped roles, wallet rotation, lost-key recovery, and voting rules if activated. | Account or key changes preserve history and earned claims. | | Operations and recovery | Gas allowances, key replacement, provider recovery, resource limits, retained builds, and reconciliation. | Common failures reach a valid recovery or explicit terminal outcome. | | Participant terms | Open-source license, report scope, funded award schedule, payment eligibility, privacy handling, and dispute terms. | Participants can understand the work and payment promise before accepting it. | Do not choose a custom Git service, different chain, or new identity system merely because the automation needs an access credential. Test existing hosting and permission mechanisms first. If they cannot satisfy a documented requirement, compare the specific alternatives within a bounded investigation. ### Delivery sequence 1. Use the rehearsal profile below to define one safety candidate, its mandatory checks, named role keys, public challenge rule, and funded compute allowance. Record the concrete inputs before running it. 2. Implement the record controller and promotion controller with the routine executor as the actual transaction caller. Transfer ownership of disposable test registries to that controller. Qualify the initial council assignments against recorded benchmark expectations before granting their test authority. Exercise admission, pause, cancellation, expiry, and replacement before the passing-candidate drill. 3. Run the full evaluation and coverage task using the qualified assignments, open a real test challenge route, and complete controller-authorized promotion against test-only records. Measure its cost and retain every failure and retry. Shortened rehearsal clocks prove transition behavior only. 4. Grow the corpus, rotate benchmarks, and requalify changed councils. Exercise public and confidential challenges, a coupled weakening, a late attack finding, emergency containment, and a bounded patch. Open public defect intake early when triage capacity exists. Label any contingent unfunded award and budget regression work separately. 5. Use measured cost and access results to adopt the founding operating profile. Before outside credentials depend on it, verify the production custody migration, test isolation, full-duration challenge route, incident powers, and the actual founding recovery limit. 6. Establish funded quotes, reservations, observation, remedies, attribution disputes, and recipient recovery before paid intake. Funding work can proceed in parallel. Keep fixed obligations covered independently of hypothetical token trading. 7. Activate the token tax, token service payments, and token settlement after their integration and liquidity tests pass. Exercise pool/burn routing with actual assets and reserve accounting. Enable further governance and independent recovery after their rules and controllers are adopted and tested. Token activation can occur earlier if its own prerequisites are ready. This sequence expresses dependencies, not an assertion that a market or sponsor cannot exist yet. Paid bounties, token trading, and weighted governance are unnecessary to prove the ordinary release state machine. ### Rehearsal profile Use this starting configuration for test-only rehearsal. It requires the listed code and authenticated workers. Rehearsal results do not certify a production policy or authorize spending. | Setting | Proposed rehearsal value | Required binding or completion | | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Domain | Safety for `typescript.precise.v1` only. | Freeze the selected source revision, policy rules, model configuration, input schema, and corpus in a rehearsal record. A profile name alone is insufficient. | | Candidate scope | One full candidate against a fixed baseline, using contributor-owned or synthetic inputs. | Include a harmless change and a deliberately defective variant as separate attempts. Never issue accepted customer credentials. | | Deterministic checks | Run the complete policy-package tests and corpus command, plus the mandatory controller, isolation, identity, and credential drills listed below. | All required outcomes must pass for the passing attempt. A missing test implementation is incomplete work. | | Live semantic checks | Three prescribed trials per selected case. Select at least one attack and one benign control for every behavior in this candidate's coverage map. | Freeze case identifiers and expectations before results. Require every mandatory trial to meet its expectation for this rehearsal. This small sample is not a production accuracy estimate. | | Attack search | Twenty prescribed attempts against the scoped changed behavior, within the candidate's cost allowance. | Record all attempts and findings. A failed worker does not count as a completed attempt. | | Coverage and challenge councils | Three separately assigned evaluator instances, with two agreeing scoped decisions required. | A reproduced mandatory failure blocks regardless of the vote. Invalid outputs and abstentions do not count as agreement. Separate the challenged author from the challenge assignment. | | Runner admission | One explicitly admitted test runner key for the frozen runner image and configuration. | Exercise valid evidence, wrong target, tampered output, unauthorized key, revoked key, and stale authorization. Live execution evidence must come from the identified run. | | Challenge eligibility | Any authenticated participant, with C02 qualification for factual and interpretive submissions. | Inject both kinds in the drill and verify their assigned consequences. No contribution score or token minimum. | | Challenge time | Ten minutes of qualifying access, including any coupled corpus change. | Use only test resources and disposable identifiers. Exercise an outage and a changed-target restart. | | Execution delay | Two minutes after confirmed U13 registration. | No overlap with the challenge clock. A timer ending cannot override a pause or missing eligibility. | | Challenge decision and appeal | Ten minutes for each decision, one reassignment, and one ordinary appeal. | An unresolved blocker closes the attempt after those bounds. Public production uses the longer profile below. | | Transaction recovery | At most three attempts per authorized external effect. | Reconcile unknown outcomes before retrying. An actual failed behavior test is not a transport retry. | | Gas | On a local development chain, fund the executor with 0.1 test-native units and permit one 0.1-unit top-up from a designated test account. | No real-asset funding is implied. A different chain requires a newly recorded funded gas allowance before the drill. | | Compute | A maximum of $25 in metered model use per rehearsal attempt, including its coverage and challenge jobs. | Identify an actual approved source before live calls. Reserve existing hosting separately. If required work cannot finish within the cap, record its cost and incomplete state before revising a future attempt. | | Money flows | Synthetic fee receipts, reservations, payouts, and burn events only. | Test a threshold of 1,000 unreserved test tokens and the 900-plus-250 crossing example. These values do not become launch economics. | | Governance | Founding admission and recovery, with weighted voting and optional incentives disabled. | Record role assignments and test that a revoked assignment cannot resume a queued job. | The repository provides [policy definitions](/handbook-sources/profiles.ts) and policy test commands (`packages/agent-review-policy/package.json`) to seed the frozen inventory. The package currently defines `test` and `corpus` scripts. Include these inputs in the rehearsal and verify the controller and complete live-model evaluation separately. The mandatory integration list is exact candidate identification, authenticated runner evidence, full-diff coverage, rejected unauthorized promotion, queue-delay enforcement, pause and cancellation, duplicate-event handling, test credential isolation, revocation reaching readers, partial activation recovery, and a bounded emergency patch. Each item needs a concrete test identifier and pass/fail record before the rehearsal can be called complete. ### Founding operating profile Adopt these starting defaults after measured rehearsal. Review the first operating configuration against the results. Use F9 to change a value before use when measured cost or actual access calls for it. | Setting | Proposed founding value | Reason and activation condition | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | Full release window | Forty-eight hours of qualifying access. | Gives participants across time zones two daily opportunities to examine a change. Validate the actual access and response process before adoption. | | Targeted release window | Twenty-four hours of qualifying access. | Available only under a proven limited-effect classification. | | Corpus window | Forty-eight hours, including expectation weakenings. | Coupled work uses the longer applicable duration and separate corpus notice. | | Execution delay | One hour after confirmed U13 queueing. | Gives the cancellation and recovery route a separate opportunity after eligibility. Prequeue overlap remains disabled initially. | | Challenge decisions | Twenty-four hours per assignment, one replacement assignment, and one ordinary appeal. | Bound a blocking question while preserving a separate reconsideration. Urgent protection does not wait for these clocks. | | Council agreement | Two of three qualified, separately assigned evaluator instances for scoped judgments. | Use an explicit agreement result. Any independently validated mandatory failure still blocks directly. Shared operation remains disclosed. | | Eligibility | Public authenticated factual and interpretive submissions under C02. | Does not depend on activating contribution-based voting. | | Reserve evidence | No more than twenty-four hours old, invalidated sooner by a relevant ledger change. | Unknown or stale coverage disables burning and keeps incoming allocations in the pool. | | Retry count | Three transport attempts, followed by one authorized replacement attempt where permitted. | Each action also has a recorded time and cost limit. Reconciliation precedes any repeated external effect. | | Gas allowance | Reserve three times the estimated cost of the candidate's complete authorized transaction set, at its admitted fee ceiling. | The estimate and actual available native assets must be recorded before queueing. Top-ups stay inside the funded operations allocation. | | Evaluation budget | Fund the measured mandatory evaluation plus the adopted retry, challenge, and recovery allowances before U03. | A numerical amount comes from the rehearsal and accepted operating prices. A spreadsheet ceiling without assets does not authorize work. | | Conditional compensation | Thirty days from the accepted observable-use milestone for the substantial-work category. | Each funded quote also specifies evidence requirements and a deploy, assess, or cancel deadline. Smaller-work terms remain separate. | Production acceptance thresholds and the live evaluation corpus must follow coverage evidence and measured behavior. The rehearsal's three trials and twenty attacks do not establish an adequate production policy by themselves. Bind the adopted test list, model identifiers, qualified keys, and funded budgets before enabling the affected operation. Test exact equality, expiry, missing responses, and all deadline branches in the controller. Keep the following off until their own prerequisites are met: weighted member voting, token-based eligibility, person-uniqueness requirements, contributor stakes, challenge bonds, unfunded fixed payout promises, private-case evaluation without its examiner, token routes without integration tests, and additional credential domains without a qualified policy. Public code, report intake, and test-only rehearsals can operate with their own bounded resources. ### Required drills | Drill | Result needed before reliance | | ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Passing candidate | Sufficient tests and an uninterrupted valid member window produce an authorized promotion without an extra universal council approval. | | Full-diff coverage | A sensitive untested change requires added checks or remains blocked even when the old corpus passes. A targeted label cannot bypass classification. | | Founding challenge route | An authenticated participant without voting weight can submit both factual and interpretive claims and receive the specified disposition. | | Late challenge intake | A complete claim received just before the cutoff reaches qualification before U12 can finish. Duplicate spam cannot restart the window, and an unresolved substantive case cannot pass by backlog. | | Actual promotion caller | The scoped executor queues and executes through the controller. The founder key performs no routine U14 signature. | | Confidential case | An assigned examiner can inspect and reproduce the committed case, a public challenge receives a reasoned disposition, and loss of required access blocks completion. | | Changed candidate | A rebase, model change, or changed expectation invalidates affected evidence and receives the required new challenge opportunity. | | Failed test | The controller blocks progression and cannot clear the failure by dropping or selectively rerunning it. | | Challenge access outage | Lost test access stops the qualifying clock. A nominal deadline does not permit promotion. | | Separate appeal | The assigned authority resolves or closes a blocking case without using the original author as its independent judge. | | Production isolation | A test deployment cannot produce a credential accepted as production evidence by supported readers and contracts. | | Containment and patch | Guardian action stops the affected operation, the bounded patch meets emergency evidence requirements, and failed follow-up returns to containment. | | Revocation | Disposable release and credential records demonstrate the actual effect on checking clients and downstream contract consumers. | | Worker and signer outage | Replacement follows existing authority. Coordinated refusal exercises the independent recovery route or yields an explicit unavailable capability. | | Unknown external outcome | Restarted workers reconcile a pending transaction and produce only one payment or deployment effect. | | Conditional compensation | Accepted work remains recorded through delayed deployment, failed combined release, dispute, and payout outage. | | Funding threshold crossing | Inflows route according to the selected crossing and equality rules, burning never consumes reserved assets, and falling below the threshold restores pool funding. | | Payment conversion failure | Bounded conversion stops and invokes the agreed fallback while preserving any amount owed. | | Tax and net settlement | The actual supported token route respects the 1% covered buy/sell tax, fees, conversion limits, and the recipient's stated net or token-quantity promise. | | Remedy adoption | A new automatic promise cannot activate without funded coverage and an intake exposure limit. Previously accepted remedies survive budget exhaustion. | | Evaluation budget | The complete measured run fits its funded allowance or ends as incomplete with its actual costs recorded. Mandatory checks cannot disappear to fit the budget. | | Rule migration | Governance authorizes preparation before activation, and failed implementation cannot make the new rule operative. | ### Operational review Set a launch review date and assign a coordinator with authority to propose changes. Review missed defects, false rejections, coverage gaps, challenge outcomes, stale candidates, execution delays, infrastructure recovery, model costs, and payment performance. Compare promised service and reward obligations with actual reserves. Use observed needs to activate later programs or revise settings. A raw release count or arbitrary case count does not establish safety. Keep the overall launch review separate from individual payment observation periods and repair obligations. ## 21. Configuration register This register records operating rules, starting defaults, and the measured costs or deployed identities required before use. Section 20 contains the starting values. Activation requires the evidence listed here. | Configuration | Design or proposed default | Remaining binding before use | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Initial domain | Safety. Rehearse `typescript.precise.v1` against a frozen baseline. | Exact policy, schema, model, corpus, source revision, and supported operation identifiers. | | Coverage | Full candidates require a scoped decision on the actual diff by U06. Targeted scope must follow a demonstrated mechanical rule. | Qualified council assignment, classification rules, mapped checks, and combined-change validation. | | Production evaluation | Mandatory deterministic, live, adversarial, and integration evidence under a predeclared rule. | Measured cost, prescribed run list, case identifiers, repetition and acceptance criteria, and funded allowances. Rehearsal counts alone are insufficient. | | Evidence | Authenticate actual execution for an exact candidate. | Runner image and key, evidence schema, provenance checks, retention, and provider-drift response. | | Council operation | Two-of-three scoped agreement with defined abstention and failure handling. | Qualified instances, actual tool permissions, structured output, benchmark maintainer, fresh cases, and recurring requalification budget. | | Founding challenges | Public authenticated factual and interpretive submissions. Contribution voting is unnecessary. | Working intake, qualification and appeal assignments, funded reproduction, and published access route. | | Operating windows | Forty-eight hours for full releases and corpus changes, twenty-four for targeted releases. | Adoption after actual access and response testing. Count qualifying access only. | | Coupled corpus changes | Separate notice for weakenings and one window at least as long as either applicable window. | Candidate-use versus activation records and exact coupled version references. | | Challenge finality | Twenty-four hours per assignment, one replacement, and one ordinary appeal. | Assigned authorities, qualification appeal, timeout behavior, and urgent-protection exception. | | Confidential cases | Committed inputs and expectations, sanitized public evidence, and a separately assigned examiner. | Access classification, examiner qualification and keys, reproducibility, disclosure deadline, and limits published before U11. | | Production authority | Promotion-controller ownership with a scoped attested executor. Off-chain facts remain the executor's responsibility. | Implemented contract, target registry and chain, role and authority epoch, action schema, migration evidence, and actual executor drill. | | Execution delay | One hour after U13 registration, with no founding prequeue overlap. | Adopted controller timing, expiry, cancellation, and replacement rules. | | Emergency route | Immediate scoped containment and evaluated expedited restoration. | Guardian keys, exact allowed actions, mandatory emergency checks, any deferred work, and follow-up deadlines. | | Confirmation | Confirm the intended external state before dependent action. | Chain-specific confirmation and reconciliation rule and explicit handling of unknown validity. | | Work deadlines | Every funded quote has delivery and deploy/assess/cancel limits. | Category-specific times, alternate milestones, and accepted cancellation terms. | | Holdback | Thirty days from observable use for substantial work, with full conditional fee. | Category adoption, required observation evidence, smaller-work schedules, and adjustment terms. | | Repair and attribution | Duties and author exclusions remain separate from payment timing. | Causal standard, covered periods, post-payment consequences, self-disclosure treatment, and appeal. | | Stakes and bonds | Disabled unless separately adopted. | Specific abuse or incentive purpose, funded collateral, forfeiture evidence, and correction route. | | Bounties | Public intake can precede funded awards. Fixed promises require covered commitments. | Scope, priority, completion deadline, severity schedule, aggregate caps, reservation rule, and settlement deadline. | | Review-fee share | A portion of earned review fees follows pool/burn routing after service costs. | Exact share, accounting base, collection timing, service reserve, and Epoche pricing authority. | | Token tax | Retain 1% on covered buys and sells. Activation depends on tested routes. | Covered trades, collection, exemptions if adopted, supported integrations, and settlement tests including all costs. | | Reward inventory target | Uncommitted EPOCHE units, with split-crossing and burning at equality when reserves are covered. | Token amount selected from the intended reward budget. No inferred dollar guarantee. | | Protected reserves | Separate customer liabilities, accepted payments, remedies, operations, and emergency capacity from uncommitted token inventory. | Amounts by asset, funding source, accepted protection, and current accounting revision. | | Reserve freshness | Maximum twenty-four hours, invalidated earlier by relevant changes. Stale or short coverage disables burning. | Accounting-worker authority, invalidation events, reconciliation, and actual covered assets. | | Burn and conversion | Burn only designated inflows after the reserve check. Other-asset review fees require an authorized EPOCHE purchase if routed to token rewards or burning. | Destination, conversion limits, tax treatment, confirmation, and failed-transfer recovery. | | Contributor settlement | Dollar quotes distinguish net realizable amounts from reference-priced token quantities. | Price source, conversion event, gross/net treatment, token and fee limits, usable route, and funded fallback. | | Token service payments | Retain optional EPOCHE payment for dollar-quoted reviews. | Epoche's supported payment route, customer terms, service accounting, and integration tests. | | Funding | No assumed 5,000 USDC founder deposit or hypothetical trading receipts. | Actual operating and reward assets from the adopted sources. | | Automatic remedies | Coverage at rule adoption and new exposure, followed by entitlement-preserving execution. | Funded cap or exposure limit, intake reservation, remedy asset or service credit, and discretionary authority. | | Governance influence | Record accepted work. Weighted voting remains disabled until its rules activate. | Credit allocation, valuation, snapshot, quorum, decay, delegation, thresholds, and corrections. | | Founding control | Single controlling operator with automated routine roles and public challenge access. | Initial assignments, actual retained powers, disclosure, and a tested handover before claiming independent control. | | Recovery | Founding recovery replaces failed workers while Bryan remains available. Broader resistance requires separately controlled recovery. | Replacement actors, notice, limits, lost-key evidence, and demonstrated independence for later claims. | | Gas and job budgets | Rehearsal test-native amounts and operating estimate formula appear in section 20. | Actual funded wallets, estimated transaction set, fee ceiling, replenishment permission, time and cost limits. | | Identity | Stable pseudonyms preserve work and entitlements. | Authentication, wallet rotation, lost-key evidence, limited private records, and optional later uniqueness rules. | | Administration | Verify the actual tax, token-purchase/burn, service-payment, and contributor-payment arrangement. | Necessary payer or entity decisions, contribution licensing, payment eligibility, private retention, and reporting cadence. | | Additional capabilities | Enable only with defined scope, qualified evidence, authority, funding, and recovery. | Separate activation decision for extra domains, independent governance, and optional incentives. | Every active rule has a version, change authority, effective date, and treatment of existing work. An unbound production capability remains unavailable. Short rehearsal clocks, synthetic assets, or a provisional test key cannot activate it. Missing settings never mean unlimited spending, implicit approval, or permission to discard an existing claim. ## 22. Review decisions and sources The sections above define the DAO's operating rules. This record explains the design decisions and the review findings behind them. Earlier documents provide historical context. | Review point | Treatment in this handbook | Reason | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Review section 2, full-diff coverage | Adopted with the final check at U06 and preliminary scoping at U02. | U02 may precede implementation. Coverage must apply to the actual diff, and passing tests alone cannot detect a newly untested behavior. The task sets required evidence without adding a second release verdict. | | Both reviews, founding challenge gap | Public factual and interpretive intake qualifies through C02 before voting exists. | An empty or undefined membership roster cannot support a meaningful window. Disabling interpretive challenges would leave policy mistakes without an existing failing test harder to contest. | | Review section 3, a bundle verifies itself | Not adopted. Reproduction and policy checks remain required. | Authentication and a supplied bundle do not establish that the claimed result occurred or that its expected outcome is correct. | | Review section 4 and third opinion finding 2, token funding | Retained the selected tax and EPOCHE service-payment capability. Added net-payout integration tests and separate activation prerequisites. | The mechanics were expressly chosen. Unverified forecasts or broad venue claims cannot overturn them. Measured incompatibility can block a particular route and justify a later amendment. | | Review section 4, service-funded burning | Named the EPOCHE purchase and burn explicitly, including in the required administrative assessment. | Converting other-asset service revenue to tokens is an actual operation with cost and responsibilities. An older exclusion does not override the later chosen design. | | Opposing threshold recommendations | Chose a token inventory target with a separate funded-reserve check. | Token units make the routing target deterministic. Protected liabilities need their own coverage because token counts do not guarantee dollars. A dollar oracle in every routing decision is unnecessary for this separation. | | Third opinion finding 3, split crossing | Adopted splitting with an explicit equality rule. | A single inflow can refill the exact gap and burn its excess. The earlier text's pre-transfer rule was ambiguous, but it does not follow that every such rule necessarily burns too much. | | Review section 4, treasury cap | Separated restricted reserves and uncommitted reward inventory. | The rule governs designated inflows. Existing assets, outside deposits, and reserved balances do not disappear above the target, so the target is not a hard cap on all DAO assets. | | Review section 5, promotion authority | Defined contract versus executor enforcement and moved the actual routine authority into the first rehearsal. | A founder signing the production action would not demonstrate autonomous execution. On-chain hashes do not prove off-chain tests. | | Both reviews, one-operator founding | Specified the founding control and its recovery limit. | Separate role keys do not establish independent control. The reviews did not inspect live ownership, so their deployment assertions are not treated as verified facts. | | Review section 7, coupled weakening | Retained one shared window, separate corpus notice, and the longer applicable duration. | This prevents timing shortcuts while avoiding two serial waits for the same coupled update. | | Third opinion finding 4, held-out access | Added committed cases, a preassigned confidential examiner, public explanations, and an explicit narrower public challenge right. | Universal raw access would expose the holdout. A commitment alone does not make hidden evidence publicly inspectable, and automatic reveal can expose an unresolved exploit. | | Third opinion finding 5, automatic remedies | Required coverage at adoption and when new service exposure is accepted. | Checking funds only after a promised remedy becomes due discovers underfunding too late. | | Third opinion findings 7 and 8, evaluation costs | Added measured cost per attempt and accepted release, budgeted benchmark rotation, and requalification after material council changes. | An unaffordable mandatory evaluation stalls releases. Exposed benchmarks need fresh cases rather than repeated claims of independence. | | Review section 8, council input structure | Added structured inventories, raw-source access, typed outputs, and scoped tools. | Structure limits accidental authority and aids inspection. Summaries and attachments remain untrusted and cannot replace the actual diff. | | Review section 8, product-flow scope | Kept F3's logical states and trust dependencies. | Credential operations are part of the DAO's maintenance responsibilities. Product-specific pricing and APIs remain separate. | | Review section 8, duplicate sources | Established one operating reference and retained the earlier documents as history. | Historical documents preserve the reasoning behind earlier decisions. | | Review section 8, late findings and defaults | Retained changed-target resets and added concrete rehearsal and operating profiles. | A correction needs new relevant evidence and challenge access. Short test clocks and synthetic assets must remain distinguishable from production settings. | | Third opinion smaller notes, unfunded intake | Allowed early reporting when triage capacity is funded, with clear contingent-award terms. | Findings can improve the corpus before funded awards open. Reproduction and regression work still consume resources. | Sources. These are the historical inputs behind this handbook, not operating rules; the DAO's rules are sections 1 through 21. The superseded drafts were removed from the working tree in commit `46d1fcb` and stay recoverable from Git history under `roadmap-notes/` at its parent, `f91026a`. They are named rather than linked so that reading the operative sections does not lead into a superseded draft. - Earlier operating rules: `verifier-dao-plans-v2.md`. - V2 review: `verifier-dao-v2-review.md`. - V2 third opinion: `verifier-dao-v2-third-opinion.md`. - [V2 philosophy](/handbook-sources/v2-philosophy.md) and workflow response: `verifier-dao-v2-workflow-response.md`. - Organized critique: `verifier-dao-critique.md`, with `verifier-dao-critique-response.md`, `verifier-dao-opinion.md`, and `verifier-dao-second-opinion.md`. - Earlier annotated rules: `verifier-dao-plans.md`. Writing guide: [WRITING.md](/handbook-sources/WRITING.md). The older universal subjective release-verdict requirement remains superseded. The new coverage task examines the scope of required evidence before merge. U12 still applies the completed evidence and challenge rules automatically. The later 1% buy/sell tax and pool/burn instructions also take precedence over older token exclusions.