Renata protected actor model planning

Pseudonymous Actor Model Planning

Protected, read-only planning for future opaque actor references before any account, identity, or workflow storage exists.

This is a protected, read-only actor-model planning page. It does not create accounts, store identities, map real users, assign roles, collect submissions, or write data.

Purpose

This page defines how Renata could eventually represent a person inside workflow records without storing or exposing real identity values.

It is planning-only. Actor references are not accounts, not identity records, not role assignments, and not live submission owners.

Current Identity Boundary

Product

Renata

The Sixth Sense at 6th Street

Access boundary

outer-boundary-only

outer-boundary-only

Actor storage

false

not implemented

Identity mapping

false

not implemented

Actor references are planning labels only; no actor records, identity maps, accounts, roles, submissions, staff decisions, or writes exist.

Why Pseudonymous Actors Come Before Accounts

Live pull-up/push-up workflows would eventually need references for draft authors, subjects, reviewers, audit actors, and visibility rules. Planning those references before accounts keeps the model privacy-first and avoids leaking real identity into workflow records.

This phase does not create those references. It defines the boundaries that future schema planning must respect.

Actor Model Principles

  • Actor references are not real identity.
  • Actor references must not contain email, name, initials, room number, case number, or resident/staff identifiers.
  • Actor references should be opaque and non-semantic.
  • Actor references should be scoped to a community and workflow context.
  • Actor references should not be reversible without a separately approved identity policy.
  • Actor references should not expose Cloudflare Access claims.
  • Actor references should not become attendance, participation, performance, scoring, or compliance tracking.

Planned Actor Reference Types

Reference Purpose Allowed future use Prohibited use Sensitivity Gates before storage
community_actor_ref Future opaque actor reference scoped to a community context. Could identify a pseudonymous actor inside approved community-scoped configuration after identity policy approval. Must not contain real identity, role labels, room numbers, case numbers, Cloudflare claims, or profile data. configuration-sensitive identity policy approved; privacy approval complete; retention policy approved; deletion policy approved
workflow_actor_ref Future opaque actor reference scoped to one workflow family. Could separate actor references by workflow context so pull-up/push-up records do not share unnecessary identifiers. Must not become cross-workflow tracking, participation analytics, scoring, or resident history. workflow-sensitive actor mapping policy approved; workflow scope approved; audit policy approved; small pilot approved
reviewer_actor_ref Future opaque staff-review actor reference for audit trails after staff review policy exists. Could support staff review accountability without exposing staff names in workflow records. Must not store staff names, emails, Cloudflare groups, staff profiles, or surveillance metrics. staff-sensitive staff review procedure approved; staff privacy approval complete; audit policy approved
submitter_actor_ref Future opaque draft author reference for approved pull-up/push-up draft storage. Could associate a draft with a pseudonymous author only after live draft pilot gates are approved. Must not enable live submissions, identity lookup, participation tracking, or resident scoring in this phase. submission-sensitive role mapping policy approved; draft schema approved; retention policy approved; small pilot approved
subject_actor_ref Future opaque subject reference for a person or context mentioned in a draft when policy allows. Could support staff-reviewed workflow routing only after privacy and subject-visibility rules exist. Must not create resident profiles, staff profiles, behavior history, discipline records, or performance dashboards. high subject visibility policy approved; staff review procedure approved; deletion policy approved
system_actor_ref Future opaque system reference for automated lifecycle events. Could mark system-generated audit events without linking to a person. Must not be used to hide real staff decisions, AI processing for real submissions, or database writes without audit approval. audit-sensitive audit policy approved; system event taxonomy approved; rollback policy approved

Synthetic Actor Examples

These are synthetic labels only. They are not residents, staff, Cloudflare users, accounts, roles, or stored actor records.

actor_alpha

synthetic community actor placeholder

Allowed future use: Static planning example for an opaque community-scoped actor ref.

Prohibited use: No real user mapping, no role assignment, no identity lookup, no submission ownership.

synthetic-preview-only

actor_bravo

synthetic workflow actor placeholder

Allowed future use: Static planning example for a workflow-scoped actor ref.

Prohibited use: No cross-workflow tracking, no participation analytics, no behavior scoring.

synthetic-preview-only

actor_charlie

synthetic reviewer actor placeholder

Allowed future use: Static planning example for a future staff-review audit ref.

Prohibited use: No staff name, email, profile, group claim, approval, rejection, or staff decision.

synthetic-preview-only

actor_delta

synthetic submitter actor placeholder

Allowed future use: Static planning example for a future draft author ref.

Prohibited use: No live pull-up form, no live push-up form, no submission collection, no identity mapping.

synthetic-preview-only

actor_echo

synthetic subject actor placeholder

Allowed future use: Static planning example for a future subject ref after privacy gates.

Prohibited use: No resident profile, staff profile, case history, attendance record, or scoring record.

synthetic-preview-only

Future Workflow Usage

Future use Boundary Blocked until
Draft author reference A future approved draft schema may use an opaque submitter actor ref. identity policy, actor mapping policy, role mapping policy, draft schema, retention, deletion, audit, staff review, privacy, and pilot approval
Subject reference A future approved staff-reviewed workflow may use an opaque subject actor ref. subject visibility policy, privacy approval, staff review procedure, deletion policy, and small pilot approval
Reviewer reference A future approved review workflow may use an opaque reviewer actor ref for audit metadata. staff review procedure, staff privacy approval, audit policy, and retention policy
Audit actor reference A future approved audit model may reference a pseudonymous actor for lifecycle events. audit policy, rollback policy, identity policy, and privacy approval
Visibility rules A future approved visibility model may use actor refs to constrain who sees a draft or review state. role mapping policy, Morning Sheet visibility policy, staff review procedure, and small pilot approval

Prohibited Identity Fields

emailnamefirst namelast nameinitialsphoneaddressroom numbercase numberlegal identifiermedical identifierinsurance identifierCloudflare identity headerJWTtokengroup claimraw Access claimsresident profile detailsstaff profile details

What Actor Refs Must Never Become

  • attendance tracking
  • participation tracking
  • participation analytics
  • performance scoring
  • recovery scoring
  • ranking
  • discipline points
  • compliance metrics
  • resident productivity dashboards
  • staff surveillance dashboards
  • clinical outcome claims
  • behavioral prediction scores

Future Mapping Rules

  • no actor storage in Phase 8.2
  • no identity mapping in Phase 8.2
  • no reversible mapping without separately approved identity policy
  • no Cloudflare Access claim storage
  • no direct email, name, group, token, JWT, or identity-header fields
  • no role assignment from actor refs
  • no live submission ownership from actor refs
  • no actor refs in runtime endpoints until storage, privacy, retention, and audit gates are approved

Retention And Deletion Considerations

  • actor refs need retention windows before storage
  • actor refs need deletion rules before storage
  • actor refs need rollback rules before pilot use
  • actor refs must not preserve identity after a deletion decision
  • actor refs must not link to resident history without separate approval
  • actor refs must not link to staff history without separate approval

Required Gates Before Storage

  • identity policy approved
  • actor mapping policy approved
  • role mapping policy approved
  • retention policy approved
  • deletion policy approved
  • audit policy approved
  • staff review procedure approved
  • privacy approval complete
  • small pilot approved

Safe Implementation Sequence

  1. Phase 8.3 - Actor Reference Schema Planning

    future-planning

    No live submissions begin until every gate is resolved.

  2. Phase 8.4 - Account Role Mapping Schema Planning

    future-planning

    No live submissions begin until every gate is resolved.

  3. Phase 8.5 - Pull-Up/Push-Up Draft Schema Planning

    future-planning

    No live submissions begin until every gate is resolved.

  4. Phase 8.6 - Staff Review Procedure Planning

    future-planning

    No live submissions begin until every gate is resolved.

  5. Phase 8.7 - Live Draft Pilot Readiness Review

    future-planning

    No live submissions begin until every gate is resolved.

Blocked Capabilities

  • 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
  • actor records
  • actor storage
  • identity mapping
  • resident profiles
  • staff profiles
  • user admin CRUD
  • role assignment
  • live pull-up forms
  • live push-up forms
  • submission collection
  • staff approval/rejection
  • Morning Sheet live placement
  • database writes
  • write endpoints
  • active migrations
  • D1 account/user/actor/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.3 - Actor Reference Schema Planning

After the actor model is defined, the next safe step is planning schema metadata for actor refs without creating tables, storage, identity mapping, or live workflows.

Boundaries: no storage in Phase 8.2; no actor mapping yet; no identity capture yet; no live submissions yet; no staff decisions; no database writes; no active migrations.

recommended-next