Skip to contentCredential operations
Section 10 of 22
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, 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.