The honest, technical
version.

A browser session opens a direct WebSocket from the user device to the Gemini 3 Flash Live preview endpoint. The Pulse backend mints a one-use ephemeral token via @google/genai authTokens.create with liveConnectConstraints locked to AUDIO modality + system instruction; GOOGLE_API_KEY never leaves Cloud Run.

16 kHz mono PCM mic via AudioWorklet (resampled from the device-native 48 kHz), 1 Hz JPEG frames from the same MediaStream. Gemini emits 24 kHz PCM back which we play through a queued AudioContext for gapless playback. rPPG runs in parallel on the same video stream so the heart-rate estimate lands at the same moment the model finishes speaking.

Every reading produces two signatures alongside the saved record. (1) An Ed25519 detached signature over a canonical JSON-sorted-keys serialisation of the record fields, with the public key included so the receipt is self-verifying. (2) A SMART Health Card JWS: the FHIR R4 Observation Bundle is DEFLATE-raw compressed, signed ES256 by the issuer key in Google Secret Manager, encoded as a shc:/ numeric QR (each character mapped to two digits, char - 45).

Validated end-to-end against the official smart-on-fhir/health-cards-dev-tools v1.3.0-2 validator on 2026-05-20 with zero warnings: shc:/ decoded, JWS payload inflated, issuer key retrieved from /.well-known/jwks.json, JWS signature verified, FHIR bundle validated.

On first sign-in the browser generates a non-exportable ES256 keypair via WebCrypto with extractable=false; the CryptoKey reference is stored in IndexedDB. The corresponding public JWK auto-registers via /api/shc/register-delegated-key (Firebase ID-token authenticated) and the JWKS endpoint publishes it alongside the master issuer key.

When navigator.onLine is false, the check-in flow signs the SHC locally with the delegated key and queues the record to an IndexedDB outbox. Reconnection drains the outbox to /api/check-in/save, which keeps the offline-signed JWS verbatim rather than re-signing. The same public JWKS validates online and offline readings.

Verification runs three ways. (1) /verify in any browser: pure client-side, jose + pako, JWKS cached by the service worker so the page works offline. (2) /api/shc/verify: server-side for kiosk verifiers that prefer a JSON call. (3) Any third-party SMART Health Card reader (the COVID-card verifiers deployed in 70+ jurisdictions): zero integration cost, they fetch the JWKS at /.well-known/jwks.json from the iss URL in the JWS, validate, and read the FHIR Bundle.

The clinic adds zero infrastructure to read a Pulse. The signing kid in the JWS matches a key in JWKS regardless of whether the issuer was the server master key or a per-device delegated key.

The /signature page calls /api/signature/weekly which prompts Gemini 3 Pro with the Google Search grounding tool enabled. The prompt limits citations to authoritative public health sources (HSE, ECDC, WHO, NICE, NHS, Cochrane, BMJ, AAP, peer-reviewed journals) and requires the model to NOT invent URLs. The response is JSON with narrative + highlights, and the grounding metadata returns a list of cited web URIs.

Per-user per-day cached in Firestore signature_weekly/{uid}_{date}; one-hour soft TTL on top so we don't burn Search-grounded calls. The UI surfaces each grounding URI as a pill chip the user can click to read the source.

A weekly cron route (/api/email/audio-digest/run, OIDC + audience-pinned auth) pulls each opted-in user's last 7 days of Pulses, generates the grounded Signature, composes a narration script that opens warm and closes with a safety reminder, then synthesises an MP3 via Cloud TTS Studio (en-GB-Studio-B at 0.95 speaking rate, slight pitch lowering for a calmer register).

The MP3 lands in Firebase Storage at audio-digests/{uid}/{date}.mp3, gets a 7-day signed URL, and the user receives an email with a Play button via AWS SES. Opt-out is one click via the standard RFC 8058 unsubscribe path; the audio digest is independent of the reminder-email preference.

The chest-worn sensor (ESP32 + MAX30102 pulse-ox + LIS3DH accelerometer + SPS30 on-body PM₂.₅, BOM ≤ €30) signs every reading on-device with an ATECC608B secure element. The Ed25519 keypair is generated on first power-on; the private key never leaves the chip. The public key registers in the same JWKS as the phone-app surface.

Output to the caregiver is a FHIR R4 Observation Bundle in the same SMART Health Card envelope as the phone-app surface. A clinic verifier reads chest-sensor and phone readings with one fetch of /.well-known/jwks.json. EU MDR Class IIa pathway; clinical evaluation begins with the Q3 2026 pilot at Uttaradit Hospital paediatric clinic.

Cloud Run, Firestore, Firebase Auth, Secret Manager, Vertex AI / Gemini: all europe-west1 (Belgium). AWS SES transactional email: eu-central-1 (Frankfurt) under AWS EMEA SARL. No data residency outside the EEA at the Effective Date.

Raw selfie video and raw audio never reach the Pulse backend. rPPG computes heart rate from frames in the browser; only the integer bpm + signal quality leave the device. Voice for the Live API goes browser → Google over a token-scoped WebSocket; we never see the audio.

Cron endpoints (/api/email/reminders/run, /api/email/audio-digest/run) accept either an INTERNAL_CRON_TOKEN header (manual runs) or a Cloud Scheduler OIDC bearer token. The OIDC verifier requires email match against CRON_SERVICE_ACCOUNT_EMAIL AND audience match against CRON_EXPECTED_AUDIENCE.

Audience-pinning closes the second-service-compromise vector: a Google-signed OIDC token minted by the same service account for any other Cloud Run target won't pass here. Without that pin, any such token could fire the cron endpoint and email every Pulse user on the SES bill.

/api/check-in/save runs every incoming body through an explicit allowlist of fields a client may contribute (kind, heart_rate_bpm, voice_transcript, etc.). Server-set fields (id, schema, issued_at, owner_uid, anonymous) override the spread, so a client cannot inject a faked owner_uid or replace the signature/public_key inside the envelope.

The canonical JSON serialisation (sorted keys) used for Ed25519 signing lives in lib/sign.ts and is reused by /verify, so any future verifier port matches the issuer canonicalisation exactly. SHA-256 hash output stays at 64-char hex (no truncation) to match the published verifier contract.