Signatures and execution

Section 7 of 22

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 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.