# No-PHI Pilot Architecture — One-Pager

> **Purpose.** A one-page, reviewer-oriented description of the Gatekeeper pilot tier:
> what the pilot demonstrates, what data is allowed inside it, and what it does and does
> not prove. It is consistent with, and defers to, the
> [Architecture Brief](/trust/architecture-brief.md), which traces every technical claim
> to current code. This document claims no formal compliance status and invents no control.
> Statuses use the same labels: **REAL / CURRENT** (implemented) or **ROADMAP /
> PROPOSED** (designed, not shipped).

---

## 1. Pilot Purpose

The pilot demonstrates governed AI calls with per-call evidence, using **no-PHI data
only**. A pilot participant routes AI requests through the Gatekeeper gateway and
receives, for every call: PII/PHI-pattern redaction before the provider forward,
jailbreak/prompt-injection screening, policy enforcement (SOC-2 / HIPAA policy packs),
and one audit row mapped to specific controls — exportable as an evidence packet.

The pilot exists to show **how the evidence layer behaves**, not to process real
patient data.

The pilot tier has two distinct components, and they are not the same workflow:
the **gap-check engagement** (§2) — a documentation-and-evidence review with zero
PHI custody — and the optional **product demonstration** on synthetic data
(§3–§6). Neither is a production PHI processing workflow.

## 2. The Gap-Check Engagement Model — Zero PHI Custody

A pilot engagement is delivered as a **gap check**: a documentation and evidence
review, not a production deployment and not a PHI processing workflow. The
engagement maps a participant's AI change-related contract clauses against
observed change events and available evidence, and produces a findings report.

**Zero PHI custody.** The engagement operates with **zero PHI custody**: customer
PHI is not requested, not transferred, not stored, not processed, and not
retained as any part of the engagement.

**Allowed inputs — only these:**

- Redacted contractual clauses (identifying and sensitive details removed by the
  participant before sharing)
- Public documentation
- Public changelogs
- Publicly available evidence

**TPRM positioning.** The engagement is designed for organizations that want to
complete an initial trust / TPRM **questionnaire-only** review without
transferring PHI — the reviewable materials on this Trust Center plus the
gap-check report are the deliverables; no data connection to the participant's
systems is required or requested.

**Relationship to the product.** The gap-check engagement and the Gatekeeper
gateway are distinct. The engagement reviews documents and public evidence; the
gateway (described from §3 onward) processes live requests. A participant who
additionally wants to see the gateway itself in action does so under the
separate demonstration boundary below — synthetic / non-PHI data only.

## 3. Data Boundary — Why the Pilot Is No-PHI

**Allowed in the pilot:**

- Synthetic data (the same class of data used for the public demo and sample evidence
  packet — "synthetic only, by policy" is the existing, stated demo policy)
- Test / non-production data
- De-identified data containing no real identifiers

**Not allowed in the pilot:**

- PHI or any real patient data
- Real production data containing personal identifiers
- Real credentials, API keys, or secrets embedded in prompt text

**The honest reasons this boundary exists** (all REAL / CURRENT, verified in the
Architecture Brief):

1. **Raw request text is stored indefinitely.** Every request's pre-redaction
   `original_text` is persisted to the audit database with **no retention mechanism,
   TTL, or purge job**, and no flag to disable storage. Retention controls are ROADMAP.
2. **One raw-text egress path exists today.** The internal jailbreak judge and block
   explainer receive raw, pre-redaction text snippets (sent to OpenAI). Judge-input
   redaction is ROADMAP, not shipped.
3. **Detection fails open.** If the judge is unavailable, requests proceed rather than
   block. A fail-closed mode is ROADMAP.
4. **No BAA is available.** There is no Business Associate Agreement, DPA, or formal
   subprocessor register; the BAA stance is an open founder/legal decision.

Because of these documented facts, the pilot **must not** receive PHI. No claim is made
that the system can safely process PHI, and no HIPAA compliance or formal compliance
status is claimed.

## 4. System Flow (actual pipeline)

```text
Pilot participant application
        │  (chat messages + governance headers: X-Gatekeeper-Key,
        │   X-Workflow-Tag, X-Actor-ID + participant's provider key)
        ▼
Gatekeeper proxy  (/proxy/openai · /proxy/anthropic)
        ▼
Jailbreak / prompt-injection detection   ← judge sees RAW text (known gap)
        ▼
PII/PHI detection and redaction  →  [REDACTED_TYPE] placeholders
        ▼
Policy enforcement  (soc2 / hipaa policy packs)
        ▼
Upstream model provider  (OpenAI / Anthropic — redacted text only,
                          participant key passed through in memory)
        ▼
Audit row per call  →  PostgreSQL audit_logs  →  evidence packet export
```

This is the real, current pipeline order (jailbreak check runs **before** redaction).
No components beyond these exist in the pilot path.

## 5. Trust Boundaries

- **Inside the pilot boundary:** the Gatekeeper proxy and detection pipeline, the
  policy/governance layer, and the audit database (hosted model: Gatekeeper-managed
  PostgreSQL on Neon, compute on Railway).
- **Outside the pilot boundary:** the participant's own application and users; upstream
  model providers (OpenAI / Anthropic), which receive redacted text on the proxy
  forward — plus raw snippets on the judge/explainer path (see §3); Slack (metadata-only
  block alerts, never prompt content).
- **Where data enters:** the proxy endpoints, authenticated per-app via
  `X-Gatekeeper-Key`.
- **Where data is processed:** in the fixed-order pipeline above, transiently in memory
  on gateway compute.
- **Where evidence is generated:** one `audit_logs` row per call; evidence exports emit
  entity-type **counts**, never raw text.

## 6. Data Handling in the Pilot

- **Do not submit:** PHI, real patient or production data, real secrets (see §3).
- **What is stored:** per-call audit rows including raw `original_text` and redacted
  `cleaned_text`, retained **indefinitely** today (no retention window exists — this is
  exactly why pilot data must be synthetic or non-sensitive).
- **Synthetic vs production:** all pilot, demo, and benchmark traffic uses synthetic or
  non-production data by policy; the public sample evidence packet is generated from
  clearly-labeled synthetic data.
- No deletion guarantee or retention period is claimed, because none is implemented.

## 7. What the Pilot Does NOT Establish

The pilot is:

- **Not a formal compliance attestation** (no HIPAA, SOC 2, or other formal compliance
  status is claimed; SOC 2 Type I & II engagement in process, not complete)
- **Not a compliance determination** for Gatekeeper or any participant
- **Not a production security assessment** — see the
  [Pen-Test Scope](/trust/pen-test-scope.md), which is proposed, not performed
- **Not an independent audit** — see the auditor engagement slot on the
  [Trust Center](/trust), which is pending publication
- **Not evidence of regulatory approval**
- **Not evidence that the system can safely process PHI**

The pilot demonstrates the evidence-generation behavior of the gateway on non-PHI data.
Nothing more is claimed.