Loading module
Resolving locale, route permissions, and workspace projection.
EX-PL-01 GOVERNANCE WALKTHROUGH
Document Type: Governance-to-UI Translation Constraint Specification
Procedure: EX-PL-01 — Land Plot Registration & Verification
Status: DRAFT — NON-AUTHORITATIVE INPUT
Version: 1.0
Date: 2026-02-09
1. Purpose of Governance Walkthrough
This document defines governance-level constraints that govern HOW the EX-PL-01 procedure states MAY be reflected in user-facing interfaces.
This document is NOT:
- UI/UX design
- User journey definition
- Workflow specification
- Backend implementation guide
This document IS:
- A set of MANDATORY visibility, wording, and messaging rules
READ 2026-03-28T23:42:21.903Z
READ 2026-03-29T04:52:41.869Z
CORE STRICT SAFE DELETE AFTER RERUN REPORT
PUBLIC | DRAFT | v1.0.0
READ 2026-03-29T03:13:33.020Z
A compliance bridge between governance states and future UIA constraint specification that UI/Copilot implementations MUST followAuthority:
This document is subject to governance validation and MUST NOT be treated as final until ratified.
2. Principles for UI Interpretation (Governance-Level)
2.1 State Reflection Principle
- UI MUST reflect the current governance state as the primary information element
- UI MUST NOT imply progress, likelihood of approval, or predicted outcomes
- UI MUST NOT show percentage completion, step counts, or visual progress bars during verification phases
2.2 Neutral Messaging Principle
- UI MUST use neutral, non-promissory language
- UI MUST NOT promise approvals, confirmations, or guarantees
- UI MUST NOT attribute delays, rejections, or decisions to individuals or external parties
2.3 Role-Based Visibility Principle
- UI MUST hide information not allowed to be visible to the current role
- UI MUST NOT leak verifier identity, internal notes, or decision reasoning to LAND_OWNER
- UI MUST maintain separation of duties through visibility controls
2.4 Blockchain Presentation Principle
- Blockchain MUST be presented ONLY as:
- Anchoring proof
- Settlement confirmation
- Cryptographic integrity reference
- Blockchain MUST NOT be portrayed as:
- Validator
- Decision-maker
- Process controller
3. State-by-State Governance Walkthrough
STATE: DRAFT
Purpose:
Land plot information is being prepared but not yet submitted.
- Status label: "Draft"
- Neutral description: "Land plot information is being prepared"
- Allowed actions: Edit, Delete, Submit
- Verifier information
- Verification criteria
- Internal system identifiers (beyond display ID)
- That submission will result in approval
- That verification is automatic
- Estimated approval time
- Only LAND_OWNER who created the draft MAY view or edit it
- Platform ADMIN MAY view for support purposes only (logged)
- MUST use neutral language: "Draft", "Not submitted"
- MUST NOT use: "Pending approval", "Waiting for verification"
STATE: SUBMITTED
Purpose:
Land plot registration has been submitted and is awaiting initial screening.
- Status label: "Submitted"
- Neutral description: "Registration submitted for review"
- Submission timestamp
- Reference ID
- Who will review it
- Review criteria details
- Internal routing or assignment logic
- That review will succeed
- Estimated review duration
- Likelihood of verification
- LAND_OWNER MAY view status but MUST NOT edit submitted information
- PLATFORM_ADMIN MAY view for assignment purposes
- VERIFIER assigned to this plot MUST NOT see other plots by same owner (unless governance allows)
- MUST use: "Submitted", "Under review"
- MUST NOT use: "Being processed", "In approval queue"
STATE: UNDER_VERIFICATION
Purpose:
Land plot is being verified by an assigned VERIFIER.
- Status label: "Under verification"
- Neutral description: "Platform verification in progress"
- Submission date and reference ID
- Verifier name or identity
- Verification progress or partial results
- Internal comments or notes
- Verification criteria checklist status
- Current progress percentage
- Expected completion time
- Likelihood of success or failure
- LAND_OWNER: read-only status view
- VERIFIER: full access to verification forms and evidence
- GOVERNANCE_MANAGER: read-only oversight
- Verification details MUST be hidden from LAND_OWNER until state transition
- MUST use: "Under verification", "Verification in progress"
- MUST NOT use: "Being approved", "Almost complete", "Final review"
STATE: VERIFICATION_COMPLETED
Purpose:
Verification has been completed and a decision has been made (accept, reject, or require correction).
- Status label: "Verification completed"
- Decision outcome (if governance permits disclosure):
- "Verified — Registered in platform registry"
- "Verification completed — Correction required"
- "Verification completed — Registration declined"
- Allowed next actions based on outcome
- Verifier identity
- Internal scoring or evaluation details
- Exact reasons for decline (unless explicitly provided by VERIFIER in formal notice)
- Legal ownership confirmation
- Government approval
- Binding property rights
- Decision outcome MUST be visible to LAND_OWNER
- Detailed verification records MAY be visible only if governance requires disclosure
- Verifier identity remains confidential unless organizational policy permits
- MUST use: "Verification completed", "Registered in platform registry", "Correction required"
- MUST NOT use: "Approved", "Ownership confirmed", "Land title validated"
STATE: CORRECTION_REQUIRED
Purpose:
Verification identified issues requiring correction by LAND_OWNER.
- Status label: "Correction required"
- Neutral description: "Additional information or correction needed"
- List of required corrections (if provided by VERIFIER)
- Allowed actions: Edit, Resubmit
- Verifier identity
- Internal rejection reasoning beyond what is formally communicated
- Other applicants' correction patterns
- That correction guarantees success
- That resubmission will be faster
- Number of attempts allowed (unless explicitly governed)
- LAND_OWNER MAY edit ONLY the fields marked for correction
- VERIFIER MAY view updated information after resubmission
- Original submission MUST remain in audit trail (immutable)
- MUST use: "Correction required", "Additional information needed"
- MUST NOT use: "Rejected (fixable)", "Minor issues detected"
STATE: REGISTERED
Purpose:
Land plot has successfully completed verification and is registered in the platform registry.
- Status label: "Registered"
- Neutral description: "Registered in platform registry"
- Registration reference ID
- Anchoring proof (if available):
- Algorand transaction reference
- BNB Chain transaction reference
- Allowed actions: View, Use in procedures (e.g., apply for inspection)
- Verifier identity or notes
- Internal risk scores or flags (if any)
- Other land owners' registrations (unless public by policy)
- Legal ownership confirmation
- Government validation
- Binding property rights
- Guarantee of inspection approval
- LAND_OWNER: full read access to own registered plot
- PUBLIC visibility: UNDEFINED — organizational decision required
- INSPECTOR or SERVICE_PROVIDER: may view if authorized for specific procedure instance
- MUST use: "Registered in platform registry", "Available for platform procedures"
- MUST NOT use: "Approved", "Ownership confirmed", "Land rights validated"
Anchoring Proof Presentation:
- MAY display blockchain transaction references
- MUST label as: "Anchoring proof", "Settlement reference"
- MUST NOT label as: "Blockchain approval", "Smart contract validation"
STATE: DECLINED
Purpose:
Verification was completed and registration was declined.
- Status label: "Registration declined"
- Neutral description: "Verification completed — registration not approved"
- Formal reason (if provided by VERIFIER)
- Allowed actions: Contact support, Appeal (if governance permits)
- Verifier identity
- Internal decision criteria or scoring
- Other declined applications
- Resubmission is not allowed
- Land owner is at fault
- Comparison to other applications
- LAND_OWNER: read-only status view
- GOVERNANCE_MANAGER: full audit access
- Decline reason MUST be documented but disclosure policy is UNDEFINED
- MUST use: "Registration declined", "Not registered"
- MUST NOT use: "Failed", "Rejected permanently", "Ineligible"
STATE: CANCELLED
Purpose:
Land owner or authorized role has cancelled the registration.
- Status label: "Cancelled"
- Neutral description: "Registration cancelled by request"
- Cancellation timestamp
- Whether cancellation affects other processes (unless explicitly linked)
- That cancellation is reversible
- That cancellation has external legal effects
- Cancelled registrations MUST remain in audit trail (immutable)
- Visibility to VERIFIER: UNDEFINED — organizational decision required
- MUST use: "Cancelled", "Registration withdrawn"
- MUST NOT use: "Deleted", "Removed"
4. Visibility Rules by Role (High-Level)
4.1 LAND_OWNER Visibility
- Own land plot status
- Own submissions and registration history
- Public-facing status labels
- Allowed actions in current state
- Anchoring proof (if registered)
- Verifier identity
- Internal notes, scores, or evaluations
- Other land owners' plots (unless public)
- Verification criteria details
- Assignment or routing logic
4.2 VERIFIER / CADASTRAL_VERIFIER Visibility
- Assigned land plot details
- Submitted evidence and documents
- Verification forms and checklists
- Decision history (if already decided)
- Land owner's other unrelated data
- Other verifiers' decisions (unless governance requires)
- Information classified above their clearance level
- VERIFIER MUST NOT verify land plots where conflict of interest exists
- VERIFIER identity MUST remain confidential to LAND_OWNER (unless organizational policy permits)
4.3 PLATFORM_ADMIN Visibility
- All land plot registrations (for operational purposes)
- Assignment and routing status
- Audit logs (read-only)
- Make verification decisions
- Override verifier assignments without governance authority
- Modify submitted evidence or verification results
- All ADMIN access to confidential information MUST be logged
4.4 GOVERNANCE_MANAGER Visibility
- All land plot registrations
- Full audit trail
- Verification decisions and reasoning
- Quality and compliance metrics
- MAY override assignments in exceptional cases (logged)
- MAY initiate CAPA or management review
- Perform verification directly
- Approve registrations
4.5 SYSTEM (Automated Anchoring Agent) Visibility
- Hash values of registered plots
- Anchoring transaction references
- Settlement status
- Access personal data
- Make governance decisions
- Alter land plot state
- SYSTEM MUST operate on cryptographic hashes ONLY
- SYSTEM MUST NOT interpret or evaluate land plot content
5. Copy & Terminology Constraints (Critical)
5.1 Prohibited Wording
UI MUST NOT use the following terms in the context of land plot registration:
- "Approved ownership"
- "Confirmed land rights"
- "Government-validated"
- "Ownership verified"
- "Legal confirmation"
- Action-taking terms or wording that implies an operational layer
- "Smart contract approval"
- "Blockchain validation"
- "Guaranteed registration"
5.2 Allowed Neutral Wording
UI MUST use neutral, governance-safe language:
- "Submitted for verification"
- "Under verification"
- "Verification completed"
- "Registered in platform registry"
- "Anchoring proof available"
- "Settlement reference recorded"
- "Correction required"
- "Registration declined"
5.3 Legal Disclaimer Requirement
Any UI element showing registered land plots MUST include a disclaimer such as:
"Platform registration does not constitute legal ownership confirmation, government validation, or property rights certification. For legal ownership matters, consult the Public Registry of Georgia or a licensed legal professional."
Exact wording: UNDEFINED — requires legal and organizational approval
6. Error, Delay, and Silence Rules
6.1 Long Verification Times
If verification takes longer than expected:
- Show state as "Under verification"
- Show submission date
- Guess when verification will complete
- Attribute delay to verifier, system, or land owner
- Suggest escalation unless governance permits
6.2 Temporary System Unavailability
If verification systems are temporarily unavailable:
- Show neutral status: "System temporarily unavailable"
- Preserve last known state
- Imply that submission failed
- Suggest resubmission
- Attribute fault
6.3 Anchoring Delays
If blockchain anchoring is delayed or pending:
- Show state as "Registered" (if governance decision was made)
- Show anchoring status separately: "Anchoring pending"
- Block registration completion on anchoring
- Imply that anchoring is approval
- Show blockchain as "processing" or "deciding"
- Anchoring is PROOF, not PREREQUISITE
- Registration state MUST be independent of anchoring completion
7. Copilot / UI Translation Rules
7.1 Translation Authority
UI designers and AI-assisted tools (e.g., GitHub Copilot) MAY translate this governance walkthrough into visual elements ONLY if:
- No prohibited wording is introduced
- No authority, confirmation, or guarantee is implied
- No additional governance meaning is inferred
- All state-based visibility rules are respected
7.2 Prohibited UI Translations
UI implementations MUST NOT:
- Add "Approve" buttons in states where approval is not governed
- Show "Confirmed" status before governance decision
- Display progress bars during verification
- Use gamification elements that imply success likelihood
- Show verifier identity to LAND_OWNER
7.3 Governance Violation Detection
- Contradicts this walkthrough
- Invents new states
- Promises outcomes
- Bypasses governance constraints
MUST be treated as a governance violation and corrected immediately.
8. Explicit Exclusions
This document does NOT define:
- UI component structure (React, Vue, HTML)
- CSS styling or layout
- User interaction patterns (clicks, forms, navigation)
- Backend APIs or services
- Database schemas
- Workflow automation logic
- Smart contract logic or blockchain implementations
This document defines ONLY:
- What MAY and MUST NOT be visible per state
- What MAY and MUST NOT be communicated via UI copy
- Constraints that any UI implementation MUST respect
9. UNDEFINED / Open Governance Questions
The following questions MUST be resolved by organizational governance before final UI implementation:
9.1 Visibility & Public Access
- UNDEFINED: Whether registered land plots are publicly visible
- UNDEFINED: Whether land owner identity is public or private
- UNDEFINED: Whether historical registrations are visible to new applicants
9.2 Progress Indicators
- UNDEFINED: Whether any form of progress indication is allowed during verification
- UNDEFINED: Whether estimated timelines may ever be shown (even as estimates)
9.3 Verifier Disclosure
- UNDEFINED: Whether verifier identity may be disclosed to LAND_OWNER after completion
- UNDEFINED: Whether verifier credentials may be shown
9.4 Correction Limits
- UNDEFINED: Maximum number of correction attempts allowed
- UNDEFINED: Whether correction history is visible to LAND_OWNER
9.5 Decline Communication
- UNDEFINED: Level of detail provided in decline reasoning
- UNDEFINED: Whether appeals are permitted and via what mechanism
9.6 Anchoring Display
- UNDEFINED: Whether anchoring proof must always be visible to LAND_OWNER
- UNDEFINED: Whether anchoring failure triggers state change or remains informational
10. Governance Change Impact
If governance states, roles, or constraints change:
- This walkthrough MUST be updated first
- UI implementations MUST be re-validated against updated walkthrough
- Any UI element that cannot comply MUST be disabled or removed
Precedence Rule:
Governance documents take precedence over UI implementations.
11. Document Status & Authority
Status: DRAFT — NON-AUTHORITATIVE INPUT
Governance Review Required: YES
Implementation Binding: NO (until ratified)
This document is subject to validation by organizational governance authority.
Until ratified, this document serves as:
- Draft guidance for UI translation
- Non-binding input for design and development
- Subject to revision, reduction, or rejection