Chapter 5 of 12 · 2 min read
Expression Registry, Resolution, and Lifecycle
The roles of the Spec, Registry, public service, Foundation interface, and handler.
Word Wallet Web · v0.2 · Moses Sam Paul
Expression Registry, Resolution, and Lifecycle
Five responsibilities
The implementation separates responsibilities that are easy to confuse:
- The IoV Spec defines canonical protocol objects, schemas, grammar, and validation rules.
- The Expression Registry stores operational expression and Word Wallet records.
- Word Wallet Web exposes the versioned public API, authentication, consent, invocation, saving, and deletion boundaries.
- The Foundation website explains the research and provides the public interaction surface.
- The handler performs the expression-specific analysis under a declared contract.
The website is not protocol truth. The handler does not own the identity system. The Spec does not need to process participant text. This separation narrows authority and makes failures easier to locate.
Resolution
A resolver takes a stable expression slug or identifier and returns the active record and version contract. A client can then discover supported modalities, required consent scope, protocol trace, and handler contract version. Public resolution is a read operation; invocation is a separate, protected operation.
Lifecycle
The proposed lifecycle is:
draft → review → active → deprecated or archived
An eligible creator may create a draft. Creation is not registration. Review should verify grammar, protocol grounding, handler ownership, safety claims, consent text, retention policy, and governance. Only an approved record becomes active and publicly resolvable.
Deprecation preserves history while directing new clients to a successor. Archival ends active invocation without erasing the public lineage. Emergency suspension should be available for security or safety incidents and must generate an auditable reason.
Versioning and compatibility
An expression version is immutable once active. Corrections create a new version with explicit compatibility notes. Handler contract versions are recorded separately because a semantic definition and an execution contract can evolve at different speeds.
This model remains partly proposed. Phase 1 demonstrates active list and detail resolution for one expression; it does not yet operate the complete public submission and governance workflow.