Renata protected role mapping schema planning
Account Role Mapping Schema Planning
Purpose
This page defines how future pseudonymous actor references may eventually be associated with role sets, workflow scopes, and permission scopes.
It is schema planning only. It creates no accounts, actor records, role assignments, submissions, tables, migrations, runtime permissions, or write paths.
Current Account and Identity Boundary
Product
Renata
The Sixth Sense at 6th StreetAccess boundary
outer-boundary-only
outer-boundary-onlyAccount storage
false
not implementedRole assignment
false
not implementedAccount role mapping schema is metadata only; no accounts, actor records, identity maps, live role assignments, submissions, tables, migrations, or writes exist.
Why Role Mapping Comes After Actor References
Role mapping is only meaningful after actor references have clear identity boundaries. This phase keeps role planning tied to opaque actor refs and avoids turning Cloudflare Access claims, names, emails, resident profiles, or staff profiles into live permissions.
No account storage, actor storage, identity mapping, role assignment, live submissions, staff decisions, database writes, active migrations, or executable SQL files are added.
Role Mapping Principles
- Role mappings must use pseudonymous actor refs, not real identity.
- Role mappings must not contain email, name, initials, room number, case number, Cloudflare claim values, JWTs, tokens, or resident/staff profile fields.
- Role mappings must be scoped by community and workflow context.
- Role mappings must not expose Cloudflare Access claims.
- Role mappings must not create attendance, participation, performance, scoring, ranking, discipline, or compliance tracking.
- Role mappings must not enable submissions until draft, review, retention, audit, and staff/privacy gates are approved.
- Role mappings must be revocable and auditable before any pilot.
Planned Role Mapping Tables
| Table | Purpose | Status | Sensitivity | Fields | Activation gates | Launch blockers |
|---|---|---|---|---|---|---|
future_actor_role_mappings | maps future pseudonymous actor refs to role keys within a community/workflow scope | planned-only | identity-adjacent-role-configuration-sensitive | id, community_id, actor_ref, role_set_template_id, role_key, workflow_scope, mapping_status, version, created_at, updated_at, archived_at | identity policy approved; pseudonymous actor policy approved; role mapping policy approved; Cloudflare Access boundary reviewed; D1 schema reviewed; retention policy approved; deletion policy approved; audit policy approved; staff review procedure approved; privacy approval complete; rollback plan approved; small pilot approved | no account storage exists; no actor storage exists; no identity mapping exists; no role assignment model exists; no user admin CRUD exists; no live draft schema is approved; no staff review procedure is approved; no retention/deletion policy is approved; no audit policy is approved; no active migration is approved; no database write path is approved |
future_actor_permission_scopes | stores planned permission scope metadata for an actor-role mapping | planned-only | permission-scope-sensitive | id, actor_ref, role_key, workflow_scope, permission_scope, permission_key, permission_status, created_at, updated_at | identity policy approved; pseudonymous actor policy approved; role mapping policy approved; Cloudflare Access boundary reviewed; D1 schema reviewed; retention policy approved; deletion policy approved; audit policy approved; staff review procedure approved; privacy approval complete; rollback plan approved; small pilot approved | no account storage exists; no actor storage exists; no identity mapping exists; no role assignment model exists; no user admin CRUD exists; no live draft schema is approved; no staff review procedure is approved; no retention/deletion policy is approved; no audit policy is approved; no active migration is approved; no database write path is approved |
future_actor_role_status_history | stores planned lifecycle/status transitions for role mappings | planned-only | role-lifecycle-audit-sensitive | id, actor_ref, role_key, mapping_status, version, change_reason, created_at, archived_at | identity policy approved; pseudonymous actor policy approved; role mapping policy approved; Cloudflare Access boundary reviewed; D1 schema reviewed; retention policy approved; deletion policy approved; audit policy approved; staff review procedure approved; privacy approval complete; rollback plan approved; small pilot approved | no account storage exists; no actor storage exists; no identity mapping exists; no role assignment model exists; no user admin CRUD exists; no live draft schema is approved; no staff review procedure is approved; no retention/deletion policy is approved; no audit policy is approved; no active migration is approved; no database write path is approved |
future_actor_role_audit_events | stores planned config-only audit events for future role mapping changes | planned-only | audit-sensitive | id, actor_ref, actor_ref_issued_by, audit_event_type, change_reason, workflow_scope, created_at | identity policy approved; pseudonymous actor policy approved; role mapping policy approved; Cloudflare Access boundary reviewed; D1 schema reviewed; retention policy approved; deletion policy approved; audit policy approved; staff review procedure approved; privacy approval complete; rollback plan approved; small pilot approved | no account storage exists; no actor storage exists; no identity mapping exists; no role assignment model exists; no user admin CRUD exists; no live draft schema is approved; no staff review procedure is approved; no retention/deletion policy is approved; no audit policy is approved; no active migration is approved; no database write path is approved |
Planned Field Map
idcommunity_idactor_refrole_set_template_idrole_keyworkflow_scopepermission_scopepermission_keypermission_statusmapping_statusversioncreated_atupdated_atarchived_atactor_ref_issued_bychange_reasonaudit_event_type
- actor_ref_issued_by is conceptual only
- actor_ref_issued_by must not store email, name, Cloudflare identity, JWT, token, resident profile, or staff profile data
- no real users are linked
- no role mapping is live
- role_set_template_id is a future config reference only and must not imply live role CRUD
- permission_scope is planning metadata only and must not grant runtime permissions
Relationship Boundaries
| Relationship | Status | Allowed future use | Prohibited use |
|---|---|---|---|
| pseudonymous actor ref to planned role key | planned-only | Could connect an approved opaque actor ref to a role key inside one community/workflow scope. | Must not connect to real email, name, Cloudflare claim, resident profile, staff profile, or live assignment. |
| role key to future role-set template | planned-only | Could reference approved role-set template metadata without creating a live role admin workflow. | Must not create live role CRUD, permission changes, or user assignment. |
| actor role mapping to workflow scope | planned-only | Could constrain a future role mapping to a draft, review, or visibility planning scope. | Must not enable live pull-up/push-up collection, staff decisions, or Morning Sheet placement. |
| actor role mapping to permission scope | planned-only | Could model planned permission visibility before any runtime enforcement exists. | Must not grant permissions, export records, target D1 writes, or expose Access claims. |
| actor role mapping to future audit event | planned-only | Could support future config-only audit metadata once audit and retention gates are approved. | Must not store identity values, staff notes, submission content, or surveillance metrics. |
Validation Rules
Future schema must support
- pseudonymous actor refs without real identity
- role-set template reference without live assignment
- workflow-scoped permission planning
- revocation/archival metadata
- audit event planning
- retention/deletion planning
Future schema must not support
- app-level login
- email storage
- real names
- user profiles
- resident profiles
- staff profiles
- live role assignment
- live submissions
- staff decisions
- attendance tracking
- participation tracking
- participation analytics
- scoring/ranking/compliance metrics
Excluded Identity and Tracking Fields
emailnamefirst namelast nameinitialsphoneaddressroom numbercase numberlegal identifiermedical identifierinsurance identifierCloudflare identity headerJWTtokengroup claimraw Access claimsresident profile detailsstaff profile detailssubmission contentpull-up contentpush-up contentstaff review notesattendance dataparticipation dataparticipation analyticsscoring dataranking datadiscipline pointscompliance metricsresident performance metrics
Audit Requirements
- audit policy must exist before account role mappings are stored
- future audit events must use opaque actor refs and conceptual issuer refs only
- audit events must not store email, name, Cloudflare claims, JWT, token, group, resident profile, or staff profile fields
- audit events must distinguish planned creation, revocation, archival, restoration, and scope changes
- audit events must not become attendance tracking, participation analytics, scoring, compliance reporting, or staff surveillance
Retention And Deletion Considerations
- role mappings require retention windows before storage
- role mappings require deletion and revocation rules before storage
- archived mappings must not be reusable for new live workflows without policy review
- status history must not become resident or staff history
- permission scopes must not preserve identity mapping after deletion decisions
- audit events must have a retention boundary before writes exist
Required Gates Before Storage
- identity policy approved
- pseudonymous actor policy approved
- role mapping policy approved
- Cloudflare Access boundary reviewed
- D1 schema reviewed
- retention policy approved
- deletion policy approved
- audit policy approved
- staff review procedure approved
- privacy approval complete
- rollback plan approved
- small pilot approved
What Remains Blocked
- app-level login
- account creation
- password fields
- email capture
- real user names
- real resident names
- real staff names
- real emails
- Cloudflare Access email display
- Cloudflare Access name display
- Cloudflare Access group display
- Cloudflare Access JWT display
- Cloudflare Access token display
- Cloudflare Access header display
- Cloudflare Access claim storage
- account records
- account storage
- actor records
- actor storage
- identity mapping
- role assignment
- live role assignment
- resident profiles
- staff profiles
- user admin CRUD
- live pull-up forms
- live push-up forms
- submission collection
- staff approval/rejection
- Morning Sheet live placement
- database writes
- write endpoints
- active migrations
- executable SQL files
- D1 account/user/actor/role/submission tables
- attendance tracking
- participation tracking
- participation analytics
- scoring, ranking, discipline points, or compliance metrics
- billing, lead capture, CRM, Stripe, or sales forms
- AI for real submissions
- sensitive community content storage
Recommended Next Phase
Phase 8.5 - Pull-Up/Push-Up Draft Schema Planning
After role mapping boundaries are planned, the next safe step is planning pull-up/push-up draft schema boundaries without collecting submissions or creating write paths.
Boundaries: no accounts in Phase 8.4; no account storage; no actor storage; no identity mapping; no live role assignment; no user admin CRUD; no live submissions; no staff decisions; no database writes; no active migrations; no executable SQL files.
recommended-next