# RonanRx As-Built Reference

**Audit date:** 2026-07-21, with targeted onboarding and secure-completion revalidation on 2026-07-30

**Current core refs:** full-suite baseline staging `c00248749c0287f6c87f5a553394b339fb2dedd5` and production main `d26d5e1c238bcedffef44fb4acadc1a6a3eb7788`; targeted 2026-07-30 onboarding check production `2a346e1104d96f08193e921f08626aa29d1cd939` and staging `608c9d996eccf921f8d8c62031de84087a760d7d`

**Historical census ref:** `f246ed27` from 2026-07-17

This document is informative, not binding. The running code wins when this document conflicts with implementation. Each card carries an explicit verification label. **Unverified, carried forward** means the statement came from the earlier audit and was not reconfirmed against the current refs. Historical f246 features called out as absent are not current staging claims. Product intent and build rules live in [business.md](./business.md); decision dispositions live in the repository-only decision register.

## Verification labels

- **Verified:** checked against the named current refs on the audit date.
- **Mixed:** a named branch-placement fact was verified, while remaining detail is carried forward.
- **Historical f246:** observed in the frozen 2026-07-17 snapshot and explicitly absent from both current refs.
- **Unverified, carried forward:** retained for implementation context and awaiting the D10 card-by-card census.

## 1.1 iPhone Link {#iphone-link}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Fully live. Inbound texts hit a signature-verified webhook, pass ordered safety, opt-out, replay, takeover, and special-route guards, then enter the focused Flue onboarding turn. When the current completion predicate passes, Rails mints a short secure link (a 22-character code, roughly 131 bits of randomness, with an OG preview card). The current secure flow is serial: verify ID, sign agreements, pay, then choose a video appointment or async review. Magic links expire after 24 hours. The old browser signup wizard is retired; texting is the surviving entry path. Duplicate inbound messages are deduplicated, and ops can manually resend a completion link from the console.

## 1.2 Onboarding Agent {#onboarding-agent}

**Verification:** Verified 2026-07-30 against deployed production core `2a346e1`, staging core `608c9d9`, and the active `prod-goalthread6` / `goalthread6` agent images.

Production and staging both delegate onboarding turns from the Rails Linq front door to the Flue-based `rrx_agents` service through `RrxAgents::TurnClient`, using a stable conversation key. Flue persists one JSONB progress document per conversation in `agent.onboarding_records.data`; it is not a loose JSON file. Rails reads that record, projects completed onboarding data into `IntakeResponse`, creates the `/p` completion link, applies policy and delivery controls, and sends patient-facing replies.

Current completion requires a patient goal, current medications, allergies, medical conditions, and either captured height/weight or a truthy `biometricsAddressed`. Desired medication, state, and the chat ID image do not gate completion. ID is offered once in chat and may be declined; the agent acknowledges without pressure, does not repeat the ask, and moves to the biometric beat. There is no frozen exact acknowledgment sentence.

Two current gaps are now explicit. First, Flue captures `fields.state`, but the Rails `OnboardingRecord#basics` projection omits it and the agent job passes `patient.state`, so state can be lost for a patient created only at handoff. Second, timeout and hard-failure paths log and alert but do not send the deterministic patient-facing fallback previously claimed here.

## 1.3 Signup Intake {#signup-intake}

**Verification:** Targeted onboarding behavior verified 2026-07-30; the broader public-intake and historical mobile evidence remains carried forward.

The deployed Flue path stores patient goals, desired medications, state, current medications, allergies, medical conditions, height/weight, identity candidates, attachments, interactions, and update history in one versioned JSONB record. A named medication can be stored as the goal when no goal has been captured yet, but current medications, allergies, conditions, and the biometric beat still block handoff.

The approved lighter target is `service_state AND (patient_goal OR desired_medication)`, with everything else best-effort in SMS and missing answers completed later. That target is not built. There is no explicit `missing_for_later` manifest and `/p` does not currently insert a missing-basics form. `HealthHistory::IntakePrefill` and the governed Intake 2 question engine provide part of the later continuation mechanism, but the handoff contract between them is still missing.

## 1.4 Sign Docs / Agreement Packet {#sign-docs}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Live. The packet (version 1) is seven documents signed in one flow: (1) Platform & Marketplace Agreement, (2) Provider Election & Care-Relationship Addendum, (3) Telehealth Consent & Consent to Treat, (4) Payment & Billing/Subscription Terms, (5) Privacy, HIPAA & Records-Sharing Authorization, (6) Pharmacy & Compounding/Medication Disclosure, and (7) Mobile Messaging & AI Consent, Authorization & Communications Preferences. The signed packet renders to PDF, persists as a sealed consent with the document stored in Google Cloud Storage, and a reconcile job self-heals any missed seals every 15 minutes. A separate authorization flow on a dedicated auth domain (auth.ronanrx.com) handles text-PHI authorizations, and providers sign their own agreement packet twin (six documents, not seven: §11.1).

## 1.5 Membership Subscription {#membership-subscription}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Live in production since 2026-06-29. Embedded card entry (with Apple Pay / Google Pay) saves the card, then a Stripe subscription is created with the first-month-free coupon. Payment is the third serial secure-completion gate, after ID verification and the agreement packet. Scheduling or async review stays locked until all three are complete. A webhook backstop reconciles anything the browser flow misses. Patient-facing copy: "Your first month is free, then $39/month, cancel anytime. A doctor still reviews everything before any prescription is issued."

## 1.6 Reengage / Close Agent {#reengage-close-agent}

**Verification:** Mixed. Historical f246 implementation evidence is carried forward, and the named mobile, HealthKit, Whoop, regimen, or support-reply artifacts are absent from both current core refs.

No end-to-end close agent was identified. The carried-forward audit found no scanner for stalled intakes, unopened completion links, unsigned packets, or unpaid memberships, and no model-generated reengagement copy. Deterministic health-history and weigh-in nudges, ops completion-link resend, pre-visit intake reminders, and post-prescription payment-link recovery were adjacent capabilities. The historical care-team reply nudge observed at f246 is absent from both current core refs. Delivery switches defaulted several nudges to dry-run.

## 1.7 ID Verification {#id-verification}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Live. The secure completion wizard starts with a dedicated ID step backed by a database upload state machine (pending → verified / failed / needs_review): the patient photographs the ID, Google Gemini OCR extracts name, date of birth, ID number, expiry, and document type, and a recovery sweep every 15 minutes plus a nightly purge job keep the pipeline healthy. The agreement packet, payment, and scheduling/async choice remain locked behind this first gate. Patients may also photograph their ID mid-chat, but that attempt is optional and refusal does not block the secure-link handoff. Visit-side, the EHR appointment chart record carries an "Identity verified" attestation with a verification method: it auto-prefills when a verified ID document exists, a clinician can explicitly uncheck it, and telehealth completeness is advisory at signing rather than a blocker.

## 2.1 Dr. Picker {#doctor-picker}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

A real doctor picker exists in the signup schedule step: it lists the clinic's active doctors, filters to doctors holding an active license in the patient's state (backed by an active credential), orders them by round-robin load (fewest upcoming visits first), and renders the full roster when there is more than one. But there is no specialty matching (no specialty field exists anywhere in the database), no cost dimension, availability is synthetic (hard-coded weekday windows, not doctor-provided), scope is a single clinic, and doctor choice is offered only on first onboarding: later flows pin the established doctor. Doctor self-signup exists behind an invite code, with credentials created inactive until a human activates them.

## 2.2 Appointment Setting {#appointment-setting}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

End-to-end booking is wired: slot generation, race-safe idempotent booking (database-level guarantees: one booked visit per enrollment, one booking per slot), confirmation SMS into the existing text thread, a tokenized visit page with calendar links (.ics + Google Calendar), a private doctor calendar subscription feed, an ops cancel/rebook panel, and the doctor's EHR day schedule with audited roster access. Current limitations: availability is a synthetic hard-coded weekday grid, the system does not ingest the doctor's real calendar, and code imposes a 3-day lead rather than the approved availability rules.

## 2.3 Pre-Doctor Intake {#pre-doctor-intake}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

A large, governed pre-visit intake engine is built: a deterministic question planner working from a governed, versioned question artifact; SMS question-and-answer over the existing text thread; a portal section flow (sections A/B/C); completed packets surfaced in the doctor's pre-call brief; and ops-triggered reminders. The activation switch (`GLP1_INTAKE_MODE`) defaults to `manual_fallback`, which asks no questions and writes no answers. Rehearsal, shadow, and live modes exist alongside a kill switch (`GLP1_INTAKE_KILL_SWITCH`). Reminder texts require their own send-mode switch (`LINQ_PRE_DOCTOR_INTAKE_REMINDER_MODE=send`) or they dry-run.

Current implementation rules:

- Reminders require signed text-messaging consent, a live text thread, a current appointment, and a matching phone binding.
- Live mode requires governed question content at schema version **2**; anything else falls back to inactive.
- Patients can type `manual review`, `staff help`, or `human help` to hand off to a human, and `correct <question>: <value>` to fix an answer.

## 2.4 Meeting Reminders {#meeting-reminders}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Patient reminders are wired and deterministic: a sweep every 15 minutes finds booked appointments inside the 24-hour and 1-hour windows, re-checks the appointment still stands, renders fixed templates carrying the tokenized visit link, dedupes against a message ledger, and sends through the guarded SMS pipeline. Booking confirmations use the same path with a calendar link. Delivery defaults to dry-run and requires `LINQ_TEXTFLOW_AUTOREPLY_MODE=send` to reach patients. There is no doctor SMS/email reminder workflow and no T-5-minute brief message.

Current implementation rules:

- Patient reminder windows are **T-24h** and **T-1h**; each dedupes independently per appointment time.
- The sweep runs every **15 minutes**.
- Cancelled or rescheduled visits skip without burning the dedupe slot, so a later valid window still fires.
- Reminder links must stay on the ronanrx.com host or the send guard blocks the message.

## 2.5 Pre-Brief {#pre-brief}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

The approved product surface is the **Pre-Brief**, but code has two unconnected partial implementations and neither is pushed. (1) `Ehr::Integration::PreCallBrief` builds a deterministic brief on the doctor's schedule page: goal, intake facts, medications/allergies from the chart, up to 6 must-ask questions, and the intake packet with flag count. (2) `Agents::PatientSummary` can draft a one-page Clinical Brief artifact for the doctor case page, but its producer has no production trigger. Nothing is **sent** to the doctor before the appointment: no doctor email, no doctor SMS, and nothing attached to reminders; the calendar feed currently carries only a PHI-free visit link.

## 2.6 Doctor Visit {#doctor-visit}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Per-visit Google Meet rooms are fully built (shipped 2026-07-08): booking provisions a room with automatic transcription on and automatic recording off; joining is gated through a single authorization path with a 10-minute window on each side of the visit, from both the patient's tokenized visit page and the doctor's schedule; sweeps (15-minute full pass + 2-minute fast pass) handle conference-record and transcript polling, no-shows, and room lockdown. After the visit, the transcript is ingested with speaker attribution, an appointment chart record (currently `Ehr::Encounter`) opens automatically, and real-LLM agents draft the clinical note (SOAP or HPI/MDM) plus advisory Rx and ICD suggestions for the doctor to review. No native recording reference is generated, ingested, or downloaded today. Runtime is env-gated (`MEET_PER_VISIT_ENABLED` plus two service-account vars); with flags off, everything falls back to one shared static Meet room.

## 2.7 Visit Observation {#visit-observation}

**Verification:** Not built

The current implementation has reusable appointment-bound Meet spaces, conference and transcript polling, speaker attribution, an `ehr_video_session`, PHI document storage, transcript-derived note drafting, doctor editing and signing, amendments, and chart-access audit controls. `MEET_AGENT_EMAIL` is a delegated API identity and does not join the meeting as a participant.

`GoogleWorkspace::MeetClient` hard-codes `autoRecordingGeneration: "OFF"`. There is no recording download, all-session recording readiness check, patient-speaking frame selector, `ffmpeg` extraction worker, image quality check, screenshot artifact, automatic EHR image attachment, image-assisted observation draft, screenshot gallery, delete-one or delete-all action, object purge, image-deletion tombstone, or deleted-image recreation guard. No part of Visit Observation is user-usable, so its delivery status remains not built.

## 3.1 Charting EHR {#charting-ehr}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

A complete in-house EHR zone is built and wired: chart UI (behind an environment feature switch so it can be dark-launched per environment), chart-access logging on every read/write with break-glass override and alerting, note addenda, amendment and void flows, legal holds, disclosure logs, and cryptographic (HMAC) appointment-note signing with versioned keys. Note drafting from appointment transcripts (see §2.6) feeds it. Visit Observation (§2.7) images and image-derived text do not feed it today. An architecture boundary keeps the EHR isolated from the rest of the app: one sanctioned crossing point, with the EHR→core direction enforced in CI and the reverse direction checked by an advisory script.

## 3.2 Prescription Generation {#prescription-generation}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

A complete pipeline: the doctor confirms the prescription (a fingerprint over its fields; any edit invalidates the confirmation), cryptographically signs the appointment chart record, then issues. Issuance re-verifies the signature, the patient's state serviceability, the doctor's active credential and state license, and the dose guardrail. The carried-forward audit found every reference row pending sign-off, so the guardrail matched nothing. Each prescription is issued idempotently with patient, prescriber, credential, and pharmacy snapshots; receives the legacy 19,500-cent fallback price; and routes to an internal compounding queue or external pharmacy fax. Prescribing is free-text at the dose level. E-signing is in-house, and no e-prescribing network was identified. A pharmacist-initiated correction loop (prepare → doctor review → replacement → reconcile) exists end to end.

## 3.3 Rx Pay {#rx-pay}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

A complete **one-time flat-$195** charge pipeline exists: auto-priced at issue, hosted Stripe Checkout on the pharmacy's own Stripe account, an SMS tap-to-pay link (no login required), webhook + 15-minute reconcile sweeps, and staff pricing/recovery tooling. The pay page shows a single amount; there is no recurring Rx price or subscription lifecycle. Charging also ships dark by default: with `RX_PAYMENT_FALLBACK` on (the default), patients see "the pharmacy will contact you" instead of a Pay button. The system auto-**prices** and sends a pay link; the patient must still complete checkout because the saved membership card cannot cross Stripe accounts.

## 3.4 Prescription Limits (3-month max before data-driven checkup) {#prescription-limits}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

**Nothing enforces prescription duration or supply caps.** The prescription expiry field exists in the database, but no production path writes it: a dormant EHR-sidecar helper can accept an expiry value, yet no production caller supplies one, so the live issue path always leaves it empty (its only readers are an ops diagnostic and the prescription-correction fingerprint). There are no months-supply/days-supply/refills-remaining fields and no 90-day or 3-month logic anywhere. Adjacent substrate exists: one refill task created 28 days after delivery, and weekly outcome check-ins starting at day 2: but neither gates further supply or forces a checkup before more medication.

## 3.5 Previous Charts / Records Ingestion {#records-ingestion}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

A real multi-stage pipeline: patient upload or administrator bulk import → sealed cloud storage → LLM field extraction (Google Gemini, BAA-covered) into structured clinical fields → PDF digestion into pages/elements/chunks → named-reviewer promotion into the chart's medical history with page-level source citations rendered in the EHR. Current extracted-field promotion is doctor-gated; doctors have review/promote surfaces but no equivalent upload route. Admin bulk chart imports (JSON/ZIP) exist and are idempotent. The named `HealthRecordImport` agent is legacy scaffolding; preserve it pending system-wide history/data review rather than declaring it deletable.

## 3.6 EHR Schema Cleanup {#ehr-schema-cleanup}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

**Review-hold inventory.** `DataNormalization`, `HealthRecordImport`, `OperationsDashboard`, `PatientSupport`, reply-support/nudge paths, `ehr_lab_import_export_runs`, `ehr_state_prescribing_rules`, `SubmitForDoctorReview` and its downstream chain, compounding workflows, lab orders/results, `prescriptions.external_id`, uploaded-document `fixture_path`, and `programs.template`. Preserve all pending system-wide caller/history/production-data review.

## 4.1 Order Labs {#order-labs}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Ordering as a flow **does not exist**. Read-side substrate is there: lab order and result tables with a status lifecycle, a read-only order list for lab-ops staff, and a real-LLM "lab necessity memo" agent that drafts whether labs are needed (always requiring human approval: "doctor signs the lab order"). But no code path creates a lab order (only tests do), there is no panel-selection UI, no requisition, and nothing transmits anything to any lab. Nothing populates lab results from an external source. The agent's prompt still addresses "Valinor": prototype-era scaffolding.

## 4.2 Quest Diagnostics Integration {#quest-diagnostics}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

**No Quest connectivity exists**: no API, ordering, result feed, credentials, or health-data-exchange client of any kind. What exists is Quest-code data plumbing: a biomarker crosswalk (Quest code → LOINC → canonical key) and a review queue for unknown codes: consumed only because Function Health results arrive carrying Quest result codes. The seeded crosswalk uses symbolic placeholder keys (real Quest codes can replace them in production without importer changes).

## 4.3 Concierge Phlebotomy {#concierge-phlebotomy}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Zero code substrate: no vendor client, no scheduling model, no $400 price constant, nothing. The vendor is still unnamed: the ops co-founder owes the priced-out concierge lab API link (open action item).

## 4.4 Function Health Lab Import {#function-health-lab-import}

**Verification:** Mixed. Historical f246 implementation evidence is carried forward, and the named mobile, HealthKit, Whoop, regimen, or support-reply artifacts are absent from both current core refs.

The carried-forward audit found two Function Health import paths: patient file upload under lab-import consent, and a short-lived browser-extension handoff to an isolated export runner. Imported panels are labeled patient-imported and as-reported, appear in clinician review surfaces, and appear on the patient web dashboard. A mobile labs read endpoint existed in the historical f246 snapshot but is absent from both current core refs; no iOS labs screen was identified.

## 4.5 Lab Follow-up {#lab-follow-up}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

A full provider review loop exists for both ordered and imported results: pending → reviewed/deferred verdicts, acknowledgment, critical override (written reason required), and recorded patient notification, with every action authorized against chart-access policy and logged. The queue ranks critical results first. The guardrail holds: a critical result **must** be acknowledged or overridden before patient notification can even be recorded. **Current limitation.** "patient notified" is a manually recorded attestation (channel + timestamp): the system does not itself message the patient or release results.

## 5.1 Protocols {#protocols}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

The carried-forward audit found formula masters and versioned formula records with draft, approved, superseded, and retracted states; a one-approved-version database constraint; programs; program-to-formula mappings; per-state formulary data; and empty titration rules. Seven seeded formula recipes, three programs, and two mappings were counted in that audit. The static medication content catalog was separate from protocol logic. Prescribing currently bypassed program mappings, so protocols were advisory rather than an enforced prescribing menu.

## 5.2 Internal Fulfillment Network {#internal-fulfillment-network}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

The historical audit found models and workflows for internal compounding, pharmacist review, lot consumption, release, shipment, and delivery. Pharmacist review and guarded lot consumption had UI paths, while start compounding, complete compounding, release, shipping readiness, dispatch, and delivery confirmation had no verified production caller. Launch configuration routed prescriptions externally by fax. The pharmacy supplies and prints the beyond-use date; software does not derive it. If this lane activates, release must not claim that a date exists unless a value was supplied.

## 5.3 Beyond-Use Date {#beyond-use-date}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

A nullable beyond-use-date field exists on compounding tasks and appears on staff screens, printable labels, and the patient order page. The pharmacy's physical process supplies and prints the date. Software stores and displays the supplied value but does not derive it. The carried-forward implementation audit found no production writer for the field and found a release checklist that asserted the date was set without checking for a value. The separate delivery-plus-28-day refill task is not a beyond-use-date rule.

## 5.4 Delivery Bot {#delivery-bot}

**Verification:** Mixed. Historical f246 implementation evidence is carried forward, and the named mobile, HealthKit, Whoop, regimen, or support-reply artifacts are absent from both current core refs.

The carried-forward audit found a deterministic shipment planner, shipment records, patient-facing fulfillment status, and order-page tracking. It also found no carrier API, tracking webhook, polling job, production trigger for dispatch or delivery, or automated patient shipment notification. Locally generated tracking identifiers and an empty temperature trace were placeholders. A mobile shipments endpoint existed in the historical f246 snapshot but is absent from both current core refs.

## 5.5 Medication Catalog {#medication-catalog}

**Verification:** Mixed. Current main/staging placement of the suggested-prescriptions catalog verified 2026-07-21; static-catalog counts are carried forward.

Two catalog surfaces exist. Static public medication JSON supports agent and research content but is not the prescribing or compounding authority. The database-backed suggested-prescriptions catalog is managed in Ops and is available to prescribing surfaces on both current main and staging. The carried-forward static-content audit counted 41 entries. No pipeline was identified that turns public medication content into approved protocol versions.

## 5.6 3PL Fulfillment Handoff {#3pl-fulfillment-handoff}

**Verification:** Not built. Added as approved product direction on 2026-07-30 from the current fulfillment operating model.

No 3PL or ShipStation connection is represented in the reconciled implementation evidence. The adjacent Shipment model and its unused unique `external_id` provide storage substrate, but the shipping-readiness path has no verified production caller and dispatch currently generates synthetic tracking. The active ExternalFulfillment path is a separate prescription-fax handoff to an external pharmacy. No outbound 3PL order submission, positive acknowledgment, retry ledger, authenticated inbound webhook or feed, status mapping, ShipStation configuration, or Ops reconciliation surface exists.

## 6.1 Billing Architecture {#billing-architecture}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

The carried-forward code audit found separate Stripe credential families for membership and per-state medication charges, rather than a split of one charge. Membership and medication charges used isolated credentials and webhook secrets, and medication checkout required the patient to enter payment details again because cards did not cross accounts. The approved target is for RonanRx Inc to collect the $39 membership as merchant of record, retain $10, absorb processing from that share, and pay the doctor $29 through Stripe Connect. Stripe account state and descriptors cannot be proven from source code.

## 7.1 Check-Ups {#check-ups}

**Verification:** Mixed. Historical f246 implementation evidence is carried forward, and the named mobile, HealthKit, Whoop, regimen, or support-reply artifacts are absent from both current core refs.

The carried-forward audit found a recurring patient outcome-check-in loop with due-item dispatch, a 1-to-5 response, optional free text, and self-scheduling. It did not find a doctor-facing review gate for individual responses. A mobile response endpoint existed in the historical f246 snapshot but is absent from both current core refs. The historical implementation used a maximum 30-day cadence and surfaced only aggregate trends to administrators.

## 7.2 Refills {#refills}

**Verification:** Mixed. Historical f246 implementation evidence is carried forward, and the named mobile, HealthKit, Whoop, regimen, or support-reply artifacts are absent from both current core refs.

The carried-forward audit found a refill task created after delivery, due 28 days later, with patient confirm and pause actions and a therapy-hold guard. It found no doctor or pharmacist approval surface, no consumer that turned a confirmed refill into a pharmacy order, and no recurring cycle. Regimen projection existed in the historical f246 snapshot but is absent from both current core refs. This is retained scaffolding pending the D10 production census.

## 7.3 Doctor Newsfeed {#doctor-newsfeed}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Substrate without a product. A real append-only event log powers activity feeds, and a per-patient graph record has a timeline field: but no doctor-facing feed renders any of it. Doctors get a per-case snapshot (patient graph, clinical brief, imported labs, 14-day Oura trends) and EHR chart accordions; the only chronological feed rendered anywhere is **patient-facing** (last 8 events on the patient dashboard); weight-loss narrative exists only as program-level aggregates on an admin dashboard. **Naming boundary:** the sibling repo named `ronanrx-timeline` is a different product and is outside this approval pass (§10.2); do not use it as evidence for this core feature.

## 7.4 Doctor to Patient Texting {#doctor-patient-texting}

**Verification:** Verified 2026-07-21 against core staging `c0024874` and production main `d26d5e1c`.

On current staging, the Flue cutover applies only to onboarding conversation turns. Rails still owns Linq ingress, safety policy, staff takeover, transactional messages, and guarded delivery. No doctor texting surface was found on current main or staging. The support-reply workflow, care-team reply nudge, and support-body encryption observed in the historical f246 snapshot are absent from both current refs. Production main still runs the earlier Rails onboarding voice.

## 7.5 Urgent Text Escalation (Patient → Dr / Pharmacist / 911) {#urgent-text-escalation}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Detection and hold machinery is fully wired: **every** inbound text runs emergency detection against a governed emergency registry; tier 1–2 matches auto-latch an emergency hold and reply "This could be an emergency. Call 911 now or go to the nearest emergency room. If you are thinking about harming yourself, call or text 988."; holds cascade into therapy holds and adverse events; and an on-call escalation ladder schedules follow-ups, swept every minute. **But the ladder's transport table is empty: no paging/calling adapter is implemented: so nobody is actually paged or called**; the system can only record that a page was blocked. Releasing an emergency hold is restricted to a doctor/pharmacist in the patient's clinic with a written reason: and has no UI (console only). There is also no direct patient→doctor channel; urgency reaches humans only via this (currently non-delivering) ladder.

## 8.1 App Data Collection {#app-data-collection}

**Verification:** Mixed. Historical f246 implementation evidence is carried forward, and the named mobile, HealthKit, Whoop, regimen, or support-reply artifacts are absent from both current core refs.

Withings and Oura integration paths are present in the current Rails application. Whoop services, Rails HealthKit ingestion and rollups, mobile sessions, and mobile tracking endpoints observed in the historical f246 snapshot are absent from both current core refs. The iOS repository contains HealthKit packages and entitlements, but its application composition does not start the HealthKit manager or uploader. HealthKit is therefore not an end-to-end current path.

## 8.2 Health History Questionnaire {#health-history-questionnaire}

**Verification:** Mixed. Historical f246 implementation evidence is carried forward, and the named mobile, HealthKit, Whoop, regimen, or support-reply artifacts are absent from both current core refs.

The carried-forward audit found a versioned, one-question-per-screen health-history questionnaire with append-only revisions, signup prefilling, completion nudges, and doctor review under chart-access logging. Questionnaire answers and clinician chart facts were stored separately and reconciled manually. Mobile dose logs, side-effect logs, intake logs, and patient goals existed in the historical f246 snapshot but are absent from both current core refs.

## Cam's Crack Commandments {#cams-crack-commandments}

**Verification:** Scope-only. No implementation claim is made for this boundary card.

No implementation claim was re-verified for this boundary card; the card records scope only.

## 9.1 Agent Router {#agent-router}

**Verification:** Routing placement reverified 2026-07-30 against deployed production `2a346e1` and staging `608c9d9`; broader route inventory remains from the 2026-07-21 audit.

Both deployed environments route onboarding conversation turns from Rails into one focused Flue onboarding agent in `rrx_agents`. Rails retains ingress controls, opt-out, emergency and dosing policy, human-takeover precedence, completion-link creation, persistence, SendGuard, and outbound delivery. This is not a general router for support, retention, doctor messaging, or clinical lanes.

## 9.2 Patient Support {#patient-support}

**Verification:** Mixed. Historical f246 implementation evidence is carried forward, and the named mobile, HealthKit, Whoop, regimen, or support-reply artifacts are absent from both current core refs.

The current Rails application retains a patient support inbox and the unwired `Agents::PatientSupport` class. No production caller for the agent or staff reply surface was verified. The mobile support endpoint, `Workflows::ReplyToSupportMessage`, `CareTeamReplyNudgeJob`, and support-body encryption observed in the historical f246 snapshot are absent from both current main and staging. A separate non-serviceable-state cancellation path remains adjacent behavior and is not an agent-handled support conversation.

## 9.3 Retention Agent {#retention-agent}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Nothing. "Retention" in the codebase means **data** retention (record-keeping policies, sample pruning); the closest churn-adjacent text is a "churn surface" line item in an admin report description: reporting copy, not intervention code. Zero churn-intervention, drop-off detection, or winback code, tables, or routes. The nearest neighbors are the compliance nudges (health history, weigh-in), which are not retention.

## 9.4 Founder Mode / Dr. Bot {#founder-mode}

**Verification:** Verified 2026-07-21 against core staging `c0024874` and production main `d26d5e1c`.

The Ruby Founder Mode file and trigger path are present on production main and deleted on current staging as part of the Flue onboarding cutover. No replacement Founder Mode behavior exists in the staging Flue onboarding agent. The product remains approved intent, subject to the open clinical boundary owned by Zach.

## 9.5 Medical Research Agent {#medical-research-agent}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Two real halves that don't touch. (1) A real-LLM evidence-synthesis agent is wired into the doctor-review workflow (itself dormant: no production caller, §2.5): but its input is just a recommendation id and program name, so its citations come from model memory, **not** from any corpus (ungrounded). (2) A full PubMed ingestion pipeline exists (search → full-text resolution → PDF parsing → stored documents and per-medication citations, with a 15-minute reconcile job): but it defaults **off** (`RESEARCH_INGEST_ENABLED`), has no read surface for anyone, and the governance/evidence-grading layer required before exposing it to doctors or patients is unbuilt.

## 9.6 Nutrition / Fitness Agent {#nutrition-fitness-agent}

**Verification:** Mixed. Historical f246 implementation evidence is carried forward, and the named mobile, HealthKit, Whoop, regimen, or support-reply artifacts are absent from both current core refs.

No coaching agent was found. Oura and Withings provide adjacent lifestyle-data collection. Whoop and Rails HealthKit capabilities observed at f246 are absent from both current core refs. The iOS HealthKit package is not wired into the application entrypoint. None of this substrate currently produces nutrition or fitness coaching.

## 9.7 Drift Layer {#drift-layer}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Six real self-checking mechanisms are wired: **but none of them reads this document or technical.md**, so the target's "checks the live product against the reviewed suite" behavior does not exist yet: (1) an architecture-check script comparing code against hard-coded structural allowlists, not this spec (advisory, fails only on NEW drift beyond a grandfathered 2026-07-04 baseline); (2) a weekly signed-note-vs-decision record drift judge (Mondays 7am Central); (3) a post-deploy release canary asserting the deployed version; (4) a daily observability digest (5:30am Central) turning metrics into findings, optionally LLM-ranked, delivered to Slack and persisted; (5) a nightly conversation judge (6am Central) auditing up to 200 agent conversations against deterministic tripwires plus an LLM pass; (6) a compile/test-time Sentry alert registry (landed 2026-07-17): every alert message must be pre-declared or the app fails at class load. Governed artifacts (versioned prompts/content with hash-chained, passing-only eval evidence) round out the drift defense.

## 9.8 Agent Census {#agent-census}

**Verification:** Verified 2026-07-21 by enumerating the Ruby agent namespace on both current refs and the Flue onboarding service on staging.

Production main contains 22 Ruby agent classes plus `BaseAgent`, including `Agents::LinqConversationalist`. Current staging contains 21 Ruby agent classes plus `BaseAgent`, because `Agents::LinqConversationalist` was deleted, and adds one focused Flue onboarding agent outside the Ruby namespace. `Agents::OnboardingConcierge` remains in both branches. Counts and classifications are branch-specific and must be refreshed through the D10 card-by-card census before removal or CI decisions.

## 10.1 RonanRX iOS {#ronanrx-ios}

**Verification:** Mixed. Current core branch placement verified 2026-07-21; iOS package detail is carried forward and must be reverified in the iOS repository before implementation.

The iOS repository contains packages for OTP and session handling, offline sync, reminders, dose and reconstitution calculations, and HealthKit access. The application entrypoint does not compose these packages into a working patient experience, and HealthKit collection is not started. The `/api/mobile/v1` Rails backend observed in the historical f246 snapshot is absent from both current core refs. Shipping the intended app therefore requires restoring or rebuilding and re-verifying the server contract, not promoting a current staging branch.

## 10.2 The Daily Compound {#the-daily-compound}

**Verification:** Scope-only. No implementation claim is made for this boundary card.

No implementation claim was re-verified for this boundary card; the card records scope only.

## 10.3 ronanrx-brain {#ronanrx-brain}

**Verification:** Scope-only. No implementation claim is made for this boundary card.

No implementation claim was re-verified for this boundary card; the card records scope only.

## 10.4 Elite Care Pharmacy Site {#elite-care-pharmacy-site}

**Verification:** Scope-only. No implementation claim is made for this boundary card.

No implementation claim was re-verified for this boundary card; the card records scope only.

## 10.5 TestFlight Protocol Sandbox {#protocol-sandbox}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

Not started. No admin test app exists in any repo; the iOS repo is the patient app, not a duplicated admin build. The open action item (technical founder to set up the duplicated admin app in TestFlight) remains open.

## 11.1 Provider Onboarding {#provider-onboarding}

**Verification:** Unverified, carried forward from the earlier implementation audit. Recheck against current refs before relying on exact constants, counts, flags, or wiring.

The carried-forward audit found two provider creation paths. Code-gated self-signup created inactive credentials and state licenses pending human activation; the admin-invite path activated submitted licenses immediately. The invite path included a six-document provider agreement packet, while the code-gated path did not record the same packet. Both paths attached providers to a clinic. The approved membership economics are the existing $10 RonanRx share and $29 doctor payout; Stripe Connect setup and payout wiring remain implementation work.

## 12.1 Ops Console {#ops-console}

**Verification:** Mixed. Current main/staging placement of People, Goal editing, and suggested prescriptions verified 2026-07-21; remaining implementation detail is carried forward.

The current Ops Console includes a People directory for patients, doctors, and leads; conversation detail; staff sends; assistant pause and resume; appointment cancel and rebook; an operator clinical-field editor; ID viewing; completion-link resend; payment diagnostics; view-as impersonation; and the suggested-prescriptions catalog. The People directory, Goal editor, and suggested-prescriptions catalog are present in both current main and staging. Human console actions and machine Ops API mutations use different audit paths. The target chat surface for payment actions and multiple prescriptions is not yet represented by the carried-forward implementation audit.

## Change discipline

When a current implementation check changes a statement, update the relevant card's verification label, cite the new full ref in the banner or section, and preserve historical f246 evidence only when it explains migration or recovery work. Do not convert as-built behavior into binding intent without an approved rule or decision.