Status and authority model

Status: Proposed / Not authorized
Applies to: Phase 2 research only
Official numeric scoring: Disabled at every state

1. Why four state machines are required

A trustworthy system must say exactly what changed. Identity registration, evidence corroboration, operational workflow progress, evidence maturity, and result publication are different events. Treating them as one ladder makes a weak administrative fact look like a measurement claim.

The Phase 2 proposal therefore separates:

Axis	Question answered	What it cannot mean
Trust progression	What identity or evidence corroboration has been recorded?	Capability, proficiency, employability, rank, or public visibility.
Readiness	What workflow or refresh action is currently required?	Evidence maturity or a person-level result.
Evidence maturity	At what E0–E5 level is a specific claim-to-capability relationship supported?	Trust status, verification of all claims, or proficiency.
Result lifecycle	Does a separately authorized result artifact exist, and what is its lifecycle state?	Permission to calculate or publish a number.

No field may be deterministically derived from another without a separately versioned and approved policy. A high state on one axis cannot compensate for a hold, dispute, missingness, or insufficiency on another.

The trust/readiness record does not store an E0–E5 field. Evidence maturity belongs only on the separate claim-to-capability link contract and is joined, when authorized, by a versioned reference rather than copied onto a person or trust-state object.

2. Proposed trust progression

The labels retain familiar T0–T4 ordering while narrowing their meaning.

Code	Label	Required fact	Explicitly not established
T0	Registered	A synthetic or, in a future approved system, policy-compliant identity reference exists.	Identity quality, evidence, capability, result, or visibility.
T1	Claim received	One or more claims have been recorded under an applicable consent and purpose.	Truth, authorship, corroboration, or capability.
T2	Corroboration threshold met	The versioned policy records independent identity confirmation and at least one eligible non-referral substantive corroboration class. A referral may supplement but cannot satisfy this threshold alone.	A score, proficiency, full-profile verification, or job readiness.
T3	Assessment completed	An approved controlled-assessment workflow is complete and its required review record exists.	A passing result, score, credential, or public profile.
T4	Field corroboration recorded	Qualifying production-outcome evidence and contribution attribution have been independently corroborated under an approved protocol.	Universal capability, current readiness, causality, rank, or an official result.

Trust progression is monotonic only as an event history. The current displayable state may be withheld or marked refresh-required when consent, integrity, freshness, or review conditions are unmet. Historical events are never silently rewritten.

Canonical display mapping

Product surfaces must use these exact meanings. They are event labels, not tiers, grades, or shorthand for evidence maturity:

Code	Canonical display label	Minimum displayable fact	Copy that is not permitted
T0	Registration recorded	A policy-scoped reference was registered.	Identity established; identity verified; candidate accepted.
T1	Claim recorded	At least one claim was received.	Evidence received; claim verified; evidence approved.
T2	Independent corroboration recorded	Identity confirmation and eligible non-referral substantive corroboration were recorded.	Verified professional; qualified; score available.
T3	Assessment and review recorded	The controlled assessment and required review record were completed.	Passed; probe passed; assessment score; credential earned.
T4	Field outcome and attribution corroborated	Field-outcome evidence and contribution attribution were independently corroborated after the prior chain.	Expert; top tier; production-ready; officially certified.

Readiness, freshness, result lifecycle, coverage, confidence, dispute state, and E0–E5 evidence-link maturity remain separate labels. A later event inherits the history of earlier events but does not inherit or imply a capability judgment.

3. Proposed readiness states

Readiness is an operational routing axis, not a person judgment:

registration_incomplete
claim_intake_available
corroboration_pending
assessment_pending
human_review_pending
refresh_required
appeal_pending
integrity_review_pending
workflow_complete
withheld
not_authorized

The reason for withheld or a restriction must be recorded using an approved, contestable reason code. A protected attribute, geography, employer prestige, school prestige, fame, or social following can never be a routing reason.

4. Result lifecycle

Phase 2 does not authorize a result. The proposal contract models the lifecycle so future systems cannot confuse a trust state with publication:

not_issued
draft
held
superseded
withdrawn
revoked

draft does not imply a numeric result. A later release may add an authorized result class only after satisfying the v0.1 scoring activation gates. The following remain false throughout this proposal:

official scoring release approved: false
numeric score present: false
credential issuance authorized: false
public profile publication authorized: false
employment decision use authorized: false

5. Prestige-neutral corroboration

Corroboration classes may include issuer-verified credentials, verified employment history, attributable repository history, a continuous public technical record, controlled assessment, field-outcome corroboration, and referrals. They prove only the fact named by the verification protocol.

Queue priority may consider whether a record has a secure, accessible, issuer-controlled verification route. It must not consider the issuer's market status. A small organization's signed employment assertion and a large organization's equivalent assertion receive the same verification treatment.

A referral is one item of evidence, not identity proof, capability proof, or a substitute for independent corroboration. Any future staked-referral design must prohibit automatic collective punishment. Potential voucher consequences require human investigation, evidence of knowing abuse, notice, and an independent appeal.

6. State transition requirements

Every proposed transition requires:

the exact policy and schema version;
purpose, consent, subject, and tenant binding;
eligible evidence and provenance references;
a non-geographic, non-prestige transition reason;
an append-only event timestamp and actor class;
unresolved contradiction and integrity state;
freshness policy evaluation;
correction and appeal availability; and
an explicit statement that no score authority was created.

The machine proposal represents this through a complete genesis history, opaque identifiers, exact policy and schema bindings, scope and provenance bindings, a digest chain, a deterministic reducer declaration, and a separate relational invariant gate. The gate rejects skipped or reversed progression, stale policy digests, broken history links, out-of-order timestamps, a current status that differs from the reduced history, advanced facts at an earlier state, referral-only T2 records, and T3 records without an assessment review fact. JSON Schema validation alone does not authorize or validate a transition.

Transitions must be idempotent, replayable, and reversible through a new event, not mutation. A machine may recommend routing but cannot issue a final adverse employment action or deny an appeal.

7. Public rendering rules

No individual record may render under this proposal. A future approved profile would need to show trust, readiness, result lifecycle, coverage, confidence, recency, limitations, benchmark version, and dispute state as visibly distinct labels. It must not use color or layout to make T2 and T4 look like performance grades.

Public aggregates are governed separately by the aggregate-register privacy contract.