Data Flow Diagram

Reviewed: 2026-07-22 · Canon: generation 8, effective 2026-07-21 · Scope: the designed data flows on the Google Cloud spine. The deployed environment carries synthetic data only; every PHI annotation below describes what the path would carry after the real-data gates pass, not what flows today.

Boundary legend: [PHI] PHI path once activated · [ADJ] PHI-adjacent, minimized · [ZERO] zero-PHI by design

1. Platform flow (worker evidence to facility decision)

  WORKER (browser)                          FACILITY USER (browser)
       |                                          |
       |  TLS                                     |  TLS + SSO
       v                                          v
  +---------------------------------------------------------------+
  |            Cloud Run services (platform API + apps)           |
  |   worker · readiness · operator · admin · hire · demo         |
  +-------------------------------+-------------------------------+
                                  |
          +-----------------------+-----------------------+
          |                       |                       |
          v                       v                       v
  +---------------+      +----------------+      +------------------+
  |  Cloud SQL    |      |  Cloud Storage |      |  Provider edge   |
  |  PostgreSQL   |      |  documents +   |      |  (AI models,     |
  |  (private)    |      |  receipts      |      |   source checks) |
  |  [PHI]        |      |  [PHI]         |      |  [ADJ] gated     |
  +---------------+      +----------------+      +------------------+
                                  |
                                  v
                       +---------------------+
                       |  Audit ledger       |
                       |  append-only,       |
                       |  hash-chained       |
                       |  [ZERO] ids+hashes  |
                       +---------------------+

Design rules on this flow:

• Worker uploads land in storage under encryption; extraction produces evidence records labeled by class (06.5), never silently source-verified.
• Source checks preserve a receipt: source, timestamp, response, hash. Receipts anchor to the audit ledger.
• Facility users see only their organization's scope; tenant isolation is enforced below the UI.
• Every regulated decision writes a Decision Record bound to a named human with the exact evidence and policy versions.
• The audit ledger payload carries identifiers and hashes, not PHI bodies.

2. AI provider flow

  Cloud Run service
       |
       |  typed tool call, budgeted, logged
       v
  AI gateway  -->  provider (model-agnostic routing)
       |             - minimized payload [ADJ]
       |             - PHI classification checked
       v
  trace record + receipt written to the ledger

• No provider call executes inside a held database transaction.
• Provider prompts, responses, and tool calls are logged with hashes for replay.
• Regulated data reaches a provider only after the contractual, configuration, minimization, and logging gates are satisfied (06.5).

3. Investor room flow (live today, zero-PHI)

  INVESTOR (browser)
       |
       |  TLS (investors.rovn.to)
       v
  Cloud Run (investor room)  -->  Vertex AI (Gemini 2.5 Flash)
       |                          canon-pinned, generation 8
       v
  same-origin answer; no question text written to application logs

This surface is zero-PHI by design: diligence documents are not PHI, and no PHI belongs in this room or its prompts.

4. Boundary summary

5. Data egress rules (design invariants)

• PHI stays inside the governed cloud project and its BAA-covered services once real data activates; egress requires an executed agreement at the destination.
• No SaaS analytics on PHI surfaces; third-party tags do not belong on PHI pages.
• Data export is admin-gated, audit-logged, and tenant-scoped. No cross-tenant export path exists by design.
• Error tracking receives scrubbed frames only; scrubbing verification is a real-data gate.

6. What this diagram does not claim

• It does not claim any real PHI currently flows. It does not.
• It does not claim cross-region active-active disaster recovery; recovery posture must pass its own tested gate before production real-data use.
• It does not claim third-party EHR integrations are live; integration claims require the deployed connector and current evidence.
• It does not claim any verification source is live; adapter states vary, and source claims require contract, credentials, and transport proof (06.8, 06.11).

End of diagram.