🔐 Role Architecture Preview

Future participant role for a protected 6th Street workflow after privacy approval.

Future responsibilities: Draft appropriate meeting items in a protected future workflow. Receive clear revision guidance before anything reaches staff review. Use the system only for community-appropriate, non-private meeting content.

Not allowed: View other community members sensitive drafts. Approve content for the morning meeting. Manage roles, retention settings, or system configuration.

Future peer-support role for organizing meeting flow after protected access exists.

Future responsibilities: Help prepare meeting structure and role coverage. Route unclear items toward staff review instead of deciding sensitive content alone. Keep the morning process steady, respectful, and bounded.

Not allowed: Make final decisions on sensitive submissions. Access private review notes beyond approved limits. Change system settings or retention rules.

Future staff-review role for protected review of sensitive or meeting-boundary content.

Future responsibilities: Review future submissions before they can reach a printed or read-aloud packet. Apply dignity, privacy, and safety policy consistently. Escalate policy questions to program leadership when needed.

Not allowed: Bypass audit logging or retention rules. Use the system for unrelated case notes or private treatment details. Change role permissions or infrastructure settings.

Future leadership role for approving policy, retention, and escalation boundaries.

Future responsibilities: Approve the staff-review procedure before live use. Set retention and escalation expectations with privacy review. Resolve high-impact workflow or policy questions.

Not allowed: Use public-safe demo pages as protected systems. Skip privacy review for sensitive workflow expansion. Store community submissions outside the approved system of record.

Future technical maintainer role for operating infrastructure without unnecessary content access.

Future responsibilities: Maintain source-backed packet generation and protected infrastructure. Keep secrets out of client code and version control. Implement access-control and audit requirements as approved.

Not allowed: Review sensitive community submissions by default. Grant themselves broad content access without approval. Use OpenAI or external services for submissions without separate approval.