Staff Privacy Review Checklist
Purpose
This checklist gives staff and privacy owners a protected planning surface for deciding whether future pull-up and push-up workflows are safe to design beyond synthetic previews.
This page does not record decisions. It only lists decisions that must exist before live work begins.
Why Staff/Privacy Review Comes Before Live Workflows
Pull-ups and push-ups should support repair, recognition, and community safety. Before any live data path exists, staff and privacy owners need to approve role boundaries, excluded content, retention, review, visibility, export, AI, and no-tracking rules.
Staff decisions required
Staff approval workflow
Question: Who can make a final public-display decision for pull-ups and push-ups?
Why it matters: Public reading needs accountable review so repair and recognition do not become shaming or disclosure.
Required decision: Define staff reviewer authority, escalation path, and final display boundary.
Risk if unresolved: Drafts could be treated as approved before the review process is ready.
Related: /protected-preview/staff-review-queue/
No staff decisions are created in this phase.
requires-staff-decisionRole mapping
Question: Which future roles may draft, review, configure, or view workflow records?
Why it matters: Role boundaries prevent a preview from becoming a broad access surface.
Required decision: Approve resident, peer-leader, staff-reviewer, and program-admin permissions.
Risk if unresolved: Too many people could see or act on sensitive workflow content.
Related: /protected-preview/account-setup/
No app accounts or role assignments exist.
requires-staff-decisionRejected submission handling
Question: What happens when an item is blocked or not appropriate?
Why it matters: Rejected content needs a non-punitive, privacy-preserving handling rule.
Required decision: Define whether blocked content is deleted, summarized, retained briefly, or escalated.
Risk if unresolved: Rejected drafts could be mishandled or retained unnecessarily.
Related: /protected-preview/staff-review-queue/
No rejection action exists.
requires-staff-decisionPrivacy decisions required
Privacy boundaries
Question: What identity and content fields are allowed, minimized, or prohibited?
Why it matters: Pull-up and push-up workflows may touch sensitive community context.
Required decision: Approve allowed fields, excluded fields, visibility rules, and data minimization.
Risk if unresolved: The system could collect more identity or community information than is safe.
Related: docs/architecture/submission-privacy-and-access-control.md
No identity values, resident profiles, or sensitive content are stored.
requires-privacy-approvalContent exclusions
Question: What must never be submitted or retained?
Why it matters: Clear exclusions protect medical, legal, trauma, diagnosis, and private-history boundaries.
Required decision: Review and approve hard exclusions before live collection is considered.
Risk if unresolved: Unsafe or private details could enter a future workflow.
Related: /protected-preview/pullup-pushup-workflow/
No live submission intake exists.
ready-for-reviewRetention decisions required
Retention policy
Question: How long should drafts, reviews, display text, and audit summaries remain?
Why it matters: Retention should be short, intentional, and appropriate to the content risk.
Required decision: Approve windows for drafts, review states, approved display text, archives, and audit events.
Risk if unresolved: Sensitive content could be kept too long or deleted without accountability.
Related: /protected-preview/data-schema-design/
No retention timers or deletion jobs exist.
requires-staff-decisionDeletion policy
Question: What should be deleted, summarized, or archived after each workflow state?
Why it matters: Deletion policy defines what the app must not keep.
Required decision: Approve deletion rules for unsubmitted, blocked, revised, approved, archived, and expired records.
Risk if unresolved: Blocked or sensitive drafts could remain beyond their useful purpose.
Related: docs/architecture/live-data-schema-design.md
No delete workflow exists.
requires-privacy-approvalAudit/logging decisions required
Audit logging
Question: Which future actions need audit events, and who may see them?
Why it matters: Audit logs protect staff accountability while minimizing sensitive content.
Required decision: Design minimal audit events for creation, review, revision, display, archive, expiry, and export.
Risk if unresolved: The app could either lack accountability or over-collect sensitive detail.
Related: /protected-preview/data-schema-design/
No audit logging code exists.
requires-technical-designResident visibility decisions required
Resident visibility
Question: Can a resident see draft history, review status, or only public display text?
Why it matters: Visibility can affect privacy, repair, and community safety.
Required decision: Decide whether residents can see status, guidance, display text, or history.
Risk if unresolved: The app could expose review notes or sensitive draft history.
Related: /protected-preview/live-workflow-readiness/
No resident history view exists.
requires-privacy-approvalExport/deletion decisions required
Deletion policy
Question: What should be deleted, summarized, or archived after each workflow state?
Why it matters: Deletion policy defines what the app must not keep.
Required decision: Approve deletion rules for unsubmitted, blocked, revised, approved, archived, and expired records.
Risk if unresolved: Blocked or sensitive drafts could remain beyond their useful purpose.
Related: docs/architecture/live-data-schema-design.md
No delete workflow exists.
requires-privacy-approvalExport policy
Question: Can any workflow data be exported, and if so, in what minimized form?
Why it matters: Exports can move sensitive content outside the protected system.
Required decision: Approve whether exports are blocked, audit-only, or display-text-only.
Risk if unresolved: Sensitive community content could leave the app without clear control.
Related: docs/architecture/live-data-schema-design.md
No export workflow exists.
requires-privacy-approvalAI-use decision required
AI use policy
Question: Should AI ever process real peer/community submissions?
Why it matters: Real pull-ups and push-ups may contain sensitive community information.
Required decision: Keep AI blocked for real submissions unless a separate staff/privacy policy approves it.
Risk if unresolved: Sensitive community content could be sent to third-party AI by mistake.
Related: docs/architecture/ai-use-policy.md
No OpenAI submission processing exists.
blockedExplicit No-Tracking Boundary
Go / No-Go Checklist
- Staff approval workflow documented
- Role mapping approved
- Privacy boundaries approved
- Content exclusions approved
- Retention and deletion windows approved
- Audit logging design approved
- Resident visibility rules approved
- Export policy approved
- AI use remains blocked unless separately approved
- No-tracking boundary accepted
- Pilot scope and rollback plan approved
Recommended Next Phase
Phase 5.8 — Staff Demo Walkthrough Package
Present the current product, protected preview stack, safety boundaries, and staff/privacy review order without enabling accounts, writes, migrations, forms, submissions, or staff actions.
planning-only