1. Purpose & Scope

This document defines the governance state machine for EX-PL-01 — Land Plot Registration & Verification.

In scope: governance states, transitions, authority boundaries, and invariants.
Out of scope: UI design, backend logic, APIs, workflows, automation, or timelines.

2. Canonical List of Governance States

| State | Description | Terminal | |---|---|---| | DRAFT | Land plot information is prepared but not submitted. | No | | SUBMITTED | Registration submitted and awaiting screening/assignment. | No | | UNDER_VERIFICATION | Verification is underway by assigned verifier. | No | | VERIFICATION_COMPLETED | Verification is complete; outcome determined. | No | | CORRECTION_REQUIRED | Corrections requested from Land Owner. | No | | REGISTERED | Registered in platform registry. | Yes | | DECLINED | Registration declined. | Yes | | CANCELLED | Registration cancelled or draft removed. | Yes |

3. State Definitions

3.1 DRAFT

• Description: Land Owner prepares registration content prior to submission.
• Entry Conditions (MUST): A new land plot record is initialized by Land Owner.
• Exit Conditions (MUST): Land Owner submits for verification OR cancels/removes draft.
• Allowed Transitions (TO): SUBMITTED, CANCELLED
• Prohibited Transitions: UNDER_VERIFICATION, VERIFICATION_COMPLETED, REGISTERED, DECLINED
• Responsible Roles: LAND_OWNER (primary), PLATFORM_ADMIN (support only)
• Governance Invariants: Draft data MUST be visible only to the Land Owner and authorized support personnel.

3.2 SUBMITTED

• Description: Registration submitted and queued for verification assignment.
• Entry Conditions (MUST): Land Owner submits a complete registration package as defined by governance records.
• Exit Conditions (MUST): Verification is initiated by an authorized verifier.
• Allowed Transitions (TO): UNDER_VERIFICATION
• Prohibited Transitions: REGISTERED, DECLINED, VERIFICATION_COMPLETED, CORRECTION_REQUIRED
• Responsible Roles: PLATFORM_ADMIN (assignment), VERIFIER (accept assignment)
• Governance Invariants: Land Owner MUST NOT modify submitted data unless a correction state is issued.

3.3 UNDER_VERIFICATION

• Description: Verification activities are performed by the assigned verifier.
• Entry Conditions (MUST): Verifier assignment is complete and verification has started.
• Exit Conditions (MUST): Verification outcome is recorded.
• Allowed Transitions (TO): VERIFICATION_COMPLETED
• Prohibited Transitions: REGISTERED, DECLINED, CORRECTION_REQUIRED, CANCELLED
• Responsible Roles: VERIFIER (primary), GOVERNANCE_MANAGER (oversight)
• Governance Invariants: Verifier identity SHALL remain confidential from Land Owner.

3.4 VERIFICATION_COMPLETED

• Description: Verification is complete; outcome is determined.
• Entry Conditions (MUST): Verifier records a conclusive outcome.
• Exit Conditions (MUST): Outcome is finalized into one of the terminal or correction states.
• Allowed Transitions (TO): REGISTERED, DECLINED, CORRECTION_REQUIRED
• Prohibited Transitions: UNDER_VERIFICATION, SUBMITTED
• Responsible Roles: VERIFIER (recommendation), GOVERNANCE_MANAGER (final authority) — UNDEFINED
• Governance Invariants: Outcome MUST be recorded without implying legal ownership confirmation.

3.5 CORRECTION_REQUIRED

• Description: Corrections are required from Land Owner.
• Entry Conditions (MUST): Verifier identifies required corrections.
• Exit Conditions (MUST): Land Owner resubmits corrected information.
• Allowed Transitions (TO): SUBMITTED
• Prohibited Transitions: REGISTERED, DECLINED, UNDER_VERIFICATION (unless explicitly authorized)
• Responsible Roles: LAND_OWNER (correction), VERIFIER (validation)
• Governance Invariants: Corrections MUST be limited to requested items; scope limits are UNDEFINED.

3.6 REGISTERED

• Description: Plot is registered in the platform registry.
• Entry Conditions (MUST): Verification outcome is positive and registration is issued.
• Exit Conditions (MUST): None; terminal state.
• Allowed Transitions (TO): None
• Prohibited Transitions: Any non-terminal state
• Responsible Roles: GOVERNANCE_MANAGER or AUTHORIZED REGISTRY ROLE — UNDEFINED
• Governance Invariants: Registration MUST NOT be presented as legal ownership confirmation.

3.7 DECLINED

• Description: Registration is declined.
• Entry Conditions (MUST): Verification outcome is negative and decline is issued.
• Exit Conditions (MUST): None; terminal state.
• Allowed Transitions (TO): None
• Prohibited Transitions: Any non-terminal state
• Responsible Roles: GOVERNANCE_MANAGER or AUTHORIZED DECISION ROLE — UNDEFINED
• Governance Invariants: Decline reasons MUST follow disclosure policy — UNDEFINED.

3.8 CANCELLED

• Description: Registration is cancelled or a draft is removed.
• Entry Conditions (MUST): Cancellation is requested by the Land Owner OR authorized by governance — UNDEFINED.
• Exit Conditions (MUST): None; terminal state.
• Allowed Transitions (TO): None
• Prohibited Transitions: Any non-terminal state
• Responsible Roles: LAND_OWNER (draft cancellation), GOVERNANCE_MANAGER (other cases) — UNDEFINED
• Governance Invariants: Cancellation MUST be logged and auditable.

4. Transition Matrix

| From | To | Condition (MUST) | Responsible Role | |---|---|---|---| | DRAFT | SUBMITTED | Land Owner submits complete registration package. | LAND_OWNER | | DRAFT | CANCELLED | Draft is removed by Land Owner. | LAND_OWNER | | SUBMITTED | UNDER_VERIFICATION | Verifier assignment accepted and verification initiated. | PLATFORM_ADMIN, VERIFIER | | UNDER_VERIFICATION | VERIFICATION_COMPLETED | Verifier records final outcome. | VERIFIER | | VERIFICATION_COMPLETED | REGISTERED | Outcome recorded as verified and registration is issued. | GOVERNANCE_MANAGER — UNDEFINED | | VERIFICATION_COMPLETED | CORRECTION_REQUIRED | Outcome recorded as correction required. | VERIFIER | | VERIFICATION_COMPLETED | DECLINED | Outcome recorded as decline. | GOVERNANCE_MANAGER — UNDEFINED | | CORRECTION_REQUIRED | SUBMITTED | Land Owner resubmits corrected information. | LAND_OWNER |

Any transition not listed above is PROHIBITED unless explicitly authorized by governance policy.

5. Correction Loops

• The only defined correction loop is: CORRECTION_REQUIRED → SUBMITTED.
• Additional correction paths (e.g., direct return to UNDER_VERIFICATION) are UNDEFINED — GOVERNANCE DECISION REQUIRED.
• Maximum correction cycles are UNDEFINED — GOVERNANCE DECISION REQUIRED.

6. Terminal States

Terminal states are REGISTERED, DECLINED, and CANCELLED.
These states SHALL NOT transition to any other state within EX-PL-01.

7. Audit & Traceability Requirements

• Every state transition MUST be logged with: state_from, state_to, actor, timestamp, and reason.
• Evidence references (e.g., registration package, verification record) MUST be traceable to the transition.
• Audit logs SHALL be append-only and immutable.

8. Anchoring / Settlement Positioning

• Anchoring Proof MAY be generated only after REGISTERED — UNDEFINED trigger authority.
• Anchoring Proof SHALL be treated as cryptographic integrity reference only.
• Settlement reference, if used, SHALL represent finalization only and MUST NOT imply approval authority.
• Any anchoring/settlement sequencing is UNDEFINED — GOVERNANCE DECISION REQUIRED.

9. Explicit UNDEFINED Items

• Final authority role for REGISTERED and DECLINED outcomes.
• Cancellation rules after SUBMITTED or UNDER_VERIFICATION.
• Disclosure policy for decline reasons.
• Scope limits for correction requests.
• Maximum correction cycles.
• Anchoring Proof trigger authority and timing.
• Settlement reference usage within EX-PL-01.