Vexal Experience Framework

Stable

Applies to: Hub, Intake, SmartBlocks, Media, Portfolio, and future Vexal products

Updated: July 2026 — platform milestone

The Vexal Experience Framework is a set of cross-product contracts. Products share architecture and rules—not copied class libraries.

Governing rule

Vexal owns the client-facing experience. WordPress owns authentication security. Each Vexal product owns its authorization, routing, and customer-context rules.

Experience catalog

Experience	Purpose	Reference
Authentication Experience	Branded login, lost-password request, notices, post-reset return	Intake 1.0.028+, Hub 0.3.007+
Workspace Experience	Customer shell, account/site context, fail-closed access	Hub `/vexal-workspace/`
Dashboard Experience	Operator/admin product dashboards	Hub Operator Console; SmartBlocks admin
Card Experience	Trusted registered cards	Hub Workspace card registry
Invitation Experience	Secure invites and email-locked registration	Vexal Intake
Notification Experience	Email, notices, future SMS/activity	Evolving

Authentication Experience

Vexal owns UI — branded login and account routes.
WordPress owns credentials — hashes, reset keys, cookies, sessions, wp_signon, retrieve_password.
Product owns authorization — who may use this product’s client surface.
Product owns routing and notices — allow-listed, server-rendered messages only.
No parallel password store, custom reset tokens, or second session system.
wp-login.php keeps a link back to the product login; administrators keep core recovery.

See Authentication layers, Hub authentication, and Intake authentication.

Workspace Experience

Workspace Shell — theme-agnostic full-page app
Card Registry — trusted PHP-registered cards
Customer Context and Site Context — server-resolved
Fail-closed authorization — never guess the first account/site
No WordPress admin for Workspace customers
Operator capability does not invent customer context

See Hub Workspace.

Dashboard Experience

Dashboard Shell for operators/admins
Product cards and customer summaries where applicable
Product independence — do not conflate with customer Workspace

Card Experience

Cards are registered in a trusted PHP registry
Product-owned card implementations
Customer-safe data only; fail states are first-class
Designed for future extensibility without ad-hoc remote HTML

Invitation Experience

Client invitations prove email ownership for a product purpose
Registration and account ownership remain WordPress-backed
Email validation / locked invite email where authoritative
Authorized access after invite — product-specific rules

See Intake invitations.

Notification Experience

Email (product-owned today)
Workspace / account notices (allow-listed keys)
SMS — future shared implementation
Activity notifications / feeds — product-owned until a shared contract stabilizes

Anti-patterns

Copying Intake WI_* classes into Hub (or the reverse)
Guessing account/site when context is ambiguous
Granting Workspace context from operator capability alone
Rendering arbitrary query-string notice text
Globally hijacking all wp-login.php traffic