Purpose and flows

Section 1 of 22

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.