# RonanRx: Naming Registry and Jargon Glossary

**Date:** 2026-07-30

**Implementation baseline:** core staging `c0024874` and core main `d26d5e1c`

**Purpose.** This registry gives each product concept one canonical name and makes legacy names searchable without allowing them to become new product vocabulary. Use the canonical heading in product copy and specification prose. Use implementation identifiers only when referring to the code, schema, route, or UI that actually carries that name.

Build status and branch-specific implementation evidence live in `status.json` and `as-built.md`. This glossary defines vocabulary; it does not turn a current implementation detail into a product rule.

## Alias policy

- A heading in the entries below is canonical unless the entry explicitly says it is an implementation term.
- An **allowed alias** may be used where its audience or historical context makes it clearer.
- A **historical only** term may appear in migration notes and searches, but not as new product prose.
- A **banned** term is too ambiguous to use.
- A backticked class, method, table, route, column, job, event, or environment variable is an **internal identifier**. Keep it exact in code references; do not promote it into product copy.
- Any prose synonym not explicitly allowed below is historical/search-only.

| Term | Disposition | Canonical use |
| --- | --- | --- |
| Signup Intake | canonical | Patient signup questionnaire |
| INFO #1 | allowed alias | Signup Intake |
| Pre-Doctor Intake | canonical | Questions collected before an appointment |
| INFO #2 | allowed alias | Pre-Doctor Intake |
| Health History Questionnaire | canonical | Versioned patient health-history form |
| INFO #3 | allowed alias | Health History Questionnaire |
| Full Health Profile | historical only | Health History Questionnaire |
| bare “triage” | banned | Use Pre-Doctor Intake, emergency classification, or the exact lead field |
| doctor intake | banned | Use Provider Onboarding for doctors or Pre-Doctor Intake for patients |
| doctor sign-up | historical only | Provider Onboarding |
| provider sign-up | historical only | Provider Onboarding |
| unqualified “timeline” | banned | Use Doctor Newsfeed, Outcome Check-ins, The Daily Compound, or PatientGraph timeline |
| unqualified “catalog” | banned | Use Medication Catalog or Suggested Prescriptions Catalog |
| unqualified “release” | banned | Name Pharmacist Release QA, emergency-hold release, therapy-hold release, or software release |
| OPs Panel | historical only | Ops Console |
| Striker Pharmacy | historical only | Stryker Pharmacy; current code spelling debt |
| True Nano | historical only | Stryker Pharmacy for product prose; Nano Home Inc. only when externally verified as the entity |
| encounter | internal only | Use appointment in product and specification prose |
| Reptile | historical only | Drift Layer |
| Greptile Agent | historical only | Drift Layer |
| customer service | historical only | Patient Support |
| Dr. Bot | allowed alias | Founder Mode |
| Doctor Picker | allowed alias | Dr. Picker |
| iPhone Link | allowed alias | Secure Signup Link |
| magic link | historical only | Secure Signup Link |
| completion link | historical only | Secure Signup Link |
| flat launch price | historical only | Current fallback belongs only in as-built evidence |
| flat $195 price | historical only | Current `19_500`-cent fallback belongs only in as-built evidence |
| memo medication prices | historical only | Use the per-item Medication Catalog Price |
| RX Pay | allowed alias | Rx Pay |
| health profile | historical only | Name Health History Questionnaire or Patient Chart Facts explicitly |

---

## Entries

### 3PL Fulfillment Handoff: §5.6

**Definition.** The controlled connection that sends a pharmacist-released, fulfillment-ready order to the contracted third-party logistics provider's ShipStation workflow and returns authoritative acknowledgment, packing, label, carrier, and tracking state.

**Ownership.** RonanRx owns the release gate, outbound handoff record, acknowledgment and retry state, returned-event provenance, and Ops reconciliation. The 3PL owns packing, sealing, postage purchase, carrier-label printing, and carrier tender. Delivery Bot owns patient communication from returned events.

**Usage.** ShipStation is the 3PL's shipping system, not a RonanRx printer queue. A sent or acknowledged handoff is not proof of shipment, and label creation is not proof of carrier tender. Do not call this External Fulfillment, which is the separate prescription-fax handoff to an external pharmacy.

### Agent Census: §9.8

**Definition.** The branch-dated inventory of agent implementations and their actual callers.

**Current branch facts.** Staging has 21 Ruby `Agents::*` classes plus `BaseAgent` and one Flue onboarding brain. Main has 22 Ruby `Agents::*` classes plus `BaseAgent`. `Agents::OnboardingConcierge` remains in staging and is still invoked before route resolution, although its artifact is not used by the Flue onboarding branch.

**Usage.** Do not infer that a capability exists from a class name. The keep, merge, replace, or delete disposition for each legacy component remains an engineering census task.

**Evidence.** `app/services/agents/`, `rrx_agents/`, and technical §9.8.

### Agent Router: §9.1

**Definition.** The product concept that classifies an inbound patient interaction and selects the appropriate governed lane.

**Current branch facts.** Rails remains the public Linq ingress, safety, policy, persistence, and delivery layer on staging. For an onboarding turn, Rails calls `Linq::AgentTurnJob` and `RrxAgents::TurnClient`, then applies SendGuard and sends through the Rails delivery path. Flue supplies only the onboarding reply brain. Main still uses the older Ruby onboarding voice. No general router currently dispatches patient support, retention, health questions, and clinical conversations across Flue.

**Usage.** `PreDoctorIntakeRouter` is one narrow policy hop, not the general Agent Router.

**Evidence.** `Api::V1::LinqController#inbound`, `Linq::AgentTurnJob`, `RrxAgents::TurnClient`, and technical §9.1.

### Beyond-Use Date (BUD): §5.3

**Definition.** The discard-after date supplied and printed by the pharmacy through its physical production process.

**Product rule.** Software may store and display the supplied value. It does not derive the value. If the internal fulfillment lane is activated, the release checklist must test a real supplied value rather than automatically marking `bud_set` true.

**Distinction.** The 28-day refill due date scheduled by `Workflows::ConfirmDelivery` is a refill rule, not a BUD rule. “Freshness window” is allowed patient-facing copy for a displayed BUD.

**Evidence.** `beyond_use_date`, `Workflows::ReleaseQa`, `Agents::QualityGate`, label views, and technical §5.3.

### Cam's Crack Commandments: §9

**Definition.** The twelve agent-layer rules governing simplicity, operator ownership, use of existing systems and data, EHR ownership of patient health data, and disciplined treatment of settled decisions.

**Usage.** This name is canonical. The numbered rule text lives in the business specification and must not be replaced with a shortened folk version.

### Check-Ups: §7.1

**Definition.** The target doctor-gated review of patient outcomes before care continues.

**Current branch facts.** Outcome Check-ins collect patient self-scores, but doctors do not currently receive a Check-Ups review surface. Do not conflate Check-Ups with `weigh_in_nudges` or the separate prescription-limit review trigger.

**Distinction.** Check-Ups are doctor-reviewed. Outcome Check-ins are patient-reported data collection.

### Clinical Brief implementation: §2.5

**Definition.** The LLM implementation in `Agents::PatientSummary` that creates a `physician_brief` artifact for the doctor case page.

**Current branch facts.** Its producer, `Workflows::SubmitForDoctorReview`, has no verified production trigger. Treat this as one implementation under the Pre-Brief product surface, not as a second product.

**Evidence.** `app/services/agents/patient_summary.rb`, `app/views/doctor/cases/show.html.erb`, and technical §2.5.

### The Daily Compound: §10.2

**Definition.** The separate product in the sibling `ronanrx-timeline` repository.

**Usage.** It is not Doctor Newsfeed and is outside the current core and iOS implementation audit. Do not use facts from the sibling product as evidence for a core feature.

### Delivery Bot: §5.4

**Definition.** The product surface that consumes authoritative 3PL and carrier events and communicates approved medication-delivery milestones to the patient.

**Current branch facts.** `Agents::ShippingCoordination` emits a `shipment_plan` artifact, and Shipment records move through synthetic dispatch and delivery confirmation. No 3PL or carrier event source exists. A complete patient-facing notification experience is still a target.

**Evidence.** `app/services/agents/shipping_coordination.rb`, `app/models/shipment.rb`, and `Workflows::DispatchShipment`.

### Doctor to Patient Texting: §7.4

**Definition.** The governed human messaging surface for a doctor or authorized staff member to communicate with a patient.

**Current branch facts.** Admins can send free text from the Ops Console into a Linq conversation. Doctors have no texting surface in either current branch. `Workflows::ReplyToSupportMessage` and `CareTeamReplyNudgeJob` are absent from both current refs; their older implementation evidence is historical only. Flue is the staging onboarding brain and does not replace or implement this lane.

**Usage.** Do not describe admin messaging as doctor texting. A future doctor surface must preserve consent, auditability, human takeover, and visible delivery failure.

**Evidence.** `Linq::AdminMessages::Send`, `ops_admin_message`, and technical §7.4.

### Doctor Newsfeed: §7.3

**Definition.** The target doctor-facing feed of patient progress and relevant events.

**Current branch facts.** The append-only `events` table is useful substrate, but no doctor surface renders a newsfeed. The patient dashboard activity list is a different surface.

**Usage.** Do not call this “timeline” without the Doctor Newsfeed qualifier, and do not conflate it with The Daily Compound.

### Doctor Visit: §2.6

**Definition.** The synchronous doctor-patient appointment, including its booking record, video space, and linked chart documentation.

**Usage.** “Appointment” is the canonical product and specification term. `Ehr::Encounter` is an internal implementation identifier retained until a safe migration is practical.

**Evidence.** `Appointment`, `MeetSpace`, `Ehr::Encounter`, and technical §2.6.

### Dr. Picker: §2.1

**Definition.** The signup scheduling surface where a patient selects an eligible doctor from the clinic roster and available appointment data.

**Current branch facts.** Do not claim specialty, price, or preference matching unless a current implementation is verified. State eligibility and routing rules must be tested from current code rather than inferred from the name.

**Alias.** “Doctor Picker” is allowed when punctuation is inconvenient.

### Drift Layer: §9.7

**Definition.** The umbrella name for independent mechanisms that detect architecture, behavior, release, observability, conversation, and alert drift.

**Current branch facts.** No code namespace is named Drift Layer, and no single agent owns all of these checks. The umbrella must not cause a seventh checker to be built before the existing mechanisms are inventoried.

**Aliases.** “Reptile” and bare “Greptile Agent” are historical only.

**Evidence.** `bin/architecture-check`, note-drift sampling, release canary, observability digest, nightly conversation judge, and the Sentry alert registry.

### Elite Care Pharmacy: §6.1 and §10.4

**Definition.** The Texas pharmacy product name used by current fulfillment routing.

**Usage.** Exact entity names, account descriptors, credentials, and support URLs are external facts and appear in the specification only after verification.

**Evidence.** `Pharmacy::FulfillmentRouting`, `RxBilling`, and technical §6.1.

### External Fulfillment: §3.2 and §5.2

**Definition.** The current fax-based handoff from an issued prescription to a state-routed external pharmacy.

**Current branch facts.** `ExternalFulfillment` coexists with the incomplete Internal Fulfillment Network. It is not proof that the internal workflow is active.

**Evidence.** `ExternalFulfillment`, `Pharmacy::FulfillmentRouting`, and the prescription issue workflow.

### Founder Mode: §9.4

**Definition.** The product intent for a founder-style Doctor Bot experience.

**Current branch facts.** Main still contains and routes through `Linq::FounderMode` in the older Ruby onboarding path. Staging deletes `Linq::FounderMode` and `Agents::LinqConversationalist` as part of the focused Flue onboarding change.

**Boundary.** Founder Mode remains intended, but its clinical behavior, escalation boundary, and ownership model are open. Do not expand Flue onboarding into clinical advice before that boundary is decided.

**Alias.** “Dr. Bot” is allowed.

### Health History Questionnaire: §8.2

**Definition.** The versioned patient-reported health-history questionnaire, prefilled where possible from Signup Intake.

**Current branch facts.** The Rails/web questionnaire remains current. The older mobile namespace, regimen sync, Whoop services, and Rails HealthKit ingestion are absent from both current refs and must not be described as staging features.

**Aliases.** “INFO #3” is allowed. “Full Health Profile” and unqualified “health profile” are historical only.

**Evidence.** Health-history models and views, `Linq::SignupForward::FIELD_MAP`, and technical §8.2.

### Human Takeover: §7.4 and §2.3

**Definition.** The conversation state that pauses automated replies so an authorized human can handle the thread.

**Usage.** Human takeover is canonical. Vendor- or controller-specific names are internal identifiers.

**Evidence.** Linq conversation takeover columns, Ops conversation actions, and the admin-message send path.

### ID Verification: §1.7

**Definition.** The identity-verification step in secure signup.

**Usage.** Distinguish patient identity verification from provider credential verification in Provider Onboarding. Vendor and route names remain internal identifiers.

### Internal Fulfillment Network: §5.2

**Definition.** The target pharmacy operating workflow for routing, preparation, QA, pharmacist approval, and fulfillment readiness before the §5.6 3PL handoff.

**Current branch facts.** Models and workflow services exist, but the full lane has not been verified as wired through production callers. The pharmacy supplies and prints BUD; software stores and displays it.

**Usage.** Do not equate the presence of workflow classes with an active licensed operation. Use Pharmacist Release QA for the final medication-release step. Do not assign the 3PL's packing, label, or carrier-tender work to Pharmacy Queue.

### Lead: §1.3 adjacent

**Definition.** A partnership or contact-form capture that is not yet a patient Signup Intake.

**Usage.** Keep Lead, Public Intake, and Signup Intake distinct. The `public_intakes.triage` column is an internal legacy field, not authorization to use bare “triage.”

### Linq Line: §1.1

**Definition.** The patient messaging rail carried through the Linq partner API.

**Current branch facts.** Rails owns webhook verification, message records, deterministic policy, and delivery in both current architectures. On staging, Flue produces onboarding reply content only.

**Usage.** Linq is a vendor-specific implementation name. It is not another name for Secure Signup Link.

### Medication Catalog: §5.5

**Definition.** The canonical name for patient and operator medication content. Qualify which catalog is meant:

- **Medication Catalog:** medication education and stocked product information.
- **Suggested Prescriptions Catalog:** the Ops catalog used for prescription selection and per-item pricing.

**Product rule.** Medication prices are per catalog item. Doctors may choose a dose in milligrams but may not alter the stocked vial or concentration.

**Usage.** Bare “catalog” is banned because these two surfaces have different responsibilities.

### Membership Subscription: §1.5 and §6.1

**Definition.** The recurring $39 RonanRx membership charge.

**Product economics.** RonanRx Inc. is merchant of record, retains $10, absorbs Stripe processing from that amount, and pays the doctor a flat $29 through Stripe Connect. Stripe Connect setup and payout wiring remain implementation work.

**Distinction.** Medication charges are separate and use the selected catalog item price. Do not reintroduce tiered provider economics as the launch model.

### Onboarding Agent: §1.2

**Definition.** The conversational brain that guides a prospective patient through Signup Intake.

**Current branch facts.** Main uses the older Ruby `Agents::LinqConversationalist` path with `Agents::OnboardingConcierge`. Staging routes onboarding turns from Rails through `Linq::AgentTurnJob` and `RrxAgents::TurnClient` to Flue. Rails still owns Linq ingress, deterministic safety and policy, persistence, onboarding completion, SendGuard, and delivery. `Agents::OnboardingConcierge` remains invoked before staging route resolution, although its artifact is not consumed by the Flue branch.

**Usage.** “Onboarding Agent” names the product role, not a single class. Flue is onboarding-only.

### Ops Console: §12.1

**Definition.** The operator surface for people, conversations, cases, fulfillment, configuration, and manual actions.

**Usage.** Ops Console is canonical. “OPs Panel” is historical only. A staff message sent from this surface is not Doctor to Patient Texting.

### Outcome Check-ins: §7.1

**Definition.** Recurring patient self-scores collected after treatment begins.

**Current branch facts.** The current loop can schedule prompts and record responses, but doctors do not have the target Check-Ups review surface. Older mobile check-in endpoints are absent from both current refs.

**Distinction.** Outcome Check-ins collect data. Check-Ups are the doctor-gated review.

### Patient Chart Facts: §8.2 and §3.1

**Definition.** Structured clinical facts maintained through `PatientGraph` and the EHR boundary.

**Usage.** “Patient Chart Facts” is canonical product prose. `PatientGraph` is the internal implementation name. Do not call this unqualified “health profile” or “timeline.”

### Patient Support: §9.2 and §7.4

**Definition.** The support lane for established patients.

**Current branch facts.** The portal support inbox remains. The older mobile create endpoint, support-body encryption, care-team reply workflow, and reply nudge are absent from both current refs. `Agents::PatientSupport` remains an unwired implementation with no verified production caller.

**Usage.** “Customer service” is historical only. `Agents::LinqPatientSupport` and `handle_patient_support` are historical worktree names, not current code truth. Flue does not currently implement Patient Support.

### Pharmacist Release QA: §5.2

**Definition.** The final pharmacist-controlled quality review before an internally fulfilled medication may be released.

**Product rule.** The release record must reflect real supplied values and approvals. The BUD check must not auto-assert a date that was not entered.

**Usage.** Always qualify “release” with Pharmacist Release QA when referring to this step.

### Pre-Brief: §2.5

**Definition.** The canonical appointment-driven summary that helps a doctor prepare for a visit.

**Current branch facts.** `Ehr::Integration::PreCallBrief` is the deterministic schedule-page read model. `Agents::PatientSummary` is a separate LLM implementation whose production trigger is not verified. They are implementations beneath one product surface.

**Target.** The appointment link and configurable reminders should lead to the relevant intake, clinical context, labs and chart, and video link.

### Pre-Doctor Intake: §2.3

**Definition.** The patient questions collected before a doctor appointment.

**Aliases.** “INFO #2” is allowed. Bare “triage” and “doctor intake” are banned.

**Evidence.** `ehr_pre_doctor_intakes`, `PreDoctorIntakeRouter`, and technical §2.3. The `GLP1_*` environment prefix is internal naming debt and does not limit the product concept to GLP-1 care.

### Protocols: §5.1

**Definition.** The governed formula and program system: formula masters and approved versions, programs and their state-aware mappings, plus the stocked vial and concentration constraints in the catalog.

**Product rule.** There is no numeric protocol-count target. Doctors may choose dose in milligrams but may not modify the stocked vial or concentration. Experimental changes run only in an isolated duplicate through the TestFlight Protocol Sandbox before any later connection to the live engine.

**Code vocabulary.** `FormulaMaster`, formula versions, `Program`, program-formula mappings, `Formulation`, and formulary are distinct internal concepts. Do not collapse them into a count.

### Provider Onboarding: §11.1

**Definition.** The doctor application, credentialing, agreement, and activation path.

**Product economics.** The launch agreement is the $10 RonanRx share and $29 doctor payout through Stripe Connect. Remaining work is account setup and payout wiring, not a new economics decision.

**Aliases.** “Doctor intake” is banned. “Doctor sign-up” and “provider sign-up” are historical only.

### Public Intake: §1.3 adjacent

**Definition.** A lead-capture record stored in `public_intakes`.

**Usage.** It is not Signup Intake or Pre-Doctor Intake. The legacy `triage` column is an internal field name only.

### real_llm! naming fossil: §9.8

**Definition.** An internal marker used by Ruby agent classes to distinguish a model-backed implementation from deterministic or hardcoded behavior.

**Usage.** `real_claude!` and `real_llm!` are internal identifiers, not claims about the current provider or model. Branch differences in the Agent Census must be stated explicitly; staging's Flue onboarding brain is outside the Ruby marker system.

### Reengage / Close Agent: §1.6

**Definition.** The target capability that follows up with prospective patients who leave signup before completion.

**Current branch facts.** Deterministic reminders and manual secure-link resends exist. The broader adaptive closer is not implemented. Older mobile reminder substrate is absent from both current refs.

**Usage.** `Reengage` is an internal or historical short name; use Reengage / Close Agent in product prose.

### Refill Task: §7.2

**Definition.** The work item that prompts review and action when a medication refill is due.

**Current branch facts.** Delivery confirmation can schedule a refill task 28 days later. That interval is current implementation evidence, not a BUD and not a universal protocol duration.

**Usage.** “REFILLS RX” is historical only. Use Refill Task or Refills.

### ronanrx-brain: §10.3

**Definition.** A separate sibling system outside the current core and iOS implementation audit.

**Usage.** Do not transfer runtime, privacy, or feature claims from the sibling system into the core specification without a separate audit.

### Rx Pay: §3.3

**Definition.** The patient payment flow for an issued medication, separate from the Membership Subscription.

**Product rule.** The server applies the selected Suggested Prescriptions Catalog item price. One-time and subscriber-specific prices are intended; the separate subscriber price is not yet represented.

**Current branch facts.** `RxPricing` still contains a legacy `19_500`-cent fallback. That fallback is as-built evidence only and is not the canonical product price.

**Evidence.** `PrescriptionPayment`, `RxPayments::CheckoutSession`, `RxBilling`, and technical §3.3.

### Medication Catalog Price: §3.3

**Definition.** The canonical term for a medication's per-item price in the Suggested Prescriptions Catalog.

**Usage.** `RxPricing` and `RX_FLAT_PRICE_CENTS` are internal legacy implementation names. “Flat launch price,” “flat $195 price,” and memo medication-price phrases are historical only and must not appear as target pricing.

### Secure Signup Link: §1.1

**Definition.** The tokenized, expiring link sent to a patient to continue secure signup.

**Aliases.** “iPhone Link” is allowed product language. “Magic link,” “completion link,” and “signup link” are historical only unless quoting a current UI or code identifier.

**Evidence.** `SecureLink`, `SignupMagicLink`, short-link routes, and technical §1.1.

### SendGuard: §1.2 and §7.4

**Definition.** The deterministic policy guard used by the Rails onboarding reply path before delivery.

**Current branch facts.** On staging, Flue returns onboarding reply content to Rails, and Rails applies SendGuard before `LinqReplyJob` sends it. SendGuard is not a universal transport choke point: staff-authored Ops messages and some transactional senders take different paths.

**Usage.** Hardcoded allowed-price figures in SendGuard are current guard configuration, not product pricing authority. Map all senders before changing this boundary.

### Separate Stripe Accounts: §6.1

**Definition.** The billing architecture that keeps the RonanRx membership charge separate from medication charges made through pharmacy account families.

**Current branch facts.** Current code uses membership credentials and per-state Rx credential families; it does not split one medication charge. The target membership economics separately use Stripe Connect to pay the doctor $29 from the $39 membership while RonanRx retains $10.

**Usage.** Separate charge accounts and Connect payouts solve different problems. Do not treat either as a synonym for the other. Account names, descriptors, and support URLs remain externally owned facts.

**Evidence.** `RxBilling`, `RX_<STATE>_STRIPE_*`, and the membership billing services.

### Signup Intake: §1.3

**Definition.** The patient signup questionnaire whose answers are stored in `intake_responses.answers`.

**Current branch facts.** Main collects it through the Ruby onboarding conversation. Staging uses the Flue onboarding brain while Rails retains policy, completion, persistence, and delivery.

**Alias.** “INFO #1” is allowed.

**Distinction.** `public_intakes` is Public Intake lead capture. `ehr_pre_doctor_intakes` is Pre-Doctor Intake. `dead_letter_intakes` is an ingest-replay mechanism.

### Stryker Pharmacy: §6.1 and §5.2

**Definition.** The canonical California pharmacy product name.

**Current branch facts.** Current routing and display strings spell it “Striker Pharmacy.” Treat that spelling as migration debt, not approved product prose. Nano Home Inc. is the intended related billing entity but must be presented as an external fact only after verification.

**Aliases.** “Striker Pharmacy” and “True Nano” are historical only.

**Evidence.** `Pharmacy::FulfillmentRouting`, `RxBilling`, and technical §6.1.

### Urgent Text Escalation: §7.5

**Definition.** The governed urgent-inbound lane that performs emergency classification, latches an emergency hold when required, and starts an on-call escalation sequence.

**Current branch facts.** The Rails safety branch runs before onboarding. The on-call ladder has no verified page or call transport where `OnCall::Dispatch::ADAPTERS` is empty, and hold release lacks a complete operator UI. Flue remains onboarding-only and does not own urgent escalation.

**Usage.** SendGuard is an outbound policy component, not the urgent lane. The deleted staging `Agents::LinqConversationalist` was an onboarding voice, not an emergency service. Bare “triage” remains banned; “emergency classification” is the preferred product term.

**Evidence.** `Linq::EmergencyDetection`, `Linq::RedFlagDetector`, `LinqEmergencyHold`, `OnCallEscalationJob`, and technical §7.5.

### View-as Impersonation: §12

**Definition.** The Ops Console tool that lets an authorized operator reproduce a doctor or patient view.

**Usage.** “View as” is allowed UI copy. “Impersonation” is the internal code term. `STAGING_LOGIN_BYPASS` is a retired historical identifier and must not be rebuilt as an access path.

**Evidence.** `Ops::ImpersonationsController`, `Ops::Integration::Impersonation`, and the Ops People views.

### Visit Observation: §2.7

**Definition.** The automatic set of candidate screenshots sampled from patient-speaking portions of a recorded video appointment and added to the EHR. A screenshot becomes an attributable input to doctor-reviewed visual documentation only after the doctor confirms that its visible subject is the patient.

**Usage.** Visit Observation is automatic. The doctor does not initiate capture or approve images before attachment, but confirms the visible subject before an image may inform the note and can delete any or all screenshots. Describe visible facts and sampled-image limitations. Do not use the term for sobriety verification, credibility scoring, medication-seeking detection, facial recognition, or prescribing eligibility.

**Implementation terms.** Native Meet recording, recording resource, transcript interval, extraction bucket, screenshot checksum, and `MEET_AGENT_EMAIL` are internal identifiers.

### White-Label Pharmacy Display Name: §5.1

**Definition.** The per-clinic display string stored in `clinics.white_label_pharmacy_name`.

**Distinction.** It is separate from the externally verified legal identity, the state-routed fulfillment pharmacy, and formula-master naming. Any precedence among those sources must be documented before another hardcoded display name is added.

---

## Naming debts and external verification

1. **Stryker spelling:** product prose uses Stryker Pharmacy; current code strings using Striker Pharmacy require a planned migration.
2. **Pre-doctor intake environment prefix:** `GLP1_*` is internal naming debt and must not narrow the general Pre-Doctor Intake concept.
3. **Legacy lead field:** `public_intakes.triage` remains an internal schema identifier; bare “triage” stays banned.
4. **Health profile collision:** use Health History Questionnaire or Patient Chart Facts explicitly.
5. **Drift namespace:** Drift Layer is the canonical product umbrella, but the current mechanisms have no shared namespace.
6. **Pharmacy presentation:** legal entity, routed pharmacy, and per-clinic display name are separate data sources. Externally verify entity and descriptor claims before publishing them.

---

_Canonical vocabulary for the RonanRx specification suite. Companion documents: business.md, technical.md, database.md, and as-built.md._