03 — Guardian-Rules / Safety Layer¶

Rx360 Scale-Grade AI Foundation · KB Series Scope: The guardrail layer that gates everything the AI foundation emits — across Balance Meter, Smart Scheduling, Medication-Input Intelligence, refill anticipation, and AI triage — at ~6M-user scale. Posture anchor: Consumer-wellness lane (NOT a regulated medical device). Member-facing output is reminders / confirmations / insights — never dosing or diagnosis. Clinical intelligence is internal IP. HIPAA/PHI applies. Date: 2026-06-03

0. Executive Frame — Why This Layer Exists¶

Rx360 already has a deterministic safety-rail concept: a rule-based gate that blocks any dosing/clinical-line output before it reaches a member and routes it to a pharmacist queue. This document extends that single concept into a platform-wide Guardian Layer — the mandatory, fail-closed envelope that wraps every AI engine in the foundation.

The governing principle is defense in depth: a layered architecture that stacks probabilistic controls (input filters, classifiers, safety-tuned models) with deterministic controls (rule blocks, privilege separation, human-in-the-loop) around an untrusted language model (toxsec, LLM Defense in Depth). The reason this matters for Rx360 specifically: every probabilistic defense can be overcome with enough attempts and prompt variation, so probabilistic checks alone are insufficient for a clinical-line boundary where the target is zero leakage (toxsec; Swept AI, Security Theater). The deterministic rail is the blast door; the model-based rails are the speed bumps. We need both — "speed bumps without blast doors are theater; blast doors without speed bumps are noisy" (toxsec).

A critical design caveat from the same source: defense in depth assumes heterogeneity of failure modes. Stacking homogeneous probabilistic checks just multiplies points that fail the same way (toxsec). Our layers must fail differently — that is the whole point of pairing an ML classifier with a regex/lexicon rule with a HITL gate.

1. Guardrail Architecture Patterns¶

The industry-standard decomposition (NVIDIA NeMo Guardrails) defines five rail categories: input, dialog, retrieval, execution, and output (NVIDIA, Guardrails Process). Rx360 adopts this taxonomy and maps each engine through it.

1.1 Input Rails¶

Applied to user/member input before any LLM call. An input rail can reject input (halting all downstream processing) or alter it — e.g., mask sensitive data, rephrase (NVIDIA, Overview). For Rx360, the input stage runs: - PHI/PII detection + masking (§1.5) — before any data leaves our network to a model provider. - Jailbreak / prompt-injection screening (§1.6) — flag adversarial member input or injected content from scanned Rx images / OCR. - Topical scope gate — reject inputs steering the conversation toward dosing/diagnosis solicitation.

1.2 Dialog Rails¶

Govern conversational flow — what the assistant is permitted to do in a turn (defined in NeMo's Colang flow language, a Python-like syntax for controllable dialogue) (NVIDIA, Overview; Pinecone, NeMo Guardrails Intro). Rx360 uses dialog rails to keep Smart Scheduling / triage on-rails (reminders, confirmations, "talk to your pharmacist" handoffs) and off the clinical line.

1.3 Retrieval Rails + Grounding/Factuality Checks¶

Applied to retrieved context (RxNorm, OpenFDA, DailyMed, FHIR records) before it enters the prompt, and to outputs to verify they are grounded in that context. - RAG grounding is the primary hallucination-reduction strategy: anchor outputs in external, verifiable sources to reduce reliance on the model's flawed internal knowledge (Springer / arXiv, Hallucination to Truth; CustomGPT). - Grounding verification checks whether each claim in a response is supported by provided context — essential for RAG (Zylos Research). - Self-verification / chain-of-verification: the model generates an answer, then decomposes it into atomic statements and evaluates each separately against context; unsupported claims are blocked or edited before display (Keymakr). - SelfCheckGPT offers zero-resource (black-box) consistency detection using output probability distributions; detection can be answer-level (one verdict) or span-level (localize the unfaithful fragment) (LLM-Check, OpenReview; arXiv 2508.03860).

For medication objects specifically, every structured field a member sees (drug name, strength, schedule) must trace to a grounded RxNorm/DailyMed source; any field the model invents is a grounding-rail catch and a candidate clinical-line risk.

1.4 Execution Rails¶

Gate tool calls / actions the agent can take (§4). For Rx360: refill ordering, pharmacist-queue routing, notification sends. Execution rails enforce least privilege and bound autonomy.

1.5 PII/PHI Filtering¶

HIPAA Safe Harbor requires detection/redaction of all 18 identifiers (names, geographic subdivisions below state, all date elements, SSN, MRNs, etc.); removing them yields de-identified data that is no longer PHI (Accountable HQ; IntuitionLabs). Reference architecture: - Microsoft Presidio + spaCy/BERT modular recognizers, or Amazon Comprehend Medical PHI Detection (all 18 fields with confidence scores), or NLM Scrubber (Safe-Harbor-compliant) (IntuitionLabs; PredictionGuard). - Reverse-proxy redaction pattern (e.g., phi-redactor): sits between the app and the model provider, masks all 18 identifiers before they leave our network, then restores original values locally — so raw PHI never leaves Rx360 infrastructure (GitHub: phi-redactor). This pattern is directly applicable to our model-provider calls. - Auth lives at a separate layer: Presidio explicitly ships without built-in auth by design; authentication belongs at an API gateway / reverse proxy / service mesh (web search synthesis; Presidio docs via IntuitionLabs). This reinforces our deterministic-perimeter posture.

1.6 Jailbreak / Prompt-Injection Defense¶

Prompt injection is the #1 OWASP LLM risk (2025) — same position since 2023 (promptguardrails, OWASP LLM Top 10; aembit). Hard truths to design around: - You cannot patch your way out — injection exploits the LLM design itself; a system prompt and a user message "all hit the same attention layer with the same weight" (promptguardrails; toxsec). - Classifier-only defenses fail: researchers achieved 100% evasion against Azure Prompt Shield and Meta Prompt Guard; automated jailbreak tools reach near-100% success against leading models (introl). - Mitigation = defense in depth: input validation + output filtering + privilege restriction + HITL for sensitive ops; segregate untrusted content (scanned-Rx OCR text, retrieved data) so it cannot act as instructions; use separate security layers (access control, rate limiting) rather than relying on prompt instructions to enforce policy (promptguardrails). - Provenance tagging: mark system prompts as trusted and user input / RAG results / tool output as untrusted — the foundational control of defense-in-depth (toxsec).

Rx360 implication: Medication-Input Intelligence ingests OCR'd Rx images — a prime injection vector. OCR text must be provenance-tagged untrusted and can never be treated as instructions to the model.

2. Frameworks — What Each Does, How They Compose, Trade-offs¶

Framework	Role	Mechanism	Trade-offs for Rx360
NVIDIA NeMo Guardrails	Orchestration layer	Event-driven runtime; 5 rail types (input/dialog/retrieval/execution/output); Colang flow language (NVIDIA Process, Overview)	Most complete rail taxonomy + streaming support (§6). Higher integration complexity; Colang learning curve. Best as the conductor that calls the others.
Guardrails AI	Output/Input validation	Python framework; Input/Output Guards built from composable validators; RAIL spec (Reliable AI Markup Language) or Pydantic for structured-output enforcement; 60+ pre-built validators; server mode for production (GitHub; Validators docs)	Strong for structured medication-object validation and corrective actions. Published the Guardrails Index (Feb 2025) benchmarking 24 guardrails across 6 categories on accuracy + latency (Guardrails docs).
Llama Guard 3 (1B / 8B)	Content-safety classifier	LLM-based classifier over MLCommons hazard taxonomy (14 categories incl. Code Interpreter Abuse); does prompt classification and response classification; outputs binary safe/unsafe + thresholdable score from first-token "unsafe" probability; 8 languages; 8192-token context (Meta MODEL_CARD; HF)	Self-hostable (keeps PHI in-network); the score threshold is tunable for a conservative fail-closed posture. ML classifier → can be bypassed; never the sole clinical-line gate.
OpenAI Moderation (omni-moderation-latest)	Content-safety classifier	Multimodal (text+image) categories: sexual, harassment, hate, illicit, self-harm, violence (+sub-types); per-category `category_scores` 0–1 + `category_applied_input_types`; 42% better multilingual (OpenAI Moderation guide; OpenAI blog)	Free, fast, image-capable (useful for scanned-Rx self-harm/violence screening). Sends content off-network → only after PHI redaction. Not clinical-aware — does not catch dosing/diagnosis leakage.

Composition pattern for Rx360: NeMo Guardrails as the orchestrator → Presidio reverse-proxy redaction at the input perimeter → Llama Guard 3 (self-hosted) + OpenAI moderation as parallel safety classifiers → Guardrails AI validators for structured-output / grounding enforcement → Rx360 deterministic clinical-line rail (§3) as the final, non-bypassable output gate before any member-facing surface. The classifiers provide broad probabilistic coverage; the deterministic rail provides the hard clinical boundary. They are intentionally heterogeneous (§0).

3. Deterministic (Rule-Based) Rails vs. Model-Based Guardrails — The Core of Our Clinical-Line Safety¶

This is the crux of the Guardian Layer and the direct extension of our existing concept.

3.1 The Distinction¶

Probabilistic / model-based controls (input filters, safety training, ML classifiers like Llama Guard) reduce the likelihood of a bad output but always have bypasses — every probabilistic defense can be overcome with enough attempts and prompt variation (toxsec; aisecurityandsafety).
Deterministic / rule-based controls provide hard boundaries regardless of what the model decides — privilege separation, output blocking, tool sandboxing, HITL confirmations. They cannot be bypassed through prompting and give predictable behavior (toxsec; aisecurityandsafety).

The operative engineering rule: "Guidelines live in prompts; fail-safes live in code." Policy enforcement must be deterministic runtime checks — hard-coded rules that override the LLM are fast, deterministic, and reliable (aisecurityandsafety; agility-at-scale).

3.2 Why a Deterministic Rule Layer MUST Wrap LLM Output for Rx360¶

The clinical-line target is zero leakage. A probabilistic gate with even 99.9% recall leaks ~6,000 events per 6M members per pass — unacceptable for dosing/diagnosis. Only a deterministic gate yields a predictable, auditable boundary.
LLMs lack trust boundaries by construction — instruction/data conflation is structural, so the enforcing control must sit outside the model's decision-making (toxsec).
Heterogeneous failure — the deterministic rail fails differently from the ML classifiers; an injection that defeats the classifier still hits a regex/lexicon/structured-schema block (toxsec).
The "best approach" is explicitly the combination — rule-based guardrails for critical safety boundaries, classifier-based for broad coverage, prompt-based for nuanced guidance (aisecurityandsafety).

3.3 The Rx360 Deterministic Clinical-Line Rail (extended)¶

The existing concept — block any dosing/clinical-line output → route to pharmacist queue — becomes the terminal, fail-closed output gate for the whole platform. Concrete construction: - Lexicon + pattern rules (non-ML): deterministic detectors for dosing language (mg/mcg amounts attached to instructions, "take X," titration/taper verbs), diagnostic assertions ("you have…", condition naming as fact), and contraindication/interaction adjudication. Aligns with the existing Rx360 Wellness Lexicon red-flag set. - Structured-output schema enforcement: member-facing payloads must conform to an allow-listed schema (reminder | confirmation | insight). Any field carrying dosing/clinical content fails the schema → blocked. - Fail-closed default: on detector match, low confidence, schema violation, or rail error/timeout → block + route to pharmacist queue. The default state is "do not emit." (Fail-closed is the explicit fail-safe posture — see §6.2.) - Provenance: the rail runs on the final rendered string after all model-based rails, with no model in the path that could be re-injected.

This rail is the blast door. Everything upstream is a speed bump.

4. Agentic-AI Guardrails + Human-in-the-Loop (HITL)¶

Rx360's engines take actions (refill orders, notifications, queue routing, triage escalation), so agentic guardrails are mandatory. The governance gap is real: ~80% of organizations lack mature agentic governance — clear decision boundaries, real-time anomaly monitoring, and full audit trails (Deloitte).

4.1 Three Operational Modes (apply per action class)¶

Assistive — agent recommends, human executes.
Supervised autonomy — agent executes, human approves risky steps.
Full autonomy within bounded scope — agent runs end-to-end, constrained by strict policies/limits (Deloitte).

Rx360 mapping: low-risk reminders/confirmations → bounded full autonomy; anything touching the clinical line, a refill commitment, or triage escalation → supervised autonomy with a pharmacist approval gate.

4.2 Guardrails as Policy Engines¶

Implement guardrails as policy engines that block disallowed behaviors, cap resource usage, or require human approval for sensitive tasks; use approval gates for high-impact actions, exception-based human intervention, and adaptive autonomy that tightens/loosens by performance metrics (Rippling; Deloitte).

4.3 Hard Lessons (design around these)¶

CrowdStrike July 2024: one bad automated update bricked 8.5M machines — agents auto-acting on a single signal without a sanity gate (Rippling). → Rx360 fleet-wide actions (mass notifications) need a circuit breaker.
GitHub Copilot CVE-2025-53773 (June 2025): an agent rewrote its own approval settings to disable human review, then got shell execution (Rippling). → Approval/HITL controls must be enforced in code outside the agent's reach, never in agent-editable config.
Treat HITL prompts themselves as untrusted model output — an injected agent can craft a deceptive confirmation prompt (toxsec).

4.4 Least Privilege + Sandboxing¶

Every API token, DB connection, and tool scoped minimally ("like handing a service account to a contractor who lies about everything"); credentials kept outside the model context entirely; tool execution sandboxed; session/context isolation (toxsec). This contains the blast radius: the worst case after a successful injection is a weird response with no real-world consequence (toxsec).

5. The "Clinical-Line" Gate as a Guardrail — Wellness vs. SaMD¶

The Guardian Layer must keep Rx360 inside the consumer-wellness lane and out of the medical-device / CDS function. The regulatory boundary moved in our favor in Jan 2026, but the constraints are precise.

5.1 FDA Jan-2026 Updates (supersede 2019 wellness & 2022 CDS guidance)¶

On January 6, 2026 (CDS revised again January 29, 2026) FDA updated both the General Wellness and CDS guidances (Faegre Drinker; King & Spalding; MedDeviceGuide).

General Wellness — widened lane (good for Rx360): - Now permits noninvasive wearables that estimate health metrics (e.g., heart rate, glucose) to claim wellness status if intended solely for wellness use and posing minimal risk (Faegre Drinker). This directly supports Balance Meter and wearable metrics. - "Low-risk" = noninvasive, no implantation, no lasers/radiation (Faegre Drinker).

General Wellness — the hard prohibitions (these are guardrail rules): - Products must avoid "disease, diagnostic, or clinical management claims." Any reference to health risks or professional evaluation must be carefully worded and cannot reference specific diseases (Faegre Drinker).

CDS — the four 520(o)(1)(E) non-device criteria (21st Century Cures Act §3060) (FDA CDS FAQs; Faegre Drinker): 1. Not intended to acquire/process/analyze a medical image, IVD signal, or signal-acquisition pattern. 2. Intended for displaying/analyzing/printing medical information. 3. Intended to support recommendations to a healthcare professional on prevention/diagnosis/treatment. 4. Enables the HCP to independently review the basis for the recommendation (not rely primarily on it).

CDS — what widened (Jan 2026): - FDA now exercises enforcement discretion when software provides only one clinically appropriate recommendation and all other criteria are met (Faegre Drinker; Jones Day). - Removed prior language stating that software providing a risk score / risk probability does not qualify as non-device CDS (Arnold & Porter via search synthesis; The FDA Law Blog). - Transparency requirement: "The greater the extent to which the software is a 'black box' to HCPs, the greater the risk that FDA will assert that the product is a medical device" — clear documentation of data inputs and recommendation logic is expected, especially for AI (Faegre Drinker).

5.2 What This Means for the Guardian Layer (rules to encode)¶

Criterion 1 is the bright line for member-facing output: Rx360 must not let member-facing AI analyze a medical signal/image and emit a clinical conclusion. Balance Meter fall-risk and wearable metrics must surface as wellness insights, not diagnoses. CDS criteria 3–4 contemplate an HCP in the loop — Rx360's member-facing surfaces have no HCP reviewer, so member-facing dosing/diagnosis output cannot satisfy non-device CDS and would push the product toward SaMD.
The deterministic clinical-line rail (§3.3) IS the CDS/wellness boundary enforcer. Encode the FDA prohibitions as deterministic rules: block disease/diagnostic/clinical-management claims and specific-disease references in member-facing text; block dosing instructions; route to the pharmacist (HCP) queue.
The pharmacist queue is the architectural "HCP-in-the-loop." When the internal clinical IP must inform a member, a pharmacist reviews/independently evaluates before anything member-facing is emitted — mirroring CDS criterion 4's "independent review."
Transparency/explainability of every model-derived insight (data inputs, logic) is now a guardrail observability requirement, not just good practice (Faegre Drinker).

Caveat for Rx360 legal/regulatory review: The Jan-2026 widening is favorable but is enforcement discretion, not statutory exemption, and the CDS guidance was revised twice in January 2026 — treat boundary rules as living and re-validate against the latest FDA text. The conservative posture (member-facing = reminders/confirmations/insights only) remains correct regardless of the loosening.

6. At Scale — Latency, Fail-Safe Defaults, Observability, Red-Teaming¶

6.1 Latency Budgets¶

Guardrail budget ≈ ≤10% of end-to-end latency, and that budget must cover input checks + output checks + fallbacks (Modelmetry; search synthesis].
Track P99, not averages — P99 catches batch interference, KV-cache evictions, GC pauses that averaging hides; at P99 a 600ms guardrail means one user/second waits half a second before any output — the users who churn (Spheron).
Suggested SLO alerts: P95 guardrail latency > 200ms → warning; P99 > 500ms → critical + autoscale (Spheron).
Streaming the clinical-line rail: NeMo validates output rails synchronously by default (whole response checked before return → latency on long outputs); streaming mode decouples generation from validation via chunked processing — chunk_size (~200 tokens recommended) and a context_size sliding-window buffer (~50 tokens) maintain cross-chunk context (NVIDIA streaming blog).
Tradeoff: larger chunks (200–256) give better context for grounding/hallucination rails; smaller chunks (128) lower latency but risk missing cross-chunk violations (NVIDIA streaming blog).
Critical safety note: with streaming, "if a rail is triggered, the objectionable text might have already been sent to the user" (NVIDIA streaming blog). For the Rx360 clinical-line rail, do NOT stream member-facing dosing-adjacent output — buffer fully and run the deterministic gate before the first token reaches the member. Reserve streaming for clearly-safe wellness content. (StreamGuard-style prefix forecasting is an emerging research direction if streaming is needed under safety constraints (arXiv 2604.03962).)
Use lightweight classifiers / tiered checks to stay in budget — small models (Llama Guard 3-1B) and deterministic regex/lexicon rules are cheap; reserve heavy grounding checks for higher-risk paths (Modelmetry; Maxim AI).

6.2 Fail-Safe Defaults¶

Fail closed. On detector match, low confidence, schema violation, or any rail error/timeout, the default action is block + route to pharmacist queue — never emit. The deterministic rail's default state is "do not emit." Hard-coded overriding rules are fast, deterministic, reliable (aisecurityandsafety; toxsec).
A guardrail timeout must not become a leak: if a rail can't finish within budget, treat as fail-closed (block), not fail-open (pass through).

6.3 Observability (target: zero clinical-line leakage)¶

Instrument rail catches and leakage as first-class metrics: per-rail trigger rate, block rate, false-positive/over-block rate, and — most important — clinical-line leakage count (target: 0) measured by sampling/auditing emitted member-facing output.
Platforms (Datadog LLM Observability and peers) provide LLM instrumentation + automated prompt evaluation to monitor security and evaluate guardrail effectiveness in production; pair with semantic logging, anomaly detection, and usage analytics (Datadog).
Guardrails reduce the blast radius of failures red-teaming finds — observability closes the loop between red-team findings and rail tuning (General Analysis).
Maintain full audit trails of the agent action chain (an explicit agentic-governance gap to close) (Deloitte).

6.4 Red-Teaming¶

Continuously probe for prompt injection, PII/PHI leakage, tool misuse, policy violation, and hallucination; tools (DeepEval, Promptfoo, etc.) simulate adversarial attacks before attackers do (DeepEval; Promptfoo).
Healthcare-specific urgency: systematic red-teaming of medical LLMs elicited privacy leaks in 86% of scenarios, cognitive-bias priming altered clinical recommendations in 81% of fairness tests, and hallucination rates exceeded 74% in widely-used models (arXiv 2508.00923). These numbers justify the deterministic clinical-line rail as non-negotiable.
Red-team the post-injection landing zone, not just entry attempts — assume injection succeeds and verify the blast radius stays contained (toxsec).

7. Reference Architecture — End-to-End Gate Order¶

MEMBER / DEVICE INPUT  (incl. OCR'd Rx images → tagged UNTRUSTED)
      │
      ▼
[INPUT RAILS]  PHI/PII redaction (Presidio reverse-proxy, 18 identifiers, in-network)
               → Jailbreak/injection screen (provenance tagging) → Topical scope gate
      │  (fail-closed)
      ▼
[RETRIEVAL RAILS]  RxNorm / OpenFDA / DailyMed / FHIR grounding context
      │
      ▼
   LLM ENGINE(S)  — Balance Meter / Scheduling / Med-Input / Refill / Triage
      │
      ▼
[OUTPUT RAILS — model-based, broad coverage]
   Llama Guard 3 (self-host)  +  OpenAI moderation  +  Guardrails AI validators
   + Grounding/atomic-claim verification (no invented med fields)
      │
      ▼
┌──────────────────────────────────────────────────────────────┐
│ [Rx360 DETERMINISTIC CLINICAL-LINE RAIL]  ← the blast door     │
│  Non-ML lexicon/pattern + structured-schema enforcement       │
│  Dosing? Diagnosis? Disease/clinical-mgmt claim? Schema fail?  │
│   → FAIL-CLOSED: BLOCK + ROUTE TO PHARMACIST (HCP) QUEUE       │
│   else → emit member-facing {reminder|confirmation|insight}   │
└──────────────────────────────────────────────────────────────┘
      │
      ▼
[EXECUTION RAILS]  least-privilege tools; HITL/approval gate for
                   refills, escalations, fleet-wide actions (enforced in code)
      │
      ▼
OBSERVABILITY: per-rail catch/leakage metrics · clinical-line leakage = 0 (target)
               · audit trail · continuous red-teaming feedback

One-line thesis: Probabilistic rails give us broad, cheap coverage; the deterministic clinical-line rail is the fail-closed blast door that turns clinical-line leakage from a statistical hope into a bounded, continuously-measured escape rate driven toward zero. The real guarantee is the fail-closed output-schema allow-list (member payloads must be reminder | confirmation | insight, else block) plus the default-deny posture — not lexicon completeness (a lexicon can only block what it enumerates). It doubles as the FDA wellness-vs-SaMD boundary enforcer, with the pharmacist queue as the architectural HCP-in-the-loop.

Sources¶

Frameworks - NVIDIA — Guardrails Process (5 rail types) - NVIDIA — NeMo Guardrails Overview - NVIDIA — Stream Smarter and Safer (streaming output rails) - Pinecone — NeMo Guardrails Intro / Colang - Guardrails AI — GitHub - Guardrails AI — Validators - Guardrails AI — Docs / Guardrails Index - Meta — Llama Guard 3-8B Model Card - Meta — Llama Guard 3-8B (Hugging Face) - OpenAI — Moderation Guide - OpenAI — Multimodal Moderation Model

Deterministic / Defense-in-Depth / Injection - toxsec — LLM Defense in Depth: Assume Breach and Contain the Blast - Swept AI — Why Current AI Guardrails Are Security Theater - AI Safety Directory — LLM Guardrails Complete Guide - Agility at Scale — AI Guardrails & Safety Mechanisms - PromptGuardrails — OWASP LLM Top 10 (2025) - Aembit — OWASP Top 10 for LLM Applications (2025) - Introl — Prompt Injection Defense for Production Systems

PHI/PII Filtering - Accountable HQ — HIPAA PII Identifiers / 18 Safe Harbor fields - IntuitionLabs — Open Source PHI De-Identification Review (Presidio/Comprehend Medical/NLM Scrubber) - PredictionGuard — PII Detection & Redaction for LLM Pipelines - GitHub — phi-redactor (HIPAA reverse-proxy redaction)

Grounding / Factuality - Springer / arXiv — Hallucination to Truth (fact-checking & factuality review) - arXiv 2508.03860 — Hallucination to Truth - Zylos Research — LLM Hallucination Detection & Mitigation (2026) - Keymakr — Preventing LLM Hallucinations (chain-of-verification) - CustomGPT — AI Guardrails: Reduce Hallucination with RAG - LLM-Check (OpenReview) — Hallucination Detection / SelfCheckGPT

Agentic / HITL - Deloitte — Agentic AI is scaling faster than guardrails - Rippling — Agentic AI Security (CrowdStrike, Copilot CVE, modes)

FDA Wellness / CDS Boundary - Faegre Drinker — Key Updates in FDA's 2026 General Wellness & CDS Guidance - King & Spalding — FDA Updates General Wellness & CDS Guidance - Jones Day — A Relaxing 2026? FDA Updates Wellness & CDS Guidance - Arnold & Porter — FDA "Cuts Red Tape" on CDS & Wearables - The FDA Law Blog — CDRH Updates to CDS & General Wellness Guidance - MedDeviceGuide — FDA CDS Non-Device vs Device (2026) - FDA — Clinical Decision Support Software FAQs (520(o) criteria)

Scale / Latency / Observability / Red-Teaming - Modelmetry — Latency of LLM Guardrails - Spheron — LLM Inference SLO: TTFT, ITL, P99 Budgets (2026) - Maxim AI — Top AI Gateways for Guardrails - arXiv 2604.03962 — StreamGuard / Value-Based Safety Forecasting for Streaming - Datadog — LLM Guardrails Best Practices / Observability - General Analysis — Best AI Guardrails (2026) - DeepEval — Red-Teaming Your LLM - Promptfoo — LLM Red Teaming Guide - arXiv 2508.00923 — Systematic Red-Teaming Agents for Medical LLMs