Ordinary verifier updates

Section 6 of 22

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:

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.