Trust, roles and permissions

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

Authority boundaries

Public module demos and storyboards remain fictional. The separate Trust Center requires server-side permission checks; a hidden URL or browser role label is not authorization.

Designed model

Separate roles, permissions, organizations, sites, assignments and privileged accounts.
Verified provisioning, MFA, independent approvals and non-browser-writable launch review.
Authorization-checking database functions with atomic audit writes.
Youth-owner data policies never gain staff overrides.
Invitation approvers must remain currently verified, authorized and scoped at acceptance.
Initial CHI administrator bootstrap is out-of-band, never automatic.

Current safe inspection

Read the governance reference and public role tour. Do not try to provision roles, approve invitations or activate privileged access through a demonstration. An unauthorized Trust Center visit must remain unavailable.

Why a role name is insufficient

A prospective donor, volunteer or partner cannot gain case access by selecting a role or joining a circle. Even verified staff need the permitted dataset, site/project and assignment scope.

Designed versus verified

The V5.6 baseline reported read-only containment evidence. It did not establish positive privileged lifecycle, MFA enrollment, invitation delivery or multi-account isolation. No fresh operational verification is claimed by this article.

Before privileged operation

Verified CHI authorities, safeguarding/security review, scoped fixtures, backup readiness, rollback planning and separately approved tests remain prerequisites.