Vibe Rounds: What "Vibe Coding" Looks Like When You Point It at Medicine

Vibe coding changed how people build software — you describe what you want in plain language, and the AI fills in the how. Vibe Rounds, a project coined by Dr. Avinash Kumar Gupta in June 2026, asks a simple question: what would that same shift look like in clinical training?

The answer isn't "an AI that diagnoses patients." It's closer to the opposite. Vibe Rounds is built on one deliberate constraint: the AI never just hands you the answer. It questions. It withholds. It makes you commit to a differential before it will even nudge you in the right direction. Think less "AI doctor" and more "the most relentless attending you ever rounded with" — except it runs in any chat window, on any case you paste in.

Not AI That Answers — AI That Questions

The philosophy is stated plainly on the project site: Vibe Rounds is not about asking AI for answers, it's about using AI as a Socratic cognitive partner. The clinician stays the decision-maker. The AI's job is to challenge assumptions, flag the biases that are common to a given clinical scenario, and offer a second opinion — without ever substituting its judgment for yours.

In practice, that shows up as a set of hard constraints layered onto every persona prompt in the system:

• Forced commitment first — no hint unlocks until you've offered an initial answer.
• Minimum effort threshold — a lazy "idk" gets redirected, not rewarded.
• Tiered hints — a framework first, then a narrower direction, then a partial answer. The full answer only comes after you've reasoned it out, or explicitly ask the AI to "surrender."
• Effort-weighted teaching — the more thought you put in, the deeper the teaching you get back.
• Reasoning graded, not just correctness — the AI evaluates your logic and your willingness to flag uncertainty, not just whether you landed on the right diagnosis.

It's a framework, not a piece of software with hidden state — you copy a persona prompt into Claude, ChatGPT, Gemini, or NotebookLM, and the constraints travel with the text.

From Persona Prompts to a Full Operating System

The single-persona layer (Socratic Learning) is the entry point, but it sits underneath something much larger: CCOS — the Clinical Cognition Operating System.

CCOS is the architectural backbone of the whole project — 57 self-contained reasoning modules, 4 pedagogical frameworks, and 200+ pipelines that chain modules together into progressively deeper reasoning passes on a single case. It's organized into six cognitive layers, from raw clinical reasoning (illness scripts, differential diagnosis, Bayesian inference) up through a workflow engine, metacognitive monitoring, an "epistemic trust layer" that calibrates confidence and suppresses false numerical precision, a decision-architecture layer spanning conservative-to-maximal pathways, and a longitudinal learning/documentation layer on top.

The project is candid about what this trust layer actually is and isn't: it's prompt-level instructions that shape how the AI expresses uncertainty — not an automated fact-checking or verification system. No claim gets checked against an outside source unless a specific module says so.

A CCOS Builder on the site lets you paste in a case, tick modules in the order you'd want to run them, and get a ready-to-copy prompt for any LLM. Sequence matters here by design — running a safety/bias module before a reasoning module produces a different teaching pass than running it after.

#	Title	Link
1)	Vibe Rounds — AI-Augmented Clinical Reasoning	avi33tbtt.github.io
2)	Vibe Rounds - Case Bench — Clinical Reasoning Aid	avi33tbtt.github.io/bench.html
3)	Vibe Rounds - Case Bench — Clinical Reasoning Aid (Lite version)	avi33tbtt.github.io/bench_lite.html
4)	Clinical Polemos — Healthcare Debate Bench	avi33tbtt.github.io/clinical-polemos.html
5)	Vibe Rounds — Case Simulator	avi33tbtt.github.io/case-simulator.html
6)	Modern Clinical Reasoning: Integrating Promption and Provocation Modes in Medical Analytics	avi33tbtt.github.io/article.html

A Maturity Map, Stated Honestly

One of the more unusual things about the project is that it publishes its own honesty check. The site lays out three application domains and rates each candidly:

• AI-augmented clinical education — high maturity. Socratic feedback loop, a six-level difficulty framework, prompt-version history, a pilot protocol, and live deployment already demonstrated.
• Guided discovery research — medium maturity. The seven-stage N-of-1 reasoning workflow and analysis methodology are defined and a worked case exists, but multi-case validation is still pending.
• Bedside clinical decision support — early stage. Concept and architecture only; EMR integration, multimodal AI, and FHIR infrastructure are all pre-implementation.

That kind of "here's what's actually deployable versus what's still a vision document" transparency is rare for a project this ambitious, and it's worth taking at face value: Vibe Rounds is explicit that it is a learning system, not a validated clinical or diagnostic instrument, anywhere along that spectrum.

The Tools You Can Actually Try

Beyond the prompt library, the project ships several standalone, browser-based apps — all bring-your-own-API-key, all running client-side with nothing routed through a third-party server.

Case Bench is the general-purpose reasoning workbench. Paste in a case — a vignette, a discharge summary, your own clerking notes, or a case link — and choose how you want to work it: a live back-and-forth dialogue (with quiz-style modes for NEET PG, USMLE, MRCP, or PLAB-style practice), a single-pass "Analytics Mode" report using one CCOS module, or a full pipeline you assemble stage by stage, where each step sees the case plus every prior stage's output.

Case Bench Lite is a lighter version of the same idea for a faster, lower-friction session.

Case Simulator goes further into a game-like format: pick a specialty, a difficulty level, and a setting (ED, general ward, outpatient, ICU), then work a simulated, LLM-generated patient encounter through a live console — complete with a labs dashboard, a SOAP-note view, a ranked differential, and clinical pearls that populate as the case unfolds.

Clinical Polemos (Healthcare Debate Bench) takes the Socratic idea sideways into policy and systems thinking. You put a clinical case, a policy question, or a hospital dilemma in front of a panel of stakeholder personas — physicians, nurses, allied health, administrators, patient advocates, policymakers, trainees — and each one argues strictly from its own seat in the system, with no softening for the others. It's a rhetoric and reasoning exercise, explicitly framed as medical-education content rather than clinical advice.

And underpinning the theory behind all of it, the project has a companion preprint — "Modern Clinical Reasoning & Socratic AI: Integrating Promption and Provocation Cognitive Modes into Healthcare Analytics" — alongside a flagship architecture paper on ResearchGate laying out the design rationale and composition semantics for CCOS itself.

Where It Fits Pedagogically

The site places itself deliberately on a five-stage teaching spectrum, from instructor-centered lecture through to fully independent research. Vibe Rounds' home base is explicitly Stage 3 (Socratic stress-testing), extending into Stage 4 (Guided Discovery) — the zone where a learner already has some grounding and the job shifts from receiving information to having assumptions challenged and mental models scaffolded through structured struggle. It's not trying to replace foundational lectures, and it's not trying to be an autonomous research assistant either — it's built for the specific stretch in the middle where questioning, not answering, is what actually builds reasoning skill.

The Honest Caveats

The project is upfront, repeatedly, about its own limits. It's licensed CC BY 4.0 and free to use, but every page carries some version of the same line: to be used on personal responsibility and only for learning — not for clinical purpose. Outputs are treated as drafts to verify, not citable findings; every reference or number is something you're expected to check against the primary literature yourself. The tools are described as experimental, capable of making mistakes, and meant to be cross-checked — not trusted outright.

That candor is arguably the most interesting design choice in the whole project. Vibe Rounds isn't selling itself as a finished clinical AI product — it's an open, evolving prompt architecture for teaching people to reason better, built by someone willing to publish exactly how far along each piece actually is.

---

Vibe Rounds was coined by Dr. Avinash Kumar Gupta in June 2026. The full stack — persona prompts, the 57-module CCOS library, Case Bench, Case Simulator, Clinical Polemos, and the accompanying courses — is available at avi33tbtt.github.io.

A Panel of Arguing AIs

From a Panel of Arguing AIs to a Working Behavior-Change Protocol: Notes on the Polemos Experiment

The setup

A few weeks ago I built Polemos, a small browser-based tool I've been calling a "Polymath Debate Bench." The idea is simple to state and more interesting to watch: you give it a case, a claim, or a question, pick a panel of archetypal personas, and let them argue. No moderator smoothing things over, no consensus-seeking — each persona reasons from its own logic and its own register, opening statements followed by continuous rebuttal, for as many rounds as you want. It runs entirely client-side; you bring your own model API key (Claude, Gemini, OpenRouter, or any OpenAI-compatible endpoint), and nothing passes through a server of mine.

I built it because I wanted something structurally different from the usual "ask one model, get one balanced-sounding answer" pattern. A single model asked to "consider both sides" tends to hedge toward the middle. A panel that's actually allowed to disagree — where a systems-thinker archetype and a behavioral-psychology archetype and a skeptic archetype are all pushing from different premises — surfaces friction that a single hedged answer smooths over. That friction is the point.

Turning debate into design

The specific run that produced the work I'm writing about here was a debate about designing a lifestyle/behavior-change program to run over WhatsApp — the kind of thing a lot of small health or fitness communities try to do with an open group chat and good intentions, and which usually decays into noise within a couple of weeks.

I ran the debate at polemos, let the panel go several rounds of rebuttal, and downloaded the transcript. That transcript — disagreements, half-conceded points, the places where one persona forced another to get more specific — was the raw material. I uploaded it to Claude and asked it to synthesize an actual, runnable protocol out of the argument, rather than just summarizing who "won."

What came out of it

What Claude produced wasn't a restatement of the debate — it was a structured protocol that resolved the tensions the panel had raised into concrete design decisions. A few things stood out to me:

• Small cohorts, split channels. Instead of one big group chat, the protocol calls for cohorts of 5–8 people split into a "Data Log" channel (structured prompts only) and a "Cheer" channel (peer encouragement). That separation of signal from noise was a direct answer to a tension the debate had surfaced about social comparison and diffusion of responsibility in large groups.
• If-then planning over open discussion. Commitments are collected privately, in a fill-in-the-blank format ("If it's 7am on a weekday, then I will walk for 10 minutes before checking my phone"), rather than announced publicly — avoiding the trap of performative commitments that look good in a group chat but don't predict behavior.
• Aggregate, not individual, feedback. Weekly updates report the group's numbers, never call out individuals — encouragement without shame-based comparison.
• Intention-to-treat measurement. This is the part I found most valuable. The protocol insists on reporting outcomes for everyone enrolled on Day 0, including people who stop responding, and it explicitly bans reporting results as "% of active participants." That's a direct fix for survivorship bias — the classic failure mode where a program looks like it works because only the people it worked for are still around to be counted.
• A real attrition plan. Specific triggers (3 days no reply, 14 days of low adherence, two missed weekly logs) map to specific, non-punitive re-engagement actions instead of silent dropout.

None of these ideas are individually novel — if-then planning implementation intentions and intention-to-treat analysis are both well established in behavioral science. What was interesting to me was watching them arrive as the resolution of an argument rather than as a list I'd have generated by prompting for "best practices." The adversarial structure forced trade-offs to be made explicit — cohort size versus intimacy, engagement metrics versus honest outcome metrics, encouragement versus honesty about who's dropping off — instead of getting flattened into a single unopinionated summary.

Why this is worth writing up

I think of this less as "I used AI to write a protocol" and more as a small case study in a different way of using these tools: instead of asking one model for an answer, stage a disagreement between several framings of a problem, and then have a separate synthesis step turn the disagreement into a decision. The debate does the work of stress-testing an idea; the synthesis step does the work of committing to specifics.

It's also, honestly, a fairly minimal pipeline — a static HTML page, a debate transcript, and one prompt to Claude — which is part of why I think it's worth sharing. The interesting part isn't the tooling, it's the workflow: disagreement as a design method.

If you want to see the tool itself, it's at polemos.html, and the running version I used for this is at polemos. The full protocol that came out of this particular debate — onboarding scripts, daily and weekly check-in templates, a moderator checklist, and the measurement plan described above — is attached alongside this post for anyone who wants to actually run something like it.

Protocol to a working app now? 

want to try a healthcare specific polemos? - try here https://avi33tbtt.github.io/clinical-polemos.html

pajr mirror record

This record documents a 55-year-old female patient with a 18-year history of Type 2 Diabetes Mellitus (DM2) and 3-year history of Hypertension (HTN), currently admitted for an elective hysterectomy.

Clinical Summary:

• Presentation: Admitted for management of a subserosal uterine fibroid (found incidentally via ultrasound during workup for chronic lumbosacral back pain) and glycemic stabilization.

• Observations: The primary physician notes that the back pain is clinically correlated with lumbosacral degenerative changes rather than the fibroid, raising concerns regarding the surgical intervention's efficacy for symptom relief. There is documented consideration of potential placebo effects and cognitive dissonance as factors in the patient's post-operative outcome.

• Metabolic Status: At admission, the patient presented with hyperglycemia (recorded GRBS at 239 mg/dL and a history of levels up to 515 mg/dL).

• Management Plan:

  • Transition from long-term oral hypoglycemic agents (Glimi-MP2/Dapa-M) to an inpatient insulin-based/titrated regimen.

  • Strict metabolic monitoring (4-point GRBS checks).

  • Continued management of hypertension and comorbidities with existing and supplementary medications (e.g., Telma-H, Rosuvastatin, Pregabalin, and Librium for sleep/anxiety).

  • Post-operative planning remains active.

The logs reflect a professional clinical environment focused on aggressive glycemic control and a skeptical evaluation of the surgical rationale for the patient's primary complaint of back pain.

Vibe Rounds - Socratic Ai

 For the full architecture -

The Socratic method is the spine, not a single feature

1. It's literally Module 1, and everything else builds on it. Module 1 — "Socratic Clinical Reasoning" — establishes the core contract: the objective is to push a learner to reason through a case actively rather than passively receive the answer. Every other module cross-references back to it as the "structural template" or "logical prerequisite."

2. The core mechanic is forced commitment before reveal. The Step 1.0 setup prompt explicitly instructs the AI to ask one question at a time, wait for the learner's response, and only reveal the answer after the learner has made a genuine attempt and explicitly surrendered — redirecting once with "give your best guess, differential, or next step first" if they ask for the answer without trying. This is the Socratic essence: the AI never just tells you the diagnosis — it makes you commit to a guess first, and only then guides you toward the gap in your reasoning.

3. It teaches by exposing gaps, not correcting outright. Across the whole repo, the recurring instruction is variations of: don't correct the student directly — ask one pointed question that helps them find the gap themselves (you can see this almost verbatim in the roleplay templates near the end of the file too, e.g. "Don't correct me outright — help me find the gap myself").

4. Every other module is a Socratic variant scoped to a different skill, not a different method:

• Module 12 (Devil's Advocate) = adversarial Socratic pressure for diagnostic anchoring
• Module 14 (Resource-Constrained) = Socratic forced-commitment applied under low-resource limits
• Module 15 (Illness Scripts) = deliberately diverges from Module 1's stepwise Socratic pattern to train pattern-recognition instead — but is explicitly framed as a departure from the default, proving the default is Socratic
• Module 17 (Problem Representation) = Socratic withholding applied even earlier in the reasoning chain (withholding the diagnosis attempt, not just the answer)
• Modules 4, 5, 18 (ward rounds, real-time review, rapid triage) all reuse the "Mid-Session Reasoning Checkpoint" (Step 1.4) structure as a recurring formative loop

5. The pedagogical scaffolding is Socratic-compatible by design. Bloom's Taxonomy (Step 1.5) and Fink's FLINK (Step 1.6) aren't separate teaching philosophies bolted on — they're applied through the same one-question-at-a-time, wait-for-response, affirm-then-probe loop.

6. Even the "build a case" roleplay versions preserve it. The progressive-vignette templates (Versions 3–5) release the case in chunks specifically so the Socratic question-per-chunk rhythm can repeat — vignette → one pointed question → next chunk — rather than dumping the full case and losing the reasoning checkpoints.

So the throughline is: Module 1 sets the contract (commit before reveal, probe don't correct), and the other 19 modules are that same contract re-applied to different clinical contexts (wards, polypharmacy, resource scarcity, SDOH, rapid triage) or deliberately flagged as the exception when they diverge from it.

Case 2 20 jun 2026

Recent thyroid swelling with pressure symptoms, loss of appetite since 2 months.

Suspected malignancy. Planned FNAC and excision biopsy Also has biochemical subclinical hyperthyroidism with mild lid lag, tremors and tachycardia. run full analysis

Vibe Rounds - Final Briefing

 

Vibe Rounds: What Each Module Does, Why It Doubles as an Explainability Framework, and What It Actually Surfaces in a Real Case

Prepared as a briefing on Dr. Avinash Kumar Gupta's VibeRounds framework, June 2026

---

Introduction

VibeRounds is built around one constraint: the AI is not allowed to give the answer. It questions, surfaces evidence, and flags gaps, while the learner does the reasoning. That constraint is the source of two separate but connected things this framework produces. First, it's a teaching system — 20 modules, each targeting a distinct clinical-reasoning skill. Second, almost as a structural side effect of how it's built, it functions as an explainability layer — a way of making both AI reasoning and expert human judgment inspectable, rather than opaque. This document walks through what each module does, explains why the same architecture that teaches also explains, and then shows that this isn't just theoretical — by walking through a real worked case where the framework surfaced a specific, missed diagnostic pivot.

---

Part 1 — What Each Module Does

The modules aren't a flat prompt list; each targets a distinct moment or skill in clinical training. Four cross-cutting frameworks (Bloom's Taxonomy, Fink's Taxonomy of Significant Learning, a Humanistic Persona trait set, and a Critical Awareness framework) are woven into specific steps across them rather than run standalone. Every module follows the same three-phase shape — Initiation → Execution → Closure/Review — regardless of content.

#	Module	What It Does
1	Socratic Clinical Reasoning	Pushes a learner to reason through a case actively rather than passively receive the answer. The AI withholds the diagnosis until the learner has made a genuine attempt and explicitly surrendered.
2	Patient-Advocate Case Documentation	A 4-step workflow letting a family member build a structured case record collaboratively with an AI acting as a documentation companion — for when there is no clinician present to do this.
3	Extended Patient-Advocate Monitoring	Extends Module 2 with longitudinal tracking — lifestyle, mood, medication adherence, and red-flag symptoms — over weeks or months rather than a single encounter.
4	Peer-Level Ward Round Preparation	Rehearses rounds, admission workups, pre-op clearance, and overnight triage, with the AI acting as a peer study partner rather than a supervisor — it thinks alongside the learner, not above them.
5	Real-Time Case Review & Data Audit	Queries and cleans a single patient's live case log — diet diaries, insulin logs, prescriptions — during active management.
6	Registry-Level Analytics	Queries an entire case registry, not a single patient, across nine escalating levels of analytic depth.
7	Longitudinal & Cross-Case Learning	Turns the registry itself into a learning system across cases and time — asking not just what cases contain, but what the registry has learned across them (still experimental; proposed but not yet fully validated live).
8	Socratic-Mode Design Specification	A 12-point QA checklist for authoring or revising any new Socratic-style prompt — quality control for the prompts themselves.
9	N-of-1 Case Research Protocol	Takes a clinician from a raw, unstructured case narrative to a fixed, publication-ready output package — severity rating, priority rating, timeline, intervention-symptom correlation — via seven explicit stages.
10	Medical Journal & Article Reading	Has the AI do the intellectual processing most readers skip when reading a paper — translating statistics into clinical meaning, mapping findings onto real patients, surfacing what the paper doesn't say.
11	Patient Education Query Intelligence	Helps a student anticipate the real questions patients and families carry about an illness, so they learn to see the case through the patient's eyes, not just the chart.
12	Differential Diagnosis Deepdive (Devil's Advocate)	Systematically attacks the working diagnosis and stress-tests the differential list, surfacing anchoring errors and premature closure before they reach the patient.
13	Medication Reconciliation & Polypharmacy	A structured audit of a patient on 5+ drugs, training the student to spot drug-drug interactions, drug-disease conflicts, and prescribing cascades through active reasoning.
14	Global Health & Resource-Constrained Reasoning	Trains clinical reasoning that starts from "what is actually available here" rather than "what is ideal" — making the resource ceiling itself part of the differential and management process.
15	Illness Script Acquisition	Trains the compiled, holistic "illness scripts" experienced clinicians actually use for fast recognition — a distinct skill from the stepwise differential-building in Module 1.
16	Bidirectional Basic Science ↔ Clinical Integration	Drills the two-way link between mechanism and diagnosis explicitly — diagnosis-to-mechanism and mechanism-to-diagnosis — rather than leaving it to form implicitly over years.
17	Semantic Qualifiers & Problem Representation	Trains the compression step before any diagnosis is attempted: restating a raw case as paired abstract qualifiers (acute/chronic, focal/diffuse) — the step research shows correlates more strongly with diagnostic accuracy than raw factual knowledge.
18	Causal vs. Probabilistic (Network) Reasoning	Trains reasoning over networks of interacting findings, where one finding's diagnostic weight changes depending on what else is already known — rather than treating findings as independent.
19	Community & Social Medicine Insights	Trains reasoning about a patient's social and economic context as a clinically active variable, not background colour — connecting individual social context to population-level patterns.
20	Naturalistic Decision Making (RPD)	Trains decision-making under real time pressure the way experienced practitioners do it: recognise the pattern, generate one plausible plan, mentally simulate it forward — not a side-by-side comparison of options.

---

Part 2 — How the Same Architecture Doubles as an Explainability Framework

Clinical AI has a standing problem independent of VibeRounds: a model can return a conclusion — a differential, a risk flag, a ranked priority list — without showing the steps that produced it. An unexplained conclusion can't be checked, can't be taught from, and can't be defended later if a decision is questioned. VibeRounds treats this as something the architecture itself is built to solve, not a side effect to tolerate.

The mechanism is structural, not bolted on

Because Module 1's Socratic constraint forbids the AI from jumping straight to an answer, the AI is forced to externalize its intermediate reasoning — as questions, evidence flags, gap identification — rather than collapsing it into a single output. The registry-level modules extend the same principle to data: cross-case queries are designed to surface why a diagnosis shifted, not just that it shifted, and an "Epistemic Bias Audit" step audits how the reasoning network arrived somewhere, not just what it concluded. If a system can't answer a "why did this change" query, that's treated as a documentation failure to fix, not an acceptable limitation.

The 6-stage pipeline

The Master Case Analysis Protocol runs every case through six stages that force visible reasoning:

1. Prompt mapping — which modules actually apply to this case
2. Ranking — justifying why certain problems outrank others
3. Mechanistic deep-dives — anchoring conclusions in basic science, not pattern completion
4. Output — a structured report with traceable logic connecting the above to the final synthesis

This is stated explicitly to prevent "black box" outputs — a conclusion with no visible reasoning chain behind it.

Two-Tier Analysis: explainability through refusing to merge

Module 9's Stage 4 keeps two views of a case deliberately separate before synthesis: the Coded View (structured data — diagnoses, results, drug names) and the Narrative View (the unstructured, sequential record of what was noticed first, doubted, deferred, or wrongly attributed). Standard summarization collapses these into one clean story — which is itself an explainability failure, because it erases the reasoning path and replaces it with hindsight. Keeping them separate prevents premature closure: resolving ambiguity too early by imposing a coherent narrative on incomplete data.

Human annotation, not just AI output

Outputs are designed to function as a structured possibilities map that a human expert can mark up as confirmed, ruled out, or uncertain — particularly at "diagnostic void" points, where the framework explicitly flags that no decision can be made until missing data is retrieved, rather than guessing past the gap.

Making expert judgment auditable too

The same logic is applied to human reasoning, not just the AI's. A clinical-importance ranking exercise scores every applicable prompt in a case 1–10 and assigns each an explicit reason (irreversibility, time-window, confirmatory vs. action-changing). The framework is candid that an experienced clinician would already sense this prioritization instinctively — what the exercise adds is externalizing a judgment that's normally silent, fast, and undocumented, turning it into a defensible audit trail, a teaching artefact for a junior colleague, and a safeguard against the exact fatigue conditions under which expert judgment degrades.

---

Part 3 — A Full-Fledged Report: What the Framework Actually Surfaced in a Real Case

The clearest demonstration isn't theoretical — it's a worked case in the repository: a 60-year-old woman with an 18-year history of cervical myelopathy who died of MDR E. coli sepsis, pancytopenia, stony splenomegaly, and CSF albumino-cytological dissociation, with no unifying diagnosis ever established. The framework was applied to the original (de-identified, consented) clinical record using the CARE case-report format, and the insight it produced is concrete enough to walk through directly.

The anchoring problem the framework caught

The patient's 18-year cervical myelopathy diagnosis functioned as a powerful cognitive anchor: every new symptom over nearly two decades was interpreted within that existing frame rather than questioned. Applying Module 12 (Devil's Advocate) and Module 15 (Illness Script — script mismatch recognition) to the four-month acceleration period identified the specific point where the frame should have been reset: a pre-operative finding of pancytopenia, four months before death, when planned surgery was cancelled and the patient was simply referred back with instructions to "normalise blood counts."

The report's own framing of this: pancytopenia in a patient with myelopathy and stony splenomegaly is not a reason to delay surgery until blood counts normalise — it is a reason to stop and ask what is causing the triad. That reframe — turning a "wait and recheck" moment into a flagged diagnostic pivot — is exactly the kind of insight Module 12 is built to produce: surfacing premature closure before it reaches the patient, not after.

Findings the framework forced into explicit weight

Several individual findings, applying Module 16 (mechanism ↔ diagnosis) and Module 18 (network reasoning), were shown to carry diagnostic weight that the original clinical course didn't act on:

• Stony, hard splenomegaly (as opposed to a soft, enlarged spleen) — texture, not just size, was treated as diagnostically specific: implying infiltration by granulomas (TB), malignant cells (lymphoma), or fibrosis, and specifically not consistent with simple portal hypertension. This was documented in the clinical record but never followed to an investigative conclusion.
• A near-normal CSF cell count (5 cells) in a pancytopenic patient — interpreted at the time as excluding active meningitis. Module 18's conditional-weighting logic flags this as unsafe: when peripheral white cells are suppressed, the CSF cell response to meningeal infection is also suppressed, so a near-normal count doesn't rule out TB or carcinomatous meningitis in this specific patient — it's conditionally uninformative, not reassuring.
• Haemoglobin rising only 0.1 g/dL after two units of packed red cells — reframed not as a transfusion failure but as a positive finding in itself: an explicit signal of active red cell destruction or ongoing haemorrhage outpacing replacement, which was never investigated.
• Escalating baclofen dosing (patient self-escalated to twice-daily over the final four months) — flagged via Module 13-style polypharmacy logic as a pharmacological differential for the exact terminal triad (coma, hypothermia, type 2 respiratory failure), since baclofen is renally cleared and toxic on accumulation — something that should have been evaluated against renal/hepatic function and wasn't.

The explainability layer made visible in this case

This case is also where the explainability mechanism is easiest to see directly. The report doesn't just state a missed diagnosis — it produces a structured differential table (disseminated TB vs. haematological malignancy vs. autoimmune disease vs. baclofen toxicity vs. hepatic myelopathy), each row scored against supporting evidence, evidence against, and the specific investigation that would have resolved it. That is the 6-stage pipeline's "ranking" and "mechanistic deep-dive" stages made concrete: not "this patient probably had TB," but a traceable table a second reader can independently check, disagree with, or extend.

The report goes further and names the three specific accessible investigations that, had they been obtained at the pre-operative pancytopenia discovery, may have changed the diagnostic trajectory — TB-PCR/AFB culture on the bone marrow that was already biopsied, expert review of the peripheral blood smear, and a single autoimmune panel. All three were available at the level of care the patient was receiving; none are documented as having been obtained. That is the framework's "diagnostic void" concept applied concretely — not a vague statement that something was missed, but a flagged, specific, actionable gap.

What the advocate side of the same case adds

A companion Advocate Debrief, built from Modules 2, 3, and 11, applies the same framework retrospectively to what the family was — and wasn't — given at each clinical decision point. It identifies three specific moments where clearer guidance could have prompted earlier escalation: when haemoglobin barely rose after transfusion and the family wasn't told this was itself a red flag; when self-resolving diarrhoea was attributed to diet rather than explained as a possible clinical signal; and when new breathlessness wasn't explicitly framed as a respiratory red flag. This is the same explainability principle pointed at a different audience: not "what should the clinician have concluded," but "what should the family have been told, and when."

---

Summary

VibeRounds is, at its core, a teaching system organized as 20 modules and four cross-cutting frameworks, each targeting a distinct moment in clinical training — from withholding an answer until a learner reasons (Module 1) to training fast pattern-recognition under time pressure (Module 20). The same Socratic constraint that makes it work pedagogically — forcing reasoning to stay visible rather than collapsing into an answer — is what makes it function as an explainability layer: a 6-stage pipeline that produces traceable logic, a Two-Tier analysis that resists premature closure, and a human-annotation layer that turns both AI uncertainty and tacit expert judgment into something inspectable. The worked 60F case shows this isn't just architectural description: applying the framework to a real, fatal diagnostic-anchoring case produced a specific missed pivot point, a ranked differential with named confirmatory investigations, and a concrete account of what the family should have been told and wasn't — output a clinician, a student, or a family member could each independently check against the record.