Draft Pilot Protected Read Runtime Plan
Purpose
This page defines how future protected read-only runtime surfaces could safely read draft pilot data only after schemas, migrations, access policy, actor mapping, role mapping, retention, deletion, audit, staff/privacy, and pilot gates are approved.
It is planning-only. It creates no protected live routes, no protected API routes, no read handlers, no database reads, no database writes, no draft storage, no accounts, no submissions, and no live workflows.
Current Runtime Boundary
Plan status
planning-only
Runtime status
not-implemented
Go / no-go
no-go
Database reads
not-implemented
Protected live routes
not-created
Protected API routes
not-created
Why Read Runtime Planning Comes Before Read Runtime
Read runtime design has to come after local migration validation and before any handler or route exists, because even read-only data can expose identity, draft content, review context, or visibility decisions if policy and response boundaries are not approved first.
Future reads remain blocked until the approved schema, response policy, role visibility policy, retention/deletion policy, and audit policy are all in place.
Future Read Surfaces
| Surface | Purpose | Role | Status | Reason blocked |
|---|---|---|---|---|
/protected/drafts | future list of user-visible drafts under approved role/actor policy | approved resident/submitter actor | not-implemented | protected live routes, D1 schema activation, actor policy, role mapping policy, and read visibility policy do not exist |
/protected/drafts/:id | future single draft detail page under strict visibility policy | approved draft-visible actor | not-implemented | draft storage, read visibility policy, retention policy, and audit policy are not active |
/protected/staff/review-queue | future staff read-only review queue before write decisions | approved staff reviewer | not-implemented | staff review policy, reviewer permissions, protected routes, and read APIs are not implemented |
/protected/morning-sheet/candidates | future staff-only Morning Sheet candidate review surface | approved staff reviewer or program admin | not-implemented | Morning Sheet visibility policy is planning-only and live placement remains blocked |
/protected/admin/pilot-status | future read-only pilot health surface | approved program admin | not-implemented | admin policy, protected read route policy, and approved pilot group do not exist |
Future Read API Boundaries
These API boundaries are future-only metadata. No API files are created, no handlers are created, no runtime API behavior is added, and no D1 reads occur in this phase.
| Future API | Method | Purpose | Role | Status |
|---|---|---|---|---|
GET /api/protected/drafts | GET | future draft list response boundary | approved resident/submitter actor | not-implemented |
GET /api/protected/drafts/:id | GET | future single draft response boundary | approved draft-visible actor | not-implemented |
GET /api/protected/staff/review-queue | GET | future staff queue response boundary | approved staff reviewer | not-implemented |
GET /api/protected/morning-sheet/candidates | GET | future Morning Sheet candidate response boundary | approved staff reviewer or program admin | not-implemented |
GET /api/protected/admin/pilot-status | GET | future pilot status response boundary | approved program admin | not-implemented |
Data Visibility Model
Allowed future read categories
- pseudonymous actor refs
- draft metadata
- draft content under approved visibility policy
- review lane/status metadata
- Morning Sheet eligibility metadata
- retention/deletion status metadata
- minimal audit metadata
Prohibited read categories
- real names
- emails
- Cloudflare Access claims
- JWTs
- tokens
- raw identity headers
- resident profiles
- staff profiles
- attendance data
- participation data
- participation analytics
- scoring/ranking/compliance metrics
- clinical/medical/legal/insurance/trauma details
- AI-generated decisions
- hidden staff notes not approved for visibility
Role Visibility Model
| Future role | Visibility boundary | Status | Active |
|---|---|---|---|
| resident/submitter | may view their own draft under approved actor policy | not-implemented | false |
| subject actor | subject visibility is blocked until staff/privacy policy approves it | not-implemented | false |
| peer-leader | peer-leader visibility is blocked by default | not-implemented | false |
| staff-reviewer | may view queue metadata only under approved staff review policy | not-implemented | false |
| program-admin | may view pilot status metadata only under approved admin policy | not-implemented | false |
Required Gates Before Read Runtime
- Cloudflare Access boundary approved
- identity policy approved
- pseudonymous actor policy approved
- account role mapping policy approved
- read visibility policy approved
- draft content policy approved
- staff review procedure approved
- Morning Sheet visibility policy approved
- retention policy approved
- deletion policy approved
- audit policy approved
- D1 schema activated under approved migration
- protected read route policy approved
- protected API response policy approved
- staff/privacy approval complete
- small pilot group approved
Blocked Capabilities
Recommended Next Phase
Phase 9.5 - Draft Pilot Write Endpoint Design
After read runtime planning, the next safe planning step is write endpoint design that still creates no endpoints, handlers, writes, accounts, draft storage, staff decisions, live routes, migrations, tracking, analytics, or scoring.
Boundaries: no protected live routes; no protected API routes; no database reads; no database writes; no write endpoints; no active migrations; no draft storage; no account storage; no actor storage; no identity capture; no staff decisions; no Morning Sheet placement; no tracking; no analytics; no scoring.
recommended-next