System architecture and data boundaries

Public practice, private accounts, protected Trust and quarantined network remain separate.

Concept prototype. Do not submit sensitive information. Planned instructions describe intended design, not an activated service.

Content owner: Program content reviewer (proposed; CHI assignment pending)
Review: Source-reviewed documentation; organizational and professional validation pending.
History: V5.8: public reference foundation · V6.0: enterprise specifications and linked registers

Application model

React/TanStack Start provides routed pages and server functions. Lovable Cloud supplies existing auth and database services. The same backend serves preview and published versions; drafts are not data isolation.

Data model boundaries

Public documentation and demonstrations: browser-safe structured content and temporary memory only.
Account scope: owner-only saved journeys; private reflections in a separate table.
Trust: distinct account, organization, role, permission, approval, assignment and audit concepts.
Legacy network: unscoped tables and mutation functions remain quarantined from browser roles.
Impact Partners: local practice only, not a persistent contribution system.

Connections require purpose

Module connectors depict proposed, gated handoffs. They do not describe a universally shared database or unrestricted cross-module read access. A public tour never imports the protected capabilities catalog.

Integration limits

Source references for account services are not proof of live provider delivery. No payment, messaging, live AI, real kiosk or operational partner integration is enabled by this assignment. No provider credentials or private data appear in this manual.

Controlled development

Continue in the existing project; earlier independent-Remix recommendations were superseded by V5.6. Before backend changes: classify data, verify actual backups/recovery, confirm CHI authority, document dependencies/grants/RLS/rollback and obtain separate scoped approval. Publication is separate.

Why demos cannot prove operation

A simulated save/return or staff approval cannot verify account persistence, authorization or delivery. Source checks, read-only catalog checks and production write testing are different evidence classes.