The server does the work. The laptop keeps the secrets.

Every step, and every byte on the wire.

The trace below follows one question at a library of 20,000 passages. Steps marked Laptop never touch the network. The sizes are what the app's ledger shows.

The threat model, in one table.

Each party sees only what it needs to do its job. The laptop is the only place the question, its embedding, the scores and the answer exist in readable form.

Scoring a question nobody can read.

CKKS is homomorphic encryption for approximate real numbers: the server can multiply and add encrypted vectors without ever decrypting them. That is exactly what a similarity search needs.

# on the laptop (holds the secret key s)
q   = embed(question + chart context)          # 384 numbers, unit length
ct  = Enc(q)                                     # CKKS, N = 8192, 4,096 slots

# on the server (holds only public and evaluation keys)
for each block E_b of 3,712 passage embeddings:
    ct_b = ct · E_bᵀ                            # one plaintext multiply per block

# back on the laptop
scores = Dec(ct_b)  →  top 8, at most 2 per page    # never sent back

Getting 8 passages without saying which.

Once the laptop knows which 8 passages it wants, it still has to get them. SimplePIR lets it fetch each one with a query that looks like random numbers, so the server must multiply it against the whole library and can't tell what was asked for.

The server multiplies every query against every passage. Which 8 the laptop wanted never shows.

# laptop wants passage j; keeps a fresh secret s and noise e
qu  = A·s + e + Δ·u_j                 # u_j: 1 at position j, 0 elsewhere; Δ = 2³²/256
                                       # A·s + e is an LWE sample: random-looking without s
# server: library D (1,024 bytes × n passages), public hint H = D·A
ans = D·qu                            # one multiply over every passage

# laptop
ans − H·s = Δ·D[:, j] + D·e           # noise |D·e| < Δ/2
round(· / Δ)  →  passage j, byte-exact

Why the server learns nothing: A·s + e is a Learning With Errors sample, computationally indistinguishable from uniform numbers mod 2³². Adding Δ at one position of a uniformly random vector gives another uniformly random vector, so for every choice of passage the query looks the same. That is the SimplePIR security theorem, and its reduction goes to LWE, the same family of assumptions behind NIST's post-quantum standard ML-KEM.

Hiding who asked. Blocking everything else.

The relay sits between the laptop and the server, so the server never sees the laptop's IP. It forwards only the protocol paths and only the body, content type, session id and library version. It keeps no access log. Everything else returns 404, so the server's internal endpoints stay private.

The egress guard is an allowlist inside the client: the relay, the local model, and an EHR on the same machine unless another host is listed. It checks the host before the HTTP client is called, so a blocked request never resolves a name or opens a socket. Every request, allowed or blocked, lands in the ledger the clinician can open.

A receipt the clinician can check.

After each answer, the app replays the server's side using only the bytes the laptop sent to the relay for that answer. Those bytes are kept in memory, never on disk. Then it tries to read them.

1. No secret key left the laptop. The key upload holds public and evaluation keys only.
2. The server can't decrypt the question. Decrypting the query with the uploaded keys fails.
3. No words left in readable form. Every field is base64-decoded and searched for phrases and words from the question and the chart. In the demo: 46 searched, 0 found.
4. The server can't tell which passages were read. The 8 fetch queries touch every passage, and a best-guess attacker does no better than chance.

The same checks run as a script, scripts/verify_server_view.py, against a recorder placed in front of the real server. These checks catch mistakes; the guarantee itself is the math.

Public sources, rebuilt every day.

The library is public-domain US government text, because it is handed to users passage by passage: FDA drug labels from openFDA and DailyMed, NLM's MedlinePlus, and .gov health pages that Tavily and Exa crawl. No clinician's question ever reaches them.

• Build. Clean, de-duplicate and pack into fixed 1,024-byte records with the URL and title inside. Embed each record, and compute the PIR hint once per library.
• Refresh. A scheduled job runs every 6 hours and rebuilds when the library is over a day old. Label changes, such as an NSAID warning at 20 weeks or a new contraceptive interaction, reach answers without retraining anything.
• Verify, then publish. Before publishing, the job checks the files, shapes and manifest, does a PIR round trip, and compares the encrypted and plaintext top result. A failed build is never published.
• Hot-swap. The server polls for new versions and swaps them in without a restart. A client on the old version gets a clear "library changed" reply, re-syncs and retries once.

Clinical features that never phone home.

Measured on one laptop.

Plus a one-time 35 MB key upload per session and a 4 MB public hint download. The encrypted top 8 matched the plaintext top 8 exactly, and every fetched record was byte-exact. Building the PIR hint takes about a second at 20,000 passages.

What it doesn't do yet.