PVA Trust Boundary Charter
internal prototype · canonical JSON + Dreamborn Forge HTML
internal generated
trust-boundary-charter · supabase_json

PVA Trust Boundary Charter

trust-boundary-charter artifact · for Patient Visit Advocate · phase PVA-SLICE-00 · status approved

Planning Surface

Use this to decide what happens next.

Status

approved

Phase

PVA-SLICE-00

Agent Handoff
Start Here

trust-boundary-charter artifact · for Patient Visit Advocate · phase PVA-SLICE-00 · status approved

Completion Evidence

No explicit evidence field yet. Require tests, screenshots, linked PRs, or reviewed outputs before marking complete.

Artifact Shape
  • gates: 5 items
  • phase: id: string, name: string, status: string
  • title: PVA Trust Boundary Charter
  • source: Atlas-Codex revised PVA decomp with ask_model critique from Claude and OpenAI; Gemini unavailable/high demand on retry.
  • product: Patient Visit Advocate
  • purpose: Define the hard trust, safety, privacy, and monetization boundaries before any patient-facing or server-side health-data work begins.
  • created at: 2026-05-08T14:02:37.874Z
  • created by: atlas-codex
  • hard rules: 8 items
  • principles: 5 items
  • project id: 31d7f681-bed2-44e9-9a55-b9fadcbba0da
  • ask model notes: 2 items
Structured Payload

Machine-readable source fields

gates
  • Approved escalation language exists before any patient-facing intake test.
  • Local draft retention/deletion rule exists before patient testing.
  • No cloud model call with health text before consent and data contract are approved.
  • No payment/paywall implementation before the free loop and trust copy are validated.
  • No public beta before deletion/export/privacy controls and AI output safety audit pass.
phase
id

PVA-SLICE-00

name

Trust Boundary Charter

status

draft

title

PVA Trust Boundary Charter

source

Atlas-Codex revised PVA decomp with ask_model critique from Claude and OpenAI; Gemini unavailable/high demand on retry.

product

Patient Visit Advocate

purpose

Define the hard trust, safety, privacy, and monetization boundaries before any patient-facing or server-side health-data work begins.

created at

2026-05-08T14:02:37.874Z

created by

atlas-codex

hard rules
idruleapplies to
TB-001No diagnosis or treatment recommendation- intake - brief - question plan - debrief - memory
TB-002Escalate serious symptom disclosures conservatively with approved plain-language emergency guidance.- intake - quick capture - post-visit debrief
TB-003Free/local draft work must not send health text to servers or analytics without explicit user consent.- local-only prototype - free app
TB-004Analytics may track counters and funnel states only; never health text, question text, clinician/location names, brief content, debrief content, or memory content.- all releases
TB-005Generated memory cannot be reused until the user explicitly confirms or edits it.- paid memory - family/caregiver
TB-006Export/share requires explicit user action and a disclosure that exported content may contain sensitive health information.- visit brief - question plan - debrief
TB-007Local anonymous drafts must have a visible retention/deletion rule before patient testing.- local-only prototype - free app
TB-008Any server-side PHI requires approved consent, retention, deletion/export path, encryption posture, and model/data contract.- MVP - beta - production
principles
  • The product is a patient advocacy pocket app, not an EHR, clinical decision support system, diagnosis tool, triage tool, or treatment planner.
  • The free product must create real value for a single visit without forcing an account or paid plan.
  • Paid value attaches to continuity: saved history, user-confirmed memory, unresolved questions, follow-up tracking, and caregiver/family coordination.
  • No ads, health-data resale, lead-gen bias, affiliate steering, or monetization that exploits vulnerable health context.
  • Every medical-adjacent output must preserve uncertainty and frame questions for discussion with a qualified clinician.
project id

31d7f681-bed2-44e9-9a55-b9fadcbba0da

ask model notes
  • Claude: split hard trust rules from broader retention/analytics rules; keep first charter actionable rather than legalistic.
  • OpenAI: avoid process-heavy gating that delays real user signal; embed trust rules into definition of done.
monetization boundary
free

Single-visit prep loop that is genuinely useful: messy intake, editable review, visit brief, prioritized question plan, in-visit/quick note support, post-visit quick capture, local export/share, and clear local deletion/retention.

caution

Do not punish the free user immediately after trust is earned. Debrief capture should be free; saved/searchable longitudinal debrief memory is paid.

paid individual

Saved visit history, longitudinal memory, unresolved questions across visits, follow-up continuity, searchable/exportable history, and user-confirmed reusable context.

paid family caregiver

Multiple profiles, caregiver access, delegated prep, shared follow-up tracking, revocable permissions, and family memory continuity.