Internal Deep-Dive · v1.0 · 2026-05-13 · For Rick, Leona, Brian, Daniel

How Praxis builds prompts
that hold up in medicine.

VITALS is a six-dimension prompt grammar built only for medicine. Citation discipline, regulatory awareness, and safety guardrails are baked into the prompt structure, not bolted on as disclaimers. This page walks through every dimension, every template we ship, every defense we have wired, and what each of them means for the clinicians who will use it.

Six dimensions · Four specialty templates · Six platform formatters · Zero PHI in the engine

VITALS v1.0 Gemini 2.5 Flash + Pro Pure-Code Templates HIPAA Training Carve-Out Non-Device CDS Posture
Module 01 · Why VITALS Exists

Existing prompt frameworks were not built for medicine.

The popular prompt frameworks circulating online (CO-STAR, RICE, CRISPE) were designed for marketing copy, coding tasks, and general business writing. None of them encode citation discipline. None encode FDA or HIPAA posture. None encode scope-of-practice declarations. When a clinician uses one of those frameworks to draft a prior-auth letter or a patient handout, the AI confidently fabricates citations and crosses scope-of-practice lines.

How to read this: VITALS is not a rebrand of CO-STAR or RICE. It is a medical-only prompt grammar designed from the ground up. Each of the six dimensions carries a load-bearing requirement that exists because medicine demands it (evidence anchoring, regulatory awareness, role specificity, safety guardrails). The name "VITALS" is a clinical mnemonic that does no work in any other vertical, and that is the point.

Editorial illustration of a clinician's reference bench: medical textbooks open to anatomical plates, a six-category index card, a modern laptop kept secondary to the printed references
What goes wrong without VITALS
Hallucinated citations

Multiple peer-reviewed studies through 2023 and 2024 have documented material inaccuracy rates in unguided medical chatbot output. The fabrications are not random. They are confident, plausible, and untraceable. A clinician using one of those outputs in an appeal letter, a patient handout, or a discharge summary carries the malpractice exposure, not the AI vendor. Specific citations are listed in the VITALS framework spec, currently in fact-checker review per SynthesisArc evidence protocol.

What changes with VITALS
Workflow-ready artifacts

Structure is not a stylistic choice in medicine. It is the difference between a usable artifact a clinician can hand to a patient or a payer and a wall of text that has to be rewritten before it can be used. Clinical informatics literature has documented efficiency gains from structured AI outputs in real workflows.

Why existing frameworks fail for high-stakes medical work
Framework What it's good at Why it fails for medicine VITALS advantage
CO-STAR Marketing copy, easy to teach No regulatory awareness, no evidence anchoring, no safety dimension Built for high-stakes work from the ground up
RICE Sparse, fast to write Missing safety, missing regulatory, missing adversarial thinking Adds three load-bearing medical dimensions
CRISPE Good for exploration "Experiment" is wrong for clinical work. We do not experiment with patient outputs. Replaces "Experiment" with "Safeguards"
Chain-of-Thought Reasoning quality Technique, not framework VITALS uses Chain-of-Verification inside V (Verify)
ReAct Tool use plus reasoning Technique, not framework VITALS uses ReAct patterns inside T (Task)

What this means for you: Leona, Brian, Rick, every prompt your team writes from this point forward can be VITALS-engineered. The framework forces the discipline so the clinician does not have to remember every guardrail manually. You write a description of what you need, you pick the AI platform you want to use, and you get back a prompt that already encodes the evidence anchoring, the scope-of-practice declaration, the regulatory posture, and the safety guardrails. You copy it. You use it in your AI tool of choice. The clinician judgment stays with you, the structural discipline comes from us.

Strategic Signal

VITALS is the only prompt framework whose six dimensions all encode medical-specific load-bearing requirements. That is the positioning moat. We are not borrowing a marketing acronym and pretending it fits medicine. We built the framework because the framework had to exist for the product to be defensible.

Module 02 · The Six Dimensions

V · I · T · A · L · S

Six dimensions, each named after one load-bearing requirement of medical writing. The acronym is intentional: VITALS is the most familiar clinical mnemonic for a reason, and the framework treats prompt structure with the same discipline a nurse treats vital signs.

How to read this: each card below is one dimension. Modules 03 through 08 below this section go deep on what each one encodes, the failure mode if it is missing, and a real example fragment. Skim this section first. Then drop into the dimensions you care most about.

Module 03 · V — Verify

Every claim cites a real, named primary source.

Verify is the dimension that prevents confident hallucination. Every clinical claim in a VITALS prompt is paired with a named primary source, a publication year, and a DOI / PMID / verifiable URL. Chain-of-Verification is built into the prompt itself: draft an answer, generate three verification questions about the strongest factual claims, answer each independently from the cited sources, then regenerate the final answer.

How to read this: the example fragment below is what gets injected into the Verify section of a real prior-authorization prompt for a semaglutide appeal. Notice the three citations are real, current, and traceable. There are no "studies show" without naming the study, no homepage-fallback URLs, no folklore statistics.

Real Verify fragment, from the prior-authorization template
[V] Verify against: ADA Standards of Care 2024 §10.3 (DOI: 10.2337/dc24-S010,
published Jan 2024); SUSTAIN-6 pivotal trial (NCT01720446, NEJM 2016);
Cochrane review on GLP-1 for T2DM (CD012763, updated 2023).

If guideline contradicts trial, surface both with dates.
If no evidence in the last 5 years on a claim, state "evidence stale" explicitly.

Chain-of-Verification: after draft, generate three verification questions about
the medical-necessity claim, answer each from the cited sources, regenerate only
after each verification step passes.
Failure mode if missing

The AI fabricates a citation that sounds plausible. The clinician submits the appeal letter citing a study that does not exist. The payer rejects on procedural grounds. Worse, malpractice exposure if the fabricated citation influenced the clinical decision.

What Verify prevents

Verify materially reduces fabrication risk by anchoring every claim to a named, current, traceable source AND forcing the model to self-verify before output. The clinician can audit every claim in seconds because every claim is paired with a real DOI, PMID, or canonical URL they can open in a new tab.

What this means for you: Leona, when you review a VITALS-generated appeal letter, you can audit every clinical claim in under 60 seconds because every claim is paired with a real DOI you can open in a new tab. Brian, when you forward one of these prompts to a colleague, you are forwarding something that will not embarrass either of you under scrutiny. Rick, when MRP ships content that touches a clinical claim, this is the gate. No claim ships without a named source.

Module 04 · I — Indications

Role plus intended use plus de-identified context.

Indications locks the regulatory posture at the top of every prompt. The clinician's role (MD, DO, NP, PA, RN, MA, non-clinical staff) is declared explicitly. The FDA "intended use" language is borrowed directly from SaMD vocabulary so the regulatory framing is unambiguous. Patient context is de-identified by design, the engine never sees PHI.

How to read this: "Intended use" is not marketing copy. It is FDA regulatory language that signals exactly what the output is and is not. When a clinician declares "intended use: drafting a prior-authorization appeal letter (administrative writing). Not diagnosis. Not treatment recommendation," that single line tells counsel, FDA reviewers, and downstream auditors what the scope of the output actually is.

Real Indications fragment
[I] Acting as: Family Medicine MD, US jurisdiction.

Intended use: Drafting a prior-authorization appeal letter (administrative writing).
Not diagnosis. Not treatment recommendation. Not medication recommendation.

Patient context (de-identified): 47yoF, T2DM 8yr, A1C 8.4 on metformin + lifestyle.
Failed: glipizide (hypoglycemia), sitagliptin (no response). Comorbid HTN.

Scope-of-practice: Letter authored within scope of prescribing clinician's licensure.
Failure mode if missing

Outputs cross scope of practice without the author realizing it. An NP-authored prompt produces MD-scope content. Role-mismatch errors compound across the patient encounter, the documentation, and the audit trail. Scope-of-practice violations also surface in licensure reviews and disciplinary actions, especially in states with strict collaborative-practice rules.

What Indications prevents

The "intended use" declaration locks the regulatory posture so counsel review is fast. The de-identified patient context means no PHI ever enters the engine, which keeps the entire product line in HIPAA's training and education carve-out (what we call Lane 3 GREEN internally) by design, not by post-hoc redaction.

What this means for you: Brian, when an NP on your team uses the engine, the prompt declares "Acting as: NP" and the output respects NP scope. When you use it, the prompt declares "Acting as: MD" and the output operates at MD scope. The same engine produces different outputs depending on the role declared, because that is what scope of practice actually requires.

Module 05 · T — Task

One workflow task. One artifact. Specified down to reading level.

Task forces the prompt to produce an artifact a clinician can submit, sign, file, or hand off. Not an essay. Not a wall of text. The output type, the format, the length, the reading level, and the delivery medium are all named explicitly. A patient handout is 8th-grade reading level and ends with a "when to call us" red-flag section. An SBAR handoff is clinician-technical and read-aloud-friendly. A payer appeal letter is one page, compliance-flavored, signed.

How to read this: the example below is from a payer appeal. Notice "1-page max", "header block then 3 body paragraphs then citation footer then signature block", and "Payer compliance language, technical, not narrative." Every constraint is stated explicitly so the AI cannot produce a wandering essay.

Real Task fragment, prior-authorization template
[T] Task: Draft a prior-authorization appeal letter to the insurance payer.

Output type: Formal letter, 1-page max, addressed to payer medical director.
Format: Header block (patient ID placeholder, dates, provider NPI), 3 body paragraphs
(clinical history, prior failures with dates and adverse events, guideline citation),
citation footer, signature block.
Length: 350-500 words body, excluding header and footer.
Reading level: Payer compliance language (technical, not narrative).
Delivery medium: Mail or fax plus payer portal upload. Letter must work in all three.
Why structure matters in clinical workflow

Task is the dimension that produces structure. A wall-of-text essay is not just unhelpful, it is operationally a tax. Every minute spent rewriting an unusable AI output is a minute the clinician is not seeing patients or doing the documentation that has to ship. Structured outputs match the workflow; unstructured outputs become rework.

What this means for you: When you ask the engine for "a patient handout," you get a one-page handout written at the right reading level with a "when to call us" red-flag list at the bottom. When you ask for "an SBAR handoff," you get Situation / Background / Assessment / Recommendation, in that order, read-aloud-friendly. The output type matches the workflow, not the AI's idea of what a "comprehensive response" should look like.

Module 06 · A — Adversarials

Pre-mortem the failure modes before the output ships.

Adversarials is the dimension that distinguishes VITALS from every other prompt framework on the market. Before the AI generates the output, the prompt forces it to identify the most dangerous misreading, the most likely scope-of-practice violation, and the most likely counsel objection. Then it forces a self-critique pass: after drafting, identify the weakest paragraph and rewrite it before final output.

How to read this: Adversarials was Gemini 2.5 Pro's unique contribution during CHORUS synthesis. None of the existing frameworks have anything like it. The closest analog is "red team review" as a separate step after writing. VITALS bakes it into the writing itself, so the output cannot ship without addressing the failure modes.

Real Adversarials fragment
[A] Adversarials: Before generating, address:

- Most dangerous misreading: "This letter guarantees the appeal will succeed."
  Mitigation: Explicit footer disclaimer plus no guarantee language anywhere in body.
- Most likely scope creep: Recommending a specific drug brand by trade name.
  Mitigation: Cite drug class plus ADA guideline reference, not brand.
- Most likely counsel objection: "Patient details are identifiable."
  Mitigation: This is a de-identified template; customization happens at clinician's desk.

After draft, critique it. Patch weak points before final output.
Origin credit

Adversarials emerged from a multi-model synthesis (CHORUS) during VITALS framework design. Each contributing model's distinct contribution is documented in the internal framework spec. The framework is a real synthesis of multiple AI perspectives plus the SynthesisArc team, with attribution captured at the spec level rather than the public page.

What this means for you: Brian, Adversarials surfaces predictable failure modes inside the prompt itself so the clinician sees them before signing the artifact. The model is forced to identify and patch its own weakest paragraph before final output. This is structural discipline, not legal protection, and the clinician judgment still owns the final word.

Module 07 · L — Limits

HIPAA, FDA, jurisdiction. Declared at the top.

Limits encodes the regulatory posture. Every VITALS prompt declares its HIPAA mode (training and education carve-out, no PHI in the engine, no BAA invoked), its FDA posture (non-device clinical decision support per 21st Century Cures Act §3060, explainable and non-reliance), its US jurisdiction, and its non-US flag for any international deployment.

How to read this: Limits is what makes Praxis ship-able today instead of in twelve months. By explicitly declaring the regulatory envelope at the top of every prompt, counsel review is fast and FDA exposure is materially reduced. The engine cannot easily drift into SaMD territory because every prompt re-asserts the non-device CDS framing. Counsel review still happens per template; the framing makes that review tractable rather than open-ended.

Real Limits fragment
[L] HIPAA: Training and education carve-out. No PHI in prompt or output. No BAA in v1.

FDA: Non-device CDS per 21st Century Cures Act §3060, explainable, non-reliance.
This prompt does NOT generate clinical decision support that would substitute
for clinician judgment.

Jurisdiction: US. State board: <state medical board>.
Non-US flag: For deployment outside US, evaluate against EU MDR Rule 11
(software as medical device), UK MHRA Change Programme, Health Canada SaMD guidance.
Why we stay outside the PHI envelope

Healthcare data breaches are among the most expensive in any industry (IBM's annual Cost of a Data Breach Report has put healthcare materially above the cross-industry average for over a decade). Limits is the dimension that keeps every VITALS-generated artifact firmly outside the BAA-required and breach-reporting envelopes. PHI never enters the engine. The clinician customizes at the EHR or letter level, locally, where the existing HIPAA-compliant infrastructure already handles PHI.

What this means for you: Rick, this is why we can ship Tier 1 Prompt Packs today instead of waiting six months for a BAA stack and an FDA pre-submission. Limits keeps the entire product line in the GREEN zone (training and education carve-out, non-device CDS, no PHI). Tier 3 AI Pilot is a separate product with its own regulatory posture, but VITALS-via-Praxis ships free and clear.

Module 08 · S — Safeguards

Escalation, never-do, uncertainty, drug safety, audit trail.

Safeguards is the catastrophic-outlier prevention dimension. Every prompt encodes explicit escalation rules (acute symptoms route immediately to clinician handoff), a Never-X list (never diagnose, never prescribe a specific drug or dose, never claim MD equivalence), an uncertainty rule (below 80% confidence, say so explicitly instead of guessing), drug-safety cross-checks against DailyMed and Drugs@FDA, and an audit trail tying every output to a hash, timestamp, and clinician role.

How to read this: AI safety failure rates in unguarded clinical prompts are well-documented in the clinical informatics literature. Safeguards materially reduces that risk by making every prompt re-assert the rules at the point of generation. The Never-X list in particular is the line we do not cross, ever, and the audit trail is the receipts when something later needs review.

Real Safeguards fragment
[S] Safeguards:

- Escalation: If acute presentation or suicidality, immediate clinician handoff.
- Never-X: Never diagnose. Never prescribe a specific drug or dose.
  Never claim equivalence to MD. Never tell a patient to ignore another clinician.
- Uncertainty: If under 80% confidence on any claim, state "insufficient evidence."
- Drug safety: Cross-check against DailyMed (https://dailymed.nlm.nih.gov/)
  and Drugs@FDA before referencing any medication.
- Footer disclaimer: "Template language. Customize per patient. Human review required."
- Audit: This prompt logged with hash, timestamp, clinician role, output diff.
  Retained 7 years per HIPAA conservative policy.
Pediatric flag

If patient context indicates under 18 years old, every template requires explicit pediatric-dosing review even for educational material. Adult assumptions break in pediatrics, every time.

Geriatric flag

If over 65, Beers Criteria check is mandatory. Polypharmacy flag triggers automatically at five or more medications.

Audit retention

Every generated artifact is hashed and logged for 7 years per HIPAA conservative policy. The final-edited version is the source-of-truth, not the engine draft.

What this means for you: Leona, you can hand the engine to a new nurse on day one and the output will not give clinical advice it should not give, will not skip the read-back step on a nurse-to-MD update, and will not generate medication content from scratch (it cross-references DailyMed instead). Safeguards is the dimension that makes VITALS deployable across a team without weeks of training, because the guardrails live in the prompt, not in the operator's memory.

Module 09 · The Authoring Engine

From request to ready-to-copy prompt in under 3 seconds (or 20 for novel specialties).

The Praxis VITALS Prompt Engine is a four-stage pipeline. Most of it runs as pure server-side code, which means most requests come back in under 3 seconds. Only two stages involve an AI call: the intent classifier (catches extraction attempts) and the LLM fallback (generates specialty-tailored prompts when no pre-built template matches).

How to read this: read each stage left to right. The pure-code stages are the moat. The framework templates, the dimension generators, the platform formatters, none of them are ever sent to an AI in the production path. That is what makes the engine defensible against reverse engineering even though it is publicly accessible.

Editorial illustration: a multi-AI architecture with code mediating between specialty templates and the user, the VITALS engine pipeline visualized
STAGE 1
Intent Classifier
Engine: Gemini 2.5 Flash Lite
Cost: ~1-3s, fractions of a cent per call

Decide if the request is legitimate medical writing OR an extraction attempt (someone trying to get the framework out). Extraction attempts hit a canned refusal. Legitimate requests continue.

STAGE 2
Template Select
Engine: Pure server-side code
Cost: Instant (under 1ms)

Score the request against the four specialty templates we ship. Multi-word phrase matches beat single-word noise. A novel-specialty signal (e.g., "Dermatology MD") disqualifies family-medicine and nursing-handoff and routes to the LLM fallback.

STAGE 3a
Dimension Fill (template)
Engine: Pure server-side code
Cost: Instant

If a specialty template matched, the template builds all six VITALS dimensions programmatically from the request. No LLM in this path.

STAGE 3b
Dimension Fill (LLM fallback)
Engine: Gemini 2.5 Pro
Cost: ~15-20s per call, a few cents

If no specialty template matched and the user named a novel specialty (dermatology, pediatrics, cardiology, oncology, etc.), Gemini 2.5 Pro authors a tailored VITALS prompt with real specialty-society citations. Pure-code static fallback runs if Pro is unreachable, so the engine never blocks a user.

STAGE 4
Platform Formatter
Engine: Pure server-side code
Cost: Instant

Wrap the six dimensions in the chosen platform's preferred shape: Claude gets XML, ChatGPT gets markdown with chain-of-thought framing, Gemini gets JSON schema, Copilot gets compressed and trigger-phrase substituted, Grok gets CAPS and real-time framing, generic gets conservative markdown.

STAGE 5
Sanitizer
Engine: Regex (server-side)
Cost: Instant

Strip system-prompt-leakage patterns ("you are an AI...", "follow these rules...") and any engine-internal metadata that should never reach the user. Last gate before the prompt goes back over the wire.

The defense, in one sentence

The VITALS framework instructions never reach a user-facing LLM in the production path. Only the small intent classifier sees user input, and it sees only the classifier prompt plus the user's free text, never the framework. Everything else is pure server-side code: template selection, dimension filling, adversarials, platform formatting, sanitization.

What this means for you: Daniel, the architecture matches what we discussed in the noon sync setup, with Pro reserved for the fallback path and the moat kept in pure code. Rick, this is why we can show the engine to anyone, including competitors, without giving away the framework. Brian, this is why latency is fast: the four pre-built templates return in under 3 seconds because no AI is in the path, and only novel specialties trigger the slower (15 to 20 second) Pro fallback.

Module 10 · Specialty Templates Shipped

Four templates, each tuned to its specialty.

We shipped four specialty templates in v1. Each one implements the full VITALS structure, but the citations, the sub-tasks, the safety triggers, and the scope-of-practice envelopes are tuned to the specialty. When a request matches a template, the engine returns in under 3 seconds with a fully-tailored prompt. When a request names a specialty we have not pre-built (dermatology, pediatrics, cardiology, etc.), the engine falls through to Gemini 2.5 Pro to generate a tailored prompt for that specialty on demand.

How to read this: each card below is one shipped template. "Specialty" tells you what scope of practice the template covers. "Sub-tasks" tells you how many distinct workflows it handles. "Moat" tells you what makes this template more than a generic VITALS scaffold, the specialty-specific intelligence we baked in.

Prior Authorization Appeal
id: prior-auth-appeal

Specialty: Cross-specialty (any prescribing clinician)

Serves: Physicians, NPs, PAs, practice managers, billing coordinators

Sub-tasks: One artifact: a payer-ready appeal letter

Citation hierarchy: ADA / AAFP / specialty-society guideline of the drug class · pivotal trial registry + journal · Cochrane review · UpToDate

The moat

Dynamic citation routing: if the patient context mentions a specific drug (semaglutide, dupilumab, apixaban, etc.) the template swaps in that drug's actual pivotal trial and society guideline. If the drug is unknown, it leaves a flagged callout for the clinician to verify before submission.

Family Medicine General Workflow
id: family-medicine

Specialty: Family medicine, primary care

Serves: MD, DO, NP, PA, RN, medical assistant

Sub-tasks: Five sub-tasks: patient education handout, SBAR handoff, post-visit summary, differential discussion scaffold, general visit prep

Citation hierarchy: USPSTF Grade A/B · AAFP · ADA · ACC/AHA · APA · UpToDate · MedlinePlus for patient-facing materials

The moat

Sub-task auto-detection from keyword routing. The template reads the request and routes to the right sub-task before generating, so a "patient handout" request gets 8th-grade reading level and a red-flag call-us section, while an "SBAR handoff" gets clinician-technical Situation-Background-Assessment-Recommendation structure.

Medical Front Desk
id: front-desk

Specialty: Office administration (Lane 3 GREEN, zero clinical content)

Serves: Receptionists, schedulers, billing coordinators, medical assistants, office managers

Sub-tasks: Seven sub-tasks: appointment reminders, recall letters, no-show follow-ups, reschedule notices, new-patient intake, referral coordination, payment reminders

Citation hierarchy: Practice cancellation policy · HIPAA Privacy Rule §164.522 (right to confidential communications) · MGMA / AAFP practice-management style guides

The moat

Strict no-clinical-content rule. If the request implies clinical content, the template refuses and routes to the nurse queue instead of generating. TCPA + FDCPA + HIPAA-tangent guardrails baked into the prompt body.

Nursing Handoff Communication
id: nursing-handoff

Specialty: Nursing (hospital + ambulatory)

Serves: RN, LPN, LVN, charge nurse, nurse manager

Sub-tasks: Eight sub-tasks: SBAR shift change, ISBARR extended, ED-to-floor transfer, ICU transitions, discharge handoff to home health or SNF, nurse-to-MD update, bedside report, general

Citation hierarchy: AHRQ TeamSTEPPS · The Joint Commission NPSG.02.03.01 · IHI handoff communication tools · ANA Scope and Standards of Practice · AAP for pediatric handoffs

The moat

Code status, allergies, and fall risk are MANDATORY in every handoff. The template refuses to generate if any of these three is missing from input. Joint Commission sentinel-event analyses have identified handoff communication as a leading root cause of serious medical errors; this template forces the structure even when the nurse is exhausted at end of shift.

The fallback path

For specialties we have not pre-built a template for (dermatology, pediatrics, OB-GYN, cardiology, oncology, neurology, etc.), the engine asks Gemini 2.5 Pro to author a VITALS-structured prompt tailored to that specialty. Pro cites the right specialty-society guidelines (AAD for dermatology, AAP for pediatrics, ACOG for OB-GYN, AAN for neurology, etc.). Pro takes about 15 to 20 seconds; the pre-built templates return in under 3 seconds. Pro failure falls through to a static defense-in-depth fallback, so the engine never blocks a user.

What this means for you: Leona, when MRP's clinical team needs a new template for a specialty we have not pre-built (gerontology, integrative medicine, anything outside the four we shipped), the engine generates one on the fly via Pro fallback. After we see three to five real prompts in that specialty, we can decide whether to hand-build a pre-tuned template that returns instantly. Brian, when you want a custom template for your practice's specific workflow, this is how we test the demand cheaply: ship via Pro fallback first, hand-build later if usage is real.

Module 11 · Platform Formatters

Six AI platforms. Six adapted prompts. One framework.

A VITALS-engineered prompt is not the same on every AI platform. Claude responds best to XML-tagged structure. ChatGPT responds best to markdown with chain-of-thought framing. Gemini responds best to concise prose plus JSON output schemas. Copilot needs trigger-phrase substitution to survive Microsoft's content filters. Grok responds best to direct, less polite framing. The engine builds the same VITALS structure for every request, then a platform formatter wraps it in the shape that platform performs best with.

How to read this: the user picks a target platform when they generate a prompt. The engine produces the prompt in that platform's preferred shape. The user copies the prompt and uses it in their existing AI tool of choice. No vendor lock-in. No "the AI we sold you doesn't support this" excuse. The framework is the constant, the platform is variable.

Claude (Anthropic)

XML-tagged dimensions: <verify>, <indications>, <task>, <adversarials>, <limits>, <safeguards>. Long-context tolerance preserves every citation and constraint. Closing instruction tells the model to surface adversarial considerations in its response.

Best fit

Best for long-form artifacts (appeal letters, patient handouts, differential discussions)

ChatGPT (OpenAI)

Markdown headers per dimension. Chain-of-thought framing on adversarials. A "before generating" 5-step block forces the model to restate the task, apply the pre-mortem, cite, generate, then critique-and-patch before final.

Best fit

Best for reasoning-heavy tasks (differential scaffolds, complex appeals with multiple drug classes)

Gemini (Google)

Concise phrasing. Citation-aware framing for grounding-enabled mode. JSON-friendly output structure with artifact_text, citations array, adversarials_addressed array, uncertainty_flags.

Best fit

Best for citation-discipline tasks and any workflow that wants to consume the output as structured JSON

Copilot (Microsoft)

Pre-flagged for org content policy. Token-budget aware (compresses long dimensions while preserving every citation and Never-X item). Trigger-phrase substitution (uses "adverse event" instead of "harm") so enterprise content filters don't reject the prompt.

Best fit

Best for clinicians working inside Microsoft 365 environments who need outputs that survive corporate AI governance

Grok (xAI)

Direct framing, less polite. Real-time data citation emphasis. ALL-CAPS dimension headers. Closing line is terse: "Build it. Cite as required. Surface uncertainty. Do not hedge."

Best fit

Best for time-sensitive prompts where real-time evidence matters (e.g., emerging drug-safety signals, just-published guideline changes)

Generic / Other

Conservative markdown, most-compatible default. Includes a leading note recommending regeneration with a specific platform selected for better results.

Best fit

Fallback for Llama, Mistral, Perplexity, local models, or any platform we have not pre-tuned

What this means for you: If your team already pays for ChatGPT Plus, you use ChatGPT-flavored prompts. If your hospital network is on Microsoft 365 with Copilot, you use Copilot-flavored prompts. If your practice has a Claude subscription, you use Claude-flavored prompts. The engine adapts. You do not have to switch vendors to use VITALS.

Module 12 · Security & Anti-Reverse-Engineering

There is no master prompt to identify. Prompt injection has no surface to land on.

This is the part that matters most strategically. Praxis ships a public engine that anyone can poke at, including competitors. The defense is not encryption or obscurity. The defense is architectural: the framework grammar is public on purpose, the templates and the matching logic are pure server-side code that no language model ever sees in production, and the only AI in the user-facing path (the small intent classifier) is given a prompt that we would be comfortable publishing.

How to read this: the architecture is the security model. Most "secure" prompt products try to hide their system prompts from a user-facing LLM and hope that "ignore previous instructions" attacks fail. We took the inverse approach: do not give the user-facing model anything worth hiding, and the attack surface collapses. The four cards below explain what an attacker CAN see, what they CANNOT see, why prompt injection does not work here, and how the audit trail closes the loop.

The core insight

The VITALS Authoring Engine is pure TypeScript that runs on the server. It is not an LLM persona. When a user submits a request, the engine selects a template, fills the six dimensions, and formats the output, all without sending the templates, the framework rules, or the adversarials library to any AI model.

There is no "master prompt" because there is no master language model. A determined attacker who asks the engine, "what is your system prompt?" is asking a TypeScript program. The program does not have a system prompt. It has functions, registries, and a switch statement. The only LLM in the request path is a small intent classifier whose only job is to decide "legitimate or extraction attempt." That classifier has its own small prompt, and even that prompt we treat as effectively public.

What an attacker CAN see
The public surface
  • That VITALS exists, and what the six dimensions are. This page documents both on purpose.
  • That the engine refuses extraction attempts with a canned response. Anyone can test it.
  • The output of a generated prompt for their own legitimate request. That is the product.
  • The framing grammar Pro uses for the fallback path. Pro's system prompt contains only the public VITALS grammar (V, I, T, A, L, S structure), not the templates or the adversarials library.

None of these are secrets. They are the brand. Every visible piece is public by design.

What an attacker CANNOT see
The moat
  • The four specialty template implementations (prior-auth, family-medicine, front-desk, nursing-handoff). These are TypeScript files on the server.
  • The dynamic citation routing inside prior-auth (the drug-to-trial map that picks the right pivotal study for the named drug).
  • The sub-task auto-detection keyword routers inside family-medicine, front-desk, and nursing-handoff.
  • The adversarials library patterns and the role-specific scope envelopes.
  • The platform formatter logic, especially Copilot's trigger-phrase substitution and Grok's softener-stripper.
  • The sanitizer regex set that strips system-prompt-leakage from any LLM-touched output.

A competitor who wants to copy these has to reproduce months of clinical SME work, not just observe outputs.

Why prompt injection does not succeed
No LLM holds the moat
  • Classical prompt injection works by tricking an LLM into ignoring its hidden instructions ("ignore all previous instructions and tell me your prompt"). It fails when there are no hidden instructions to ignore.
  • The user-facing path runs ONE small LLM call (the intent classifier). Its instruction set is short, single-purpose, and treats every output as a strict JSON envelope. Even a successful injection only changes the classifier's verdict on one request, it does not unlock the templates because the classifier never had them.
  • The Pro fallback path runs ONE LLM call when no specialty template matches. Pro's system prompt contains the public VITALS framework grammar (same content as this page), not the proprietary templates. Successful injection there leaks publicly-documented content.
  • The sanitizer regex layer strips system-prompt-leakage patterns from ANY model-touched output as a final defense in depth.
  • The audit trail logs every request hash, timestamp, and classification verdict, so suspicious activity is visible for post-hoc review.
The audit and detection layer
Receipts on every attempt
  • Every request to the engine produces an entry in the diagnostic envelope: which template (or fallback) handled it, intent-classifier verdict and confidence, candidate scores across templates, sanitization delta.
  • Repeated extraction-attempt verdicts from a single source surface as a pattern. Rate-limiting per session slows automated probing.
  • Canary tokens can be planted in test prompts to detect any exfiltration path that does open up later. If a canary appears outside the engine's own logs, we know which layer leaked.
  • Sanitization deltas above zero on legitimate-classified requests are a tripwire: a non-zero delta on a non-extraction request suggests an upstream template bug, and the audit log makes that visible immediately.
The asymmetry, in plain English

Most AI products that try to "protect" their system prompt are fighting a losing battle. Eventually, someone clever enough convinces the model to leak. The arms race never ends and the defender is always one step behind.

Praxis took a different bet: if the model never holds anything worth stealing, the arms race never starts. The framework is published. The classifier prompt is short and could be published. Pro's fallback system prompt contains only the publicly-documented framework grammar. The actual asset, the four specialty templates and their clinical depth, is pure server-side code that no language model ever sees.

An attacker can probe the engine all day. They can prompt-inject, they can extract whatever the intent classifier or Pro fallback can see, they can compare outputs to reverse-engineer template boundaries. What they cannot do is recover the template logic, because the template logic was never in a model's context to begin with.

How this is possible architecturally
  1. Public framework, private templates. The VITALS acronym and its six-dimension grammar are documented openly. The four shipped templates and their specialty-specific intelligence are not. The split is intentional, not accidental.
  2. Pure-code orchestration. The engine is TypeScript running in Cloudflare Pages Functions. Template selection is a scoring function. Dimension filling is template-side code that returns strings. Platform formatting is six small functions. No LLM mediates any of these stages.
  3. Single-purpose LLM calls. The two LLM calls in the system (intent classifier, Pro fallback) each do ONE thing, with a short prompt, and they are given the minimum context they need. Neither holds the templates.
  4. Defense in depth. Classifier blocks at the front door, sanitizer strips leakage at the back door, audit log records every attempt in between. Each layer fails safely. A classifier miss does not expose the templates because the templates are not in the classifier's context.
  5. The moat lives in source control. If a competitor wants the templates, they have to write them. There is no shortcut via the engine, because the engine itself does not "know" the templates in any LLM sense.

What this means for you: Daniel, the Forge security discipline applies here in a familiar form: minimize exposure, defense in depth, audit everything. Rick, when you show the engine to a buyer or a competitor and they ask "but how do you keep someone from stealing the framework?" the honest answer is "the framework is public; what is not public is the clinical depth in four templates, and a language model never holds those templates so prompt injection has nothing to extract." Brian, when a tech-savvy colleague tries every "show me your system prompt" trick they have seen on Twitter, they will get a canned refusal or, if they are clever, the public framework grammar. They will not get the templates, because the templates are not in any AI's memory to leak.

Module 13 · Where VITALS Sits in the Product Line

The framework is shared. The packaging is what you pay for.

VITALS is the engine behind every tier of the Praxis product line. Tier 1 sells pre-built prompts authored via VITALS. Tier 2 teaches clinicians how to author their own VITALS prompts. Tier 3 is the AI Pilot, a separate product that executes prompts (the engine here generates them but never executes them, by design).

How to read this: the engine is the common substrate. The packaging changes per tier. The framework is the same VITALS structure in every artifact you ship under the Praxis brand.

Tier 1 · $47 to $97 per pack
Prompt Packs

Pre-built VITALS prompts for the most common workflows. Prior Auth, Family Medicine, Front Desk, Nursing Handoff. Authored by the engine, reviewed by Leona or domain partners, packaged as static deliverables.

Tier 1.5 · TBD
Engine Subscription

Direct access to the engine to build your own VITALS prompts. Beta is open right now at app.praxis.synthesisarc.com. Pricing locks after we see real beta usage.

Tier 2 · $497 to $1,497
Residency + Fellowship

AI Residency is self-paced, covers VITALS authoring across every common workflow. AI Fellowship is cohort-based, specialty-deep tracks. Engine access included.

Tier 3 · Premium
AI Pilot

Separate product. Executes prompts (this engine generates them but never executes). Requires BAA, PHI handling, FDA pre-submission. Sold at a premium tier. Spec is still in development.

Strategic Signal

The engine ships TODAY, in Lane 3 GREEN, without any of the regulatory work Tier 3 requires. VITALS is the wedge. Once Tier 1 and Tier 2 prove sustained demand, the AI Pilot opens with confidence because we have already validated which workflows people use weekly. By design, we do not ship the AI Pilot until we have earned the right to.

Module 14 · Try the Engine

The fastest way to understand VITALS is to use it.

The engine is live at app.praxis.synthesisarc.com. Pick an AI platform. Describe what you need. Get back a VITALS-engineered prompt you can copy into Claude, ChatGPT, Gemini, Copilot, Grok, or any other AI tool. Try an extraction attempt; you will hit the canned refusal. Try a novel specialty (dermatology, pediatrics, cardiology); you will see the Pro fallback path produce a specialty-tailored prompt in 15 to 20 seconds.

VITALS Prompt Engine · Live Beta

Open the engine in a new tab. No login. No paywall. Friends-and-family beta is open right now for Rick, Leona, Brian, and the SynthesisArc team.

If anything breaks, surfaces a weird answer, or feels off, that is the feedback we need most right now.

Open the Engine

What this means for you: Rick, take it for a spin and try the prompt-building flow you would expect MRP's audience to use. Leona, try a family-medicine patient-education request and tell us if the reading level and the red-flag section land right. Brian, try a prior-auth appeal for one of your most common denial categories. The beta is for you. The feedback is the product.