When the Simulator Catches What the Chart Missed

Source case: Severe Obesity and Hypoglycemia · Simulator session: VibeRounds Case Simulator run

A 59-year-old woman gains 9 kg in 20 days, starts shouting in her sleep, develops mouth ulcers, and keeps crashing into hypoglycemia after meals — despite a "normal" HbA1c. The real-world case resolved well: CPAP for newly severe obstructive sleep apnea, then a clean-up of an overloaded diabetes regimen. Good outcome, good medicine.

But running the same case through VibeRounds' Case Simulator surfaced something the linear clinical narrative didn't foreground: the case isn't really two problems running in parallel — a sleep problem and a diabetes problem. It's one problem with a shared driver, and seeing that shared driver early changes how a learner should sequence their next questions.

The catch — and where it actually came from

It's tempting to credit this to pharmacology: the simulator "knew" that pioglitazone combined with insulin drives rapid renal sodium and water retention, and that in a recumbent, already-crowded airway, that fluid shifts rostrally into the neck and pharynx. But that mechanism is inert textbook knowledge on its own — plenty of patients are on TZDs without anyone connecting it to their snoring. What actually made it fire as a flag was the history: the case opens with the weight gain pinned to an exact window — 8 to 9 kg over 20 days, shortly after starting new diabetes medications. That single timestamp is the whole catch. It's what turned a generic drug-side-effect fact into a specific, dated hypothesis worth chasing.

Once the 20-day window is on the table, everything else lines up against it: the facial fullness, the new gasping, the shouting in her sleep. Those aren't just an OSA severity trend — they're a drug-timeline trend, and they only read that way because the history gave the simulator (and the learner) a clock to check them against. Take away the "20 days" and you're left with "obese patient, worsening OSA, on diabetes meds" — three true facts that never resolve into an urgent, dated hypothesis.

That's a subtle but genuinely high-value distinction for a trainee to make on their own: chronic OSA substrate versus acute, dateable decompensation of that substrate. Miss the timeline, and you fix the airway with CPAP and call it done. Catch it, and you know to go hunting for what changed 20 days ago — which is exactly where the pioglitazone/insulin combination was sitting, waiting to be found because the history pointed there first.

The second catch: the number that should have stopped everyone

The simulator also flagged something sharper, almost buried in the noise of the sleep-study workup: an HbA1c of 5.8% next to home glucose readings in the 50s and 60s. That combination — a near-normal HbA1c and recurrent symptomatic hypoglycemia — is one of the more urgent mismatches in diabetes management. It's not a "remaining issue" to circle back to after the sleep apnea is sorted; it's arguably the single most diagnostically loaded data point in the whole case, because it says, plainly, that this patient is being treated for a level of diabetes she doesn't currently have.

A learner working the case linearly might reasonably prioritize the airway crisis first, since it's the more dramatic presentation. What the simulator's pearls made explicit is that the glucose-vs-HbA1c mismatch deserved to be flagged as equally urgent, in parallel, not sequentially — because ongoing sulfonylurea and basal insulin in a patient who's already crashing into the 50s carries real short-term risk on its own.

Why this matters for teaching

Neither of these catches required rare knowledge. A resident who knows how TZDs work and knows what HbA1c represents has all the pieces. What they need training in is something less glamorous and much harder to teach from a textbook: the discipline of pinning every finding to a precise timeframe during history-taking, and then actively checking new findings against that timeline instead of just cataloguing them. The simulator didn't supply extra medical facts the learner didn't have — it modeled what happens when a "when did this start, exactly" answer gets carried forward and cross-checked against everything that follows, rather than being logged once and forgotten.

That's the real, transferable skill: a precise history isn't just documentation, it's a live filter that turns an inert fact ("TZDs cause fluid retention") into an urgent, dated hypothesis the moment it's checked against "20 days ago." Reconciling those pieces at the right point in the workup is what the simulator forced — but the reconciliation was only possible because the timeline was captured tightly enough to reconcile against in the first place.

That's the gap between reading a case and being examined on a case. A well-built Socratic simulator doesn't just quiz recall; it puts pressure exactly where a learner's reasoning tends to fragment — the seams between subspecialty findings — and does it in the time it takes to review the pearls after each round, not after weeks of ward rounds and delayed feedback.

What this is — and isn't

One thing worth being explicit about: this was run as an experiment, not a clinical review. The simulator was fed only the limited data captured in a student's case record of this encounter — the history as documented, the values as logged — nothing more. So what's being reported here isn't the simulator flagging a gap in this patient's actual management; the real care team, working with the full picture and the patient in front of them, handled this well and the outcome was good. What the simulator flagged is a gap in the record — points the student's write-up captured but didn't connect, or captured loosely enough that the connection wasn't forced. That's a finding about documentation and reasoning practice, not a finding about the case.

None of this is clinical decision-making or decision support, either. The simulator doesn't manage the patient — it trains a learner's history-taking and pattern-reconciliation skills against a well-documented case, in a space with no patient at risk and no hierarchy to navigate.

That distinction matters for how a learner is expected to act on what they find. Flagging that an HbA1c-vs-hypoglycemia mismatch deserved earlier attention, or that a 20-day timeline pointed straight at a drug interaction, isn't a verdict to carry into a ward round and assert. The right move for a learner who spots something like this in practice is to raise it as a clinical knowledge inquiry to the care team — a question, a "have we considered," a contribution — not to sit on it hoping it quietly shapes a decision. That's the appropriate posture for a training tool: it sharpens the question a learner knows to ask, and leaves the deciding, and the asking-out-loud, to the people actually responsible for the patient.

If I were tightening this module, I'd want the flow to explicitly prompt the learner to reconcile the HbA1c-versus-glucose-log discrepancy before CPAP titration gets addressed — right now it's easy for that thread to sit as a "remaining issue" resolved later in the narrative, when it's arguably the more diagnostically urgent one to surface first. Small sequencing change, but it's the difference between a tool that reflects good case management and one that actively trains a learner to reflex-check the numbers that don't add up, on their own, under time pressure — which is the actual skill worth building.

 

A Gradual Journey: Sharpening Clinical Reasoning, One Vibe Rounds Step at a Time

Most people encounter the Vibe Rounds framework (Dr. Avinash Kumar Gupta, June 2026) the way they'd encounter any new tool: as a wall of links — a homepage, a prompt library, 57+ modules, four pedagogical frameworks, 200+ pipelines. That's not a criticism of the framework so much as a warning about the on-ramp. Nobody sharpens their clinical reasoning by opening all 57 modules at once.

This article does the opposite. It treats the whole tool-and-prompt stack at avi33tbtt.github.io and the Prompts library as a staircase, not a menu — a sequence you climb over weeks, not a catalogue you browse in one sitting. Each step below uses only what you actually need at that stage, and points to the next step only once the current one is genuinely uncomfortable.

---

Step 0 — Orientation before any case (Module 0)

Before touching a real or dummy case, the framework has a deliberate cold-start: Module 0 — Cold-Start Orientation. Its job is narrow — route you to the right module before any clinical content enters the conversation, so you're not diagnosing a case and picking a pedagogy at the same time.

What to actually do: Open Module 0, answer its routing questions honestly (are you a student, a caregiver, a resident, an educator?), and let it hand you back a starting point rather than picking one yourself. The whole point of a staircase is that you don't get to skip to the landing you like the look of.

---

Step 1 — Build the differential from nothing (Socratic Learning, Module 1)

This is the foundation, and the site is explicit that it's meant to be: Socratic Learning personas — a Supportive Intern, a Junior Resident, a Socratic Attending — are "good for early clerkship students," and Module 1 is where "Active reasoning" lives: Socratic questioning that withholds the answer until you've genuinely attempted one and explicitly surrendered.

The mechanism that makes this different from just asking ChatGPT for a differential is the constraint layer described on the homepage:

• Forced commitment first — no hint unlocks until you've offered an initial answer.
• Minimum effort threshold — "idk" gets redirected, not rewarded.
• Tiered hints — framework, then narrowed direction, then partial answer; never the full workup up front.
• Reflection before reveal — "Why do you think that?", "What could kill the patient?", "What are you missing?"

How to practice this stage: take a single case — the site's own dummy teaching case works well (58-year-old man, central chest tightness radiating to the jaw, diabetic, heavy smoking history, HR 96, BP 148/92, SpO₂ 97%) — and run it through a Socratic Attending persona. Commit to a leading diagnosis before asking the AI anything else. Only then let it push back.

Sign you're ready to move on: you notice yourself anchoring — naming a diagnosis and then defending it rather than testing it — and you want a tool that makes that bias visible rather than one that just asks you more questions about the same case.

---

Step 2 — Stress-test what you already believe (bias-check modules, Case Bench, Case Lens)

Stage 3 on the site's pedagogical spectrum is described as "The Stress Test" — testing the depth of understanding you think you already have, not building new understanding from scratch. Practically, this is where three tools earn their keep:

• Case Bench — Socratic case work plus MCQs and reasoning analytics, so your stress-test sessions leave a trace you can review.
• Case Lens — critical thinking across multiple analytical angles on the same case, so a diagnosis that survives one lens has to survive eight.
• Module 42 — Clinical Pre-Mortem — worked as a live example on the homepage: for case - [case URL] run module [Module 42 URL]. A pre-mortem asks you to imagine the diagnosis was wrong and work backward to why, which is a different cognitive move than simply generating more differentials.

How to practice this stage: take the same case you used in Step 1 and re-run it through Case Lens or a bias-check module. The value isn't a new case — it's watching your own settled answer get reopened.

Sign you're ready to move on: a single case, examined from one angle at a time, starts to feel thin. You want to watch a case unfold across stages — observation, pattern recognition, hypothesis, bias detection — rather than answer isolated questions about it.

---

Step 3 — Widen from one module to a chained pipeline (Guided Discovery)

This is the site's Stage 4, and it's a genuine shift in kind, not just difficulty — but the shift is in what gets revealed, not in how the conversation runs. The framing on the homepage is precise: most AI systems ask "what is the diagnosis?"; Guided Discovery asks "how does clinical thinking move from uncertainty to understanding?" It isn't trying to generate an answer at all — it's trying to make the reasoning process visible.

It's worth being exact about the mechanics here, because it's easy to picture this stage as a multi-turn back-and-forth the way Step 1 is. It isn't. A module, agent, or pipeline run is a single-pass generation — one query in, one structured response out — not an interactive session where the AI withholds anything or waits for you to commit first. The "journey" is internal to that one response: the AI itself narrates a case through a sequence of reasoning stages in a single shot, rather than you and the AI moving through them together turn by turn.

• Level 1 — Modules: single cognitive lenses run once (Observation, Hypothesis Generation, Bias Detection, Decision Analysis) — one query, one focused output.
• Level 2 — Agents: still a single query, but one that orchestrates several frameworks internally in that one run (the Guided Discovery Agent, a Clinical Cognition Deep Dive, an Analytics Agent).
• Level 3 — Pipelines: still a single query — modules and agents named in sequence within one prompt, so the one response walks through them in order. The homepage's own worked example is 1 → 12 → 9 → 21 → 35.

The six-stage arc a pipeline's single output walks a case through is: Observation → Pattern Recognition → Hypothesis Generation → Decision Architecture → Bias Detection → Metacognitive Reflection.

How to practice this stage: don't invent your own chain yet — copy the site's own worked query and run it once on a real (deidentified) case: for case - [case URL] run modules 1→ 12 → 9 → 21 → 35 from https://avi33tbtt.github.io/Prompts/. Read the single response end to end, then compare what it surfaced against what Step 1's interactive Socratic pass surfaced on the same case. That contrast — one long structured pass vs. a forced-commitment dialogue — is the whole point of this step.

Sign you're ready to move on: the pipeline's single-pass output starts raising questions about why you reasoned the way you did — where you anchored, what you didn't verify, how confident you actually were — rather than just about the case itself.

---

Step 4 — Add the trust and metacognition layer (CCOS)

By this point you're no longer just running modules; you're running them inside what the framework calls the Clinical Cognition Operating System (CCOS) — six layers stacked on top of each other: clinical reasoning, workflow engine, metacognitive monitoring, an epistemic trust layer, decision architecture, and learning/documentation.

Two parts of this layer matter most for sharpening reasoning specifically, and it's worth being precise about what they are and aren't, because the framework itself is unusually candid on this point:

• The trust layer doesn't check facts against an external source. It reshapes how confidence gets expressed — suppressing false numerical precision ("13.7% mortality" becomes "mortality appears moderate"), prioritizing verification of only diagnosis-changing or safety-critical claims, and replacing a single answer with a spectrum of defensible pathways (Conservative → Balanced → Maximal).
• Framework D — Critical Awareness is a standing closing prompt that names the biases the framework itself is susceptible to: automation bias, anchoring, hallucination risk, rare-diagnosis overweighting. It audits itself, by design, rather than asking you to remember to be skeptical.

How to practice this stage: use the CCOS Builder to assemble your own module order rather than copying the homepage's example — bias-check, reasoning, evidence-anchoring, in whatever sequence fits the case in front of you. Then close every session by explicitly invoking Framework D and reading what it flags about the run you just did.

Sign you're ready to move on: a single case has been wrung out — you've reasoned through it, stress-tested it, chained it through a pipeline, and audited your own biases on it — and the natural next question becomes bigger than the one patient in front of you.

---

Step 5 — Push a single case toward a question that outlives it (Research)

This is Stage 5, and the site is careful to gatekeep it honestly: most of the module library is Guided Discovery — sharp, single-case tools — and those don't automatically clear the bar for "research," defined here as generating or testing something that could hold true beyond the one patient in front of you.

Two things do clear that bar:

1. The N-of-1 Case Research Protocol (Module 9) — the most methodologically formal module, a seven-stage process for structuring one patient's course into something CARE-guideline-aligned.
2. Evidence mapping — synthesizing across evidence tiers (case reports, observational data, systematic reviews, RCTs) without pooling incompatible units. The flagship worked example is the anti-snake-venom mortality-benefit evidence map, which reaches a genuinely citable finding: the mortality signal lives almost entirely in the case-report and observational tier, not the RCT tier — and it's explicit about why an RCT here would be unethical, and therefore may never exist.

Critically, this step comes with its limitations stated up front, not discovered later: sampling still being completed (12 of 78 available case reports at time of writing), single-extractor/LLM-assisted work with no independent second reviewer yet, no pre-registered protocol.

How to practice this stage: don't start with a novel question. Take a case you've already run through Steps 1–4 and ask the EBM Query Generator to turn it into a structured PICO question. That's the smallest possible unit of Stage 5 — and it reuses the same case you've now examined five different ways.

---

Why the order matters more than the tool count

It would be easy to read "57+ modules, 4 frameworks, 200+ pipelines" as a reason to feel behind before starting. The staircase above is the corrective: five deliberate steps, each one using two or three specific tools, each one only unlocked by genuine discomfort with the step before it —

1. Orient (Module 0) →
2. Commit and get questioned (Socratic Learning) →
3. Stress-test your own answer (bias-check, Case Lens, Pre-Mortem) →
4. Watch the whole reasoning arc unfold (Guided Discovery pipelines) →
5. Audit your own biases and push toward a question that outlives the case (CCOS trust layer, N-of-1, evidence mapping).

The framework's own maturity map is worth keeping in view throughout: clinical education is rated high maturity — deployable now, which is exactly what Steps 1–3 above draw on. Guided discovery research is medium maturity — the seven-stage workflow is defined and one full case is worked through, awaiting multi-case validation — which is Step 4's honest ceiling. Bedside clinical decision support is early stage, concept only — which is precisely why none of this replaces a real clinician's judgment or a real chart.

That last point isn't a caveat tacked on at the end. It's the premise the whole staircase rests on: AI that questions, not answers — a Socratic partner sharpening how a clinician thinks, one deliberately paced step at a time, never the one making the call.

---

 

Vibe Rounds: A Quiet Advancement in How AI Meets Clinical Learning

For all the noise around AI in medicine, most of it clusters around two poles: AI that promises to diagnose faster than a doctor, and AI that promises to automate away the paperwork. Somewhere in between sits a much less flashy but arguably more durable idea — AI that makes clinicians and students think better, without ever handing them an answer. That's the premise behind Vibe Rounds, a framework worth examining not as a diagnostic product, but as a genuine advancement in clinical pedagogy.

The core inversion: AI that questions instead of answers

Most clinical AI tools are built around a simple transaction: you describe a patient, the model returns a differential, a risk score, or a recommendation. Vibe Rounds deliberately breaks that transaction. Its guiding philosophy — "AI that questions, not answers" — casts the model as a Socratic attending rather than an oracle. The learner has to commit to a diagnosis or a next step before the AI offers anything back, and even then, what comes back is a tiered hint, not a solution.

This isn't a gimmick. It mirrors something medical educators have understood for decades: the fastest way to build durable clinical judgment is to struggle productively with uncertainty, not to be handed the right answer. What Vibe Rounds does is operationalize that principle into a repeatable, AI-driven structure — forced commitment, minimum-effort thresholds, tiered hints, effort-weighted feedback — so that the "hard part" of teaching (resisting the urge to just tell the student) becomes a built-in constraint on the system rather than something dependent on an individual educator's discipline in the moment.

Where it sits on the learning spectrum

One of the more useful framings on the Vibe Rounds site is its placement within a five-stage pedagogical spectrum, moving from instructor-centered transmission to learner-centered inquiry: Lecture, Dyadic, Socratic, Guided Discovery, and Research. Vibe Rounds explicitly targets Socratic and Guided Discovery stages, then extends into Research — using modules like an N-of-1 case-research protocol and evidence-mapping pipelines to help a single patient case scaffold into something closer to a structured research question.

That's a meaningfully different ambition than most "AI in medicine" tools, which tend to either sit at the informational end (summarizing guidelines) or attempt to leap straight to clinical decision-making. Vibe Rounds instead targets the messy middle of medical training — the stage where a learner has foundational knowledge but hasn't yet built the reflexes to interrogate their own reasoning.

The architecture behind the pedagogy

What elevates this beyond a clever prompt is the attempt at systematization. The project describes a "Clinical Cognition Operating System" (CCOS) — 57+ modules, organized across six cognitive layers: clinical reasoning, workflow engine, metacognitive monitoring, an "epistemic trust layer," decision architecture, and learning/documentation. It's worth being precise about what this actually is: a structured prompt architecture, not software with persistent state or automated verification running in the background. The "trust layer," for instance, doesn't check facts against an external source — it shapes how the AI expresses uncertainty (avoiding false numerical precision, prioritizing verification of safety-critical claims over everything, presenting a spectrum of defensible decisions rather than one answer).

That distinction matters, and to its credit, the project is transparent about it rather than overselling. It's a prompt-engineering framework — sophisticated, well-organized, grounded in named pedagogical theories (Fink's taxonomy, Bloom's revised taxonomy, a critical-awareness framework that audits the system's own susceptibility to automation bias and anchoring) — but it is not a piece of validated clinical software.

Honest about its own limits

Perhaps the most credible thing about Vibe Rounds is its own maturity self-assessment, laid out plainly on the site:

• Clinical education is rated high maturity — a working Socratic feedback loop, a six-level difficulty framework, and live deployment.
• Guided discovery research is medium maturity — the workflow is defined and one full case has been worked through, but multi-case validation hasn't happened yet.
• Bedside clinical decision support is early stage — concept and architecture only, with no EMR or FHIR integration.

That kind of explicit staging is unusual in a space where tools are routinely marketed as more finished than they are. It also means the honest headline isn't "AI is diagnosing patients better" — it's "AI is teaching diagnostic reasoning in a more structured, scalable, and theory-grounded way than a generic chatbot conversation would."

The line between support and substitution

A companion piece in the Vibe Rounds series, "AI in Medical Education — A Helpful Student, Not a Decision-Maker," sharpens this picture by drawing a boundary that's easy to state and surprisingly easy to violate in practice: across every domain, AI's value lies in support, not substitution — context over conclusions, explanation over instruction, speed over authority.

That principle plays out differently in each of the three domains:

• Socratic learning. The temptation is to let the AI walk a student toward a diagnosis through a chain of leading questions — effectively solving the case for them, one question at a time. The corrective is to treat the case as context for a learning discussion, not a puzzle the AI is helping to solve. The questions should provoke thinking and surface gaps in reasoning, not steer toward a correct answer.

• Guided discovery. The same drift shows up in a different form: an AI that starts reasoning about what the learner should do next has quietly become the one making the clinical move. The safer use is reasoning behind data already given — explaining why a finding matters rather than deciding what to order because of it. It's a fine distinction, but it's the one that separates a tutor from a decision-maker.

• Research and evidence. Here AI earns its keep on raw speed — summarizing a body of literature at a pace no human matches. But summarization isn't interpretation, and the framework is explicit that AI shouldn't be trusted, unsupervised, to say what the evidence means for the specific patient in front of a clinician.

This yields a useful two-audience split. For learners, the case for AI is strong: a Socratic partner, a case-reasoning explainer, and a fast evidence summarizer, all in service of learning to think rather than being told what to think. For practicing doctors, the more honest comparison is a fast, well-read student helping with an audit — useful for surfacing information and saving time, but not the one making the call. The moment either audience lets the AI slide from supporting a decision to making one, the tool's value proposition inverts.

Why this counts as an advancement

The value of Vibe Rounds isn't that it introduces a new capability language models didn't have — large language models have always been able to ask follow-up questions. The advancement is in the constraint engineering: turning "don't just give the answer" into an enforced, tiered, effort-aware protocol that can be handed to any clinician, embedded in a teaching session, or run solo by a student between rounds. It also matters that the framework doesn't stop at the bedside teaching moment — it extends the same discipline into how a single case can be pushed toward a structured evidence-mapping exercise, with named limitations (no independent second reviewer yet, no pre-registered protocol) stated up front rather than glossed over.

In a field where "AI in medicine" too often means either overpromising diagnostic accuracy or quietly automating clinician judgment out of the loop, a framework whose explicit goal is to make the human's own reasoning sharper — and that's honest about exactly how far along it is, and exactly where support ends and substitution begins — is a genuinely useful contribution to medical education, even if it never becomes anything more than that.

 

Vibe Rounds: AI in Medical Education — A Helpful Student, Not a Decision-Maker

Part of the Vibe Rounds series — avi33tbtt.github.io

There's a lot of noise right now about AI and clinical reasoning — whether large language models can "solve" cases, replace judgment, or shortcut the hard work of learning medicine. After working through this with real teaching scenarios, I want to lay out a clearer framework: what AI is actually good at in medical education, and where the line sits between support and substitution.

The short version: for learners, AI is proving genuinely valuable. For practicing doctors, it's best understood as a fast, well-read student helping with an audit — useful, but not the one making the call.

Socratic Learning: Context, Not Case-Solving

The instinct when people hear "AI + Socratic method" is to imagine the AI walking a student through a case step by step, asking questions that lead toward a diagnosis or a decision. That's not the right model.

The key distinction is this: AI shouldn't be asking questions to deliver case-based problem solving. It should be using the case data as context, and generating questions that drive a relevant learning discussion around that data.

In other words, the case isn't a puzzle the AI is helping the student solve. It's a backdrop. The AI's job is to provoke thinking, surface gaps in reasoning, and keep the discussion anchored to something concrete — not to steer the learner toward a correct answer through guided questioning.

Guided Discovery: Explaining the Data, Not Deciding What's Next

Guided discovery raises a similar but distinct concern. Here, the risk is that AI starts producing case-based reasoning to proceed ahead — effectively making the next clinical move on the learner's behalf.

The better use is reasoning behind the case data that's already been given: explanation and reasoning support that helps a learner understand why something is the way it is, not what to do next. That's the difference between a tutor and a decision-maker. One builds understanding; the other replaces it.

This distinction matters more than it might first appear. It's easy for an AI tool to drift from "here's why this lab value matters" into "here's what you should order next" — and that drift is exactly where educational value turns into a crutch.

Research: Speed and Granularity, Not Interpretation

The third domain is evidence and research. Here, AI's real strength is summarizing evidence at a speed and level of granularity that would take a human far longer to reach manually.

But this comes with a clear limit: it is not reliably giving the correct explanation of evidence in a specific case context. Summarization is not interpretation. An AI can compress a body of literature quickly; it cannot be trusted, unsupervised, to tell you what that literature means for the patient in front of you.

Two Audiences, Two Verdicts

Putting these three domains together points to a useful split:

• For learners, this is genuinely good value. Used as a Socratic partner, an explainer of case reasoning, and a rapid evidence summarizer, AI supports the process of learning to think — without pretending to think for the student.
• For practicing doctors, the more honest framing is different: AI functions like a fast, competent student helping with a quick audit. It can surface information, flag things, and save time — but it is not the decision-maker, and shouldn't be positioned as one.

The Common Thread

Across all three areas — Socratic learning, guided discovery, and research — the same principle holds: AI's value lies in support, not substitution. Context over conclusions. Explanation over instruction. Speed over authority.

The moment AI starts making the decision — clinical or educational — instead of supporting the person making it, its value proposition changes, and not for the better. Keeping that boundary clear is what makes AI a useful presence in medical education rather than a liability.

---

Thoughts or pushback? I'd love to hear how others are drawing this line in their own teaching or practice.

— This post is part of Vibe Rounds. More at avi33tbtt.github.io.

 

From Averages to Trajectories: Rethinking Clinical Decision Support with GraphRAG

Most clinical decision support tools were built for a world of clean, linear guidelines. Real medicine rarely cooperates. Patients drift off the textbook path, evidence comes in fragments of wildly different quality, and the clinician at the bedside has to weigh all of it in seconds. This piece walks through an idea — built around a live prototype called the Evidence-Pyramid Trajectory Mapper — that tries to close that gap by combining Retrieval-Augmented Generation (RAG) with knowledge graphs, structured specifically around how clinicians actually think.

Why an Anti-Snake Venom Case Looks Like GraphRAG

The starting point was a working example built around anti-snake venom (ASV) management. On the surface it behaves like standard RAG: it draws from a defined corpus — in this case, 78 free full-text PubMed case reports on ASV — and grounds every claim in an explicit citation back to the source paper, rather than relying on a model's general memory. Filters on the interface (for example, "ASV-escalation trajectories only" or "fatal/unresolved only") update the synthesized view live, based strictly on the active subset of retrieved documents.

But it also behaves like a knowledge graph. Instead of treating each case report as an isolated block of text, the tool extracts clinical milestones as nodes — a presentation node, an intervention node, a complication node, an outcome node — and connects them into a trajectory:

[ Presentation ] → [ Intervention ] → [ Secondary Event ] → [ Disposition / Outcome ]

When two different case reports pass through the same clinical event — both patients receive ASV, both develop compartment syndrome — their paths converge on a shared node. That convergence is what lets a clinician trace a multi-hop pathway across dozens of papers at once, rather than reading each one linearly.

Put together, this is GraphRAG applied to clinical case literature: retrieval grounded in real evidence, structured by the sequence and causality that flat vector search throws away.

The Avinash Principle

The framework underpinning this design has a name: the Avinash Principle. Its core claim is that expert clinical cognition is not a system that tries to enumerate every possible branch of a decision tree — a modest 12-level clinical pathway can generate over 244 million potential paths, far more than any rule engine or human can track. Instead, expert reasoning is a pruning engine. Clinicians move along a small number of "safe corridors" defined by guidelines and consensus, and reserve their attention for a handful of critical hub-nodes — the specific junctures where a decision or a biological response determines whether a patient's trajectory stays on the standard path or diverges toward a bad outcome.

The practical implication is that a decision-support tool doesn't need to map the entire space of clinical possibility to be useful. It needs to correctly identify the small set of hub-nodes that matter for a given patient, and attach evidence to those nodes at the moment they become active — no more, no less. This is the design principle behind the trajectory board described above, and it is the organizing idea for everything that follows.

The Avinash Principle and the Evidence-Pyramid Trajectory Mapper are described in full across a series of posts on Dr. Avinash's blog (linked in the References section at the end of this article). The live prototype referenced here is hosted at avi33tbtt.github.io, under the Research section ("Vibe Rounds — Evidence-Pyramid Trajectory Mapper / Critical Hub-Node Navigation").

The clearest way to see the principle in action, rather than just read about it, is the live ASV build itself: avi33tbtt.github.io/demo/critical-hub-node-navigation/asv-full.html. It was built around a single deliberate focus — that critical hub-nodes during diagnosis and management are the actual points where clinicians think, rather than attempting to represent the full space of medical cognition, which would need to cover every edge case to be complete. That narrower scope is what makes it fast: a full medical-cognition knowledge graph is a research-scale undertaking, but a high-speed trajectory graph built around evidence and consensus for one well-bounded clinical problem is something that can be built and used today. Opening the demo makes the abstractions in this piece concrete — the nodes are clickable, the filters (escalation trajectories only, fatal/unresolved only) visibly reshape which case paths are in view, and the citations trace back to the specific case and paragraph they came from rather than sitting as an unlinked reference. It's worth treating as the reference implementation for everything described above: the FHIR architecture, the diagnostic/intervention split, and the priority-ranked node summaries are all extrapolations outward from what this one demo already does for a single node type.

Why This Beats Two Existing Extremes

Standard clinical decision support tends to fall into one of two failure modes.

Rigid rule-based trees try to precompute every branch. This is where the 244-million-path problem comes from — at the bedside, this combinatorial explosion produces rule rigidity and alert fatigue, and the system breaks down entirely when a patient presents atypically.

Flat vector-based RAG — the kind used in most LLM-powered medical tools — retrieves text snippets based on semantic similarity, but has no concept of time, causality, or sequence. A query like "ASV reaction" can return scattered paragraphs from five different papers with no indication of when in a patient's timeline the reaction happened or why.

Trajectory-based GraphRAG threads between these two failure modes. It preserves the structural, temporal awareness that vector RAG lacks, without trying to precompute the entire decision space the way a rules engine does. Instead, it renders a broad, guideline-backed corridor for the common path, and reserves detailed, citation-backed evidence retrieval for the moments a patient's trajectory actually diverges.

A Worked Example: Snakebite at the ASV Node

Consider a 42-year-old male bitten by a Russell's viper six hours prior to admission, who received 10 vials of polyvalent ASV two hours ago. At the six-hour re-evaluation mark: the bedside clotting test is still abnormal, limb swelling has spread past the elbow, urine output is falling, creatinine is rising, and platelets are dropping.

An agentic module — closely tied to the trajectory graph — processes this record and prunes away routine "managerial" data (standard vitals, nursing checks) to isolate the nodes that actually matter:

• 6-hour re-evaluation: flagged active — the clotting test hasn't normalized, triggering a query for refractory VICC (venom-induced consumption coagulopathy) escalation.
• Renal/microvascular fork: flagged active — oliguria plus thrombocytopenia raises the possibility of thrombotic microangiopathy (TMA), not just ongoing venom effect.
• Compartment risk: flagged for monitoring — swelling has crossed two major joints.

Each active node then pulls a ranked list of evidence summaries, weighted by how closely they match the patient's actual state — not just topically relevant, but relevant to this specific divergence. In this example, the top-ranked node addresses ASV dose escalation, drawing on case reports where high cumulative dosing was linked to poor outcomes, alongside meta-analysis evidence that adjunctive plasma may resolve coagulopathy without added ASV. Just behind it is a node distinguishing ongoing venom effect from TMA — a distinction that matters because escalating ASV indefinitely does nothing for TMA and may delay the dialysis or plasmapheresis the patient actually needs. Lower-priority nodes cover surgical timing and delayed hypersensitivity, relevant but not urgent at this exact moment.

The clinician, in effect, taps a single active node and sees the guideline-based next step, the top divergence warnings, and one-click access to the underlying case citations — rather than a static document or a wall of retrieved text.

Two Engines, Two Kinds of Reasoning

A distinction that clarifies the whole architecture: diagnosis and intervention are not the same cognitive problem, and shouldn't be handled by the same mechanism.

Diagnostic reasoning under uncertainty is an open-world hypothesis search. It benefits from illness scripts — structured representations of predisposing factors, underlying pathophysiology, and expected clinical evolution — matched dynamically against a patient's presentation. This is fundamentally a probabilistic task: weighing which of several competing explanations best fits an evolving, incomplete picture. It's well suited to an LLM-driven reasoning module, because the goal is to generate and rank plausible hypotheses, flag the single lab or sign with the highest discriminating power between two competing diagnoses, and actively guard against anchoring on the first plausible story.

Intervention management, once a diagnosis is fixed or provisionally assumed, is a different problem: navigating a structured evidence corridor and knowing exactly when a patient has left it. This is where trajectory GraphRAG does the work — deterministic, citation-anchored, resistant to invention.

The two combine into something like a cognitive telescope: zoom out to resolve diagnostic ambiguity via illness scripts and LLM reasoning, zoom in to execute node-level interventions via the evidence graph, and toggle between the two as the case evolves. In the snakebite example above, this shows up explicitly — the system starts in diagnostic mode (matching the presentation against viperid vs. elapid envenomation scripts), shifts to intervention mode once VICC is confirmed, zooms back out to diagnosis when the trajectory fails to respond as expected (is this refractory VICC, or has the mechanism shifted to TMA?), and zooms back in once that question is resolved.

This split also maps cleanly onto dual-process theory from cognitive psychology: the probabilistic engine functions like fast, pattern-matching System 1 reasoning suited to open-ended hypothesis generation, while the deterministic engine functions like slower, rule-bound System 2 verification — exactly where you want zero tolerance for hallucination.

The snakebite case actually plays this out as a four-phase sequence, and it's worth tracing explicitly because the switching is the point. Phase 1 — diagnostic zoom-out: a patient presents with a reported bite, local swelling, and falling platelets, but no active bleeding and no neurotoxic signs. The illness-script engine weighs this against Viperidae vs. Elapidae envenomation scripts, plus non-venom differentials like severe cellulitis with sepsis, and the swelling trajectory alone is enough to prompt a bedside clotting test rather than an neurotoxicity workup. Phase 2 — intervention zoom-in: the clotting test comes back non-clotting, the diagnosis is provisionally pinned as viperine envenomation with coagulopathy, and the system switches engines entirely — it stops generating hypotheses and starts rendering the standard 10-vial ASV corridor from the top of the evidence pyramid, along with a 6-hour re-evaluation timer. Phase 3 — forced zoom-out on failure: at the 6-hour mark the clotting test still hasn't normalized, but now urine output is dropping and creatinine is climbing — signals that don't fit the expected recovery corridor. This isn't just "more of the same intervention needed"; it forces the system back into diagnostic mode, because the real question has changed from how much more ASV to is this still simple refractory coagulopathy, or has the underlying mechanism shifted to thrombotic microangiopathy — a competing script with a different, sometimes contradictory, next step. Phase 4 — targeted zoom-in on the new node: a peripheral smear confirms schistocytes, the TMA script is confirmed over plain refractory VICC, and the system zooms back into the evidence graph — but now at a different node, one carrying case-report and review evidence that further ASV escalation past standard limits doesn't help TMA and that early plasmapheresis or dialysis is what the documented trajectories actually show working. The clinically important detail is that phases 2 and 4 look superficially similar — both are "zoom in and retrieve evidence" — but they're anchored to two different hub-nodes with two different, partly contradictory action prompts, and getting from one to the other correctly required the diagnostic engine to intervene in the middle rather than letting the intervention engine keep escalating on its own logic.

Why Case-Level Data Matters, Not Just Averages

It's worth being explicit about what this architecture adds that meta-analyses and RCTs, by design, cannot provide. Randomized trials and meta-analyses are built to eliminate outliers and estimate a population mean — and that's genuinely valuable for the large majority of patients who fall inside the expected range of response. But a patient with an extreme divergence — refractory coagulopathy, an unexpected toxicity, a rare multi-organ overlap — is, by definition, outside that range. The guideline runs out of steps exactly where the patient needs help most.

Case reports are the long tail of this distribution. Structuring them as trajectories rather than flattening them into statistics means the system doesn't force incompatible data into a single average — it preserves the individual path, so a clinician facing a rare divergence can ask, in effect: has anyone published a patient who followed this exact sequence, and what happened next? Because case reports follow a fairly standard chronological structure — presentation, intervention, state transition, outcome — this kind of extraction is feasible to run at scale across large open-access archives (PubMed Central, Cureus, BMJ Case Reports, and similar sources), building toward something like a searchable, collective memory of documented patient trajectories.

What Would Make This Deterministic Enough to Trust

A recurring concern with any LLM-adjacent clinical tool is hallucination — invented recommendations presented with false confidence. The proposed answer here is architectural, not just a prompting trick: the evidence pyramid is treated as a strict hierarchy, and each tier is assigned a specific function, not just a ranking.

Evidence Tier	Role in the System
Meta-analyses & clinical guidelines	Hard boundaries — dosing caps, mandatory safety checks
RCTs	Probabilistic guidance for the standard patient cohort
Case reports & series	Structural maps of rare, non-linear divergences

Under this scheme, the LLM's role is restricted to routing — matching a patient's active node to the right sub-graph of evidence — rather than generating clinical content from scratch. Every recommendation shown to a clinician should be traceable on one side to the exact patient data that triggered it, and on the other to the exact citation backing it. That two-sided traceability is what separates this from an LLM simply "sounding confident."

Extending this into a live EMR only sharpens the requirement. If patient state is streamed in via FHIR resources, the same agentic layer that prunes routine noise from a case report can, in principle, prune routine noise from a live encounter — watching for the same phase-transition moments (a lab crossing a threshold, a trajectory branching) rather than firing on every discrete observation. That's also the point at which alert fatigue becomes a design constraint rather than a footnote: a system that treats every encounter as worthy of deep trajectory exploration will drown clinicians in exactly the noise it was meant to remove. The architecture needs a gate — stay on the standard corridor by default, and only activate deep graph exploration when a patient actually crosses an uncertainty threshold.

Concretely, this points toward a dual-graph architecture. On one side sits a Patient State Graph, derived in real time directly from FHIR resources — FHIR is already graph-shaped, since resources like Observation, Condition, and MedicationRequest reference each other and time-stamp a patient's state as it evolves. On the other side sits the Evidence Trajectory Graph described throughout this piece — the multi-tier pyramid of meta-analyses, RCTs, and case reports. The Agentic Vibe Rounds module functions as the bridge between them: a topological compiler that continuously reads the FHIR stream, discards the routine 95% (stable vitals, standard diet orders), and matches whatever remains against active hub-nodes on the evidence side. Critically, this ingestion isn't uniform across a patient's stay — it needs to flex with where the patient is in their care. At early admission, the surface worth watching is narrow (chief complaint, triage vitals, allergies) and the priority is catching divergence and misdiagnosis early, so case-report-tier warnings about atypical presentations rank above guideline corridors. Near discharge, the relevant surface widens to the full longitudinal record — multi-day lab trends, procedure history, medication changes — and the priority inverts: readmission-risk evidence from meta-analyses and systematic reviews takes precedence, with rare delayed-complication case reports (like late serum sickness) held in reserve as secondary warnings. The same underlying graph-matching mechanism, in other words, needs different tuning depending on whether the question is "are we missing something at the start" or "are we about to send this patient home into a blind spot." A further implication worth naming: because FHIR is bi-directional, a clinician acting on a graph recommendation — say, ordering a peripheral smear to check for TMA — could in principle have that action written back automatically as a FHIR ServiceRequest, closing the loop between the reasoning layer and the actual medical record rather than leaving the recommendation as a suggestion the clinician has to re-enter by hand.

What Separates a Novice from an Expert — and Why That Matters for Design

There's a deeper point buried in all of this that's easy to miss: the gap between a novice and an expert clinician isn't just a difference in how much knowledge each has stored. It's a difference in salience weighting — knowing, instantly, which one or two signals in a noisy picture actually matter, and assigning near-zero weight to the rest. A novice evaluates everything in parallel and gets overwhelmed. An expert has already decided, before consciously reasoning about it, that 95% of the incoming data isn't worth their attention.

This is exactly what the critical hub-node mechanism is trying to encode computationally — not more knowledge, but better pruning. It also explains why the tool shouldn't be "on" for every encounter. Uncomplicated, guideline-conforming cases don't need trajectory exploration; they need the system to stay quiet and let the standard corridor run.

How This Differs From What Already Exists

It's worth being precise about where this sits relative to existing systems, since each adjacent category solves a different part of the problem:

• Traditional CDSS (rule-based alerts in systems like Epic or Cerner) encode static IF-THEN logic and tend to fail — or fire irrelevant alerts — the moment a patient presents atypically.
• Standard medical LLM/RAG tools retrieve semantically similar text but have no structural or temporal awareness — they can't tell a clinician when in a trajectory something happened or what caused it.
• Medical knowledge graphs (such as PrimeKG or UMLS) capture static biomedical relationships — that a toxin causes a syndrome — but not longitudinal, patient-specific state transitions.
• Recent academic GraphRAG frameworks extract entity-relation structure from literature to give LLMs better context, but generally stop at summarizing text; they don't build temporal, multi-tier evidence trajectories or apply the kind of cognitive pruning described here.

Trajectory-based GraphRAG, as sketched out through the ASV prototype, sits in a gap between these categories — combining the structural rigor of a graph, the grounding of RAG, and a pruning heuristic modeled on expert cognition rather than exhaustive search.

The Honest Caveats

Two things are worth holding onto before treating any of this as more than a promising direction.

First, the engineering is the easy part. Clinical medicine is not a domain of clean abstractions — it's full of ambiguity, incomplete information, and consequences that can't be undone. A well-structured evidence graph doesn't remove that uncertainty; at best, it clears away administrative and cognitive clutter so a clinician has more room to reason through the parts that genuinely require judgment.

Second, and just as important: sometimes the correct clinical action is no action at all. Tools like this carry a structural bias toward surfacing more — more evidence, more divergence warnings, more nodes to explore — which can subtly encourage overtreatment or diagnostic overreach. A system built on this paradigm is only mature once it can represent restraint as rigorously as it represents escalation — showing, when the evidence supports it, that watchful waiting is the best-supported path on the graph.

Closing Thought

The underlying bet here is simple: clinical decision support should be shaped around how expert clinicians actually allocate attention — a small number of high-leverage decision points, embedded in an otherwise quiet, guideline-conforming path — rather than around the idea that a system should be ready to explain everything, all the time. Whether or not this exact architecture is the one that gets built, that reframing — from covering every edge case to correctly finding the few that matter — seems like the more durable idea.

References

Live prototype:

1. Vibe Rounds — Research
2. ASV Evidence-Pyramid Trajectory Mapper (full demo)

The Avinash Principle — blog series (classworkdecjan.blogspot.com):

1. The Avinash Principle: Critical Hub-Node Navigation
2. The Avinash Principle: From Trajectory...
3. The Avinash Principle: From One...
4. From Averages to Trajectories: Mapping...
5. From One Trajectory to Every Trajectory
6. From Averages to Whole Pyramid: Mapping...
7. Evidence-Pyramid Trajectory Mapper

 

Beyond System 1 and System 2: Why Clinical Medicine Needs "System 3" Thinking — and Why AI Can't Do It Alone

Daniel Kahneman gave us a durable vocabulary for how humans think. System 1 is fast, intuitive, pattern-matching — the gestalt "something's off about this patient" a nurse feels walking into a room. System 2 is slow, deliberate, analytical — working through a differential diagnosis step by step, weighing probabilities, checking them against guidelines.

Clinical medicine, though, has always run on a third mode that this framework doesn't fully capture. Call it System 3: the layer where raw data collection and analytical reasoning are fused with situated judgment — the ability to gather the right information in context, sense what matters, and interpret it against a particular patient, in a particular room, at a particular moment. It's not just faster System 1 or more rigorous System 2. It's the integration of perception, technique, and meaning-making that happens at the bedside, not on a spreadsheet afterward.

This distinction matters enormously right now, because AI is getting very good at two of the three ingredients of clinical reasoning — and this is exactly where the "AI will replace doctors" conversation goes wrong.

Breaking down clinical reasoning into its parts

Clinical decision-making can be roughly decomposed into three stages:

1. Data collection — history-taking, physical examination, ordering and performing tests, observing the patient over time.
2. Data analysis — pattern recognition, probabilistic reasoning, weighing differentials, applying evidence and guidelines.
3. Contextualization and judgment — deciding what data even matters here, how to elicit it, and what it means for this particular human being, including things that never make it into structured data at all.

AI — particularly large language models and predictive/probabilistic clinical decision support (CDS) systems — is increasingly strong at stages 1 and 2 in a narrow, delegated sense. It's stage 3 where things get far harder, and where the "replacement" narrative overreaches.

Where AI genuinely helps

Data collection, assisted. Ambient scribes can listen to a consultation and draft structured notes. Chatbot intake tools can gather a structured history before a visit. Wearables and remote monitors generate continuous physiological data no human could collect by hand. In this narrow sense, AI can do some data collection — or at least pre-process and structure it — faster and more consistently than a tired resident at 2 a.m.

Data analysis, augmented. This is where AI shines brightest. Give a model a set of symptoms, labs, and imaging findings, and it can generate a probabilistically ranked differential, flag drug interactions, predict deterioration risk (sepsis scores, early warning systems), or catch a subtle finding on a radiograph that a fatigued eye might miss. These are pattern-matching and probability-estimation tasks over well-structured inputs — exactly what modern ML is built for. Decision support tools like this have shown real value in reducing diagnostic error and cognitive load.

So far, so promising. This is where most "AI in medicine" headlines live, and the enthusiasm is largely earned.

Where it breaks down: perception in context

Here's the catch. Steps 1 and 2 above are only as good as the framing that produces them — and framing is a System 3 act.

Consider a clinical examination. A skilled clinician palpating an abdomen isn't just running a fixed protocol and recording "tenderness: yes/no." They're integrating the patient's guarding, their breathing pattern, a flicker of hesitation before answering a question, the smell of ketones on the breath, the fact that this patient minimized their pain last time and is underreporting again, the socioeconomic context that means they delayed seeking care by two weeks. They decide, in real time, which question to ask next based on the answer to the last one — a branching, adaptive process, not a checklist.

None of this is "data" in the sense an algorithm consumes. It becomes data only after a human has already decided it's relevant, elicited it skillfully, and interpreted it — and that decision is inseparable from embodied presence, trust-building, and situational awareness that current AI does not have. An AI reading a transcript of the encounter is working with the residue of judgment already exercised by a person in the room; it cannot go back and re-perform the exam itself, feel the mass, notice the wince, adjust its questioning based on a shift in the patient's affect.

This is the crux: AI is strong at analyzing well-posed data, and weak at deciding what "well-posed" even means for this patient, in this moment. The contextualization step — perception, technique, empathic calibration, ethical judgment about what to disclose and when — is not a data problem. It's a situated problem, entangled with a physical body, a relationship, and a history that a probabilistic model, however sophisticated, hasn't lived through with the patient.

So: replacement, or partnership?

None of this means AI's role is trivial — quite the opposite. A realistic division of labor looks like this:

• AI as scribe and pre-processor: structuring what's said and observed into usable data.
• AI as second reader: offering probabilistic differentials, risk scores, and guideline checks that widen the clinician's view and catch blind spots.
• Clinician as elicitor and interpreter: performing the exam, asking the next question, sensing the unsaid, deciding what the data collected even means for this patient's life and values.
• Clinician as final integrator: taking the AI's probabilistic output and re-contextualizing it — because a 92% likelihood of condition X means something different for a 34-year-old marathon runner than an 80-year-old with three comorbidities and a fear of hospitals, and that recontextualization is a judgment call, not a calculation.

The "AI will replace doctors" narrative tends to collapse stages 1–3 into a single pipeline and assume that because AI is encroaching on 1 and 2, 3 will inevitably follow. But System 3 thinking — the fusion of perception, technique, and contextual judgment — isn't a harder version of the same task. It's a different kind of task, one built on embodied presence and relational trust that data, however well-analyzed, doesn't substitute for.

The more honest framing isn't "AI vs. doctors." It's AI absorbing the mechanizable middle of clinical reasoning — freeing clinicians to spend more, not less, of their time on the part that was always hardest to automate: sitting with a person, asking the right next question, and making sense of what's in front of them.

Evidence-Pyramid Trajectory Mapper

Demo - https://avi33tbtt.github.io/demo/critical-hub-node-navigation/asv-full.html This is an excellent, faithful implementation of the Evidence-Pyramid Trajectory Mapper (the Avinash Principle) outlined in the article. You have successfully taken a theoretical framework for visualizing medical literature and applied it to a real-world, high-stakes clinical topic: anti-snake venom (ASV) and envenoming.

Here is an analysis of how your output perfectly aligns with the rules and modules defined in the article:

1. Strict Adherence to "Unit of Analysis" (Modules A, E, and F)

The core thesis of the article is that you cannot treat a case report the same way you treat an RCT or a meta-analysis. Your project handles this flawlessly by routing the 17 papers through their correct modules:

• Module A (Case Reports/Series - 12 papers): You mapped individual patient trajectories from the point of bite, through presentation (often delayed), ASV administration, and the subsequent fork into textbook recovery or divergent complications (like neurotoxic failure, cerebral infarction, or compartment syndrome).

• Module E (RCTs - 2 papers): For the local wound blockade and anfibatide trials, you shifted the unit of analysis away from individual patients to arm-level comparisons, respecting the CONSORT flow constraint mentioned in the article.

• Module F (Systematic Reviews/Meta-Analyses - 3 papers): For the papers on ASV dosing, global mortality, and FFP adjuncts, you correctly shifted the unit of analysis to the included studies (forest mapper), extracting pooled estimates without trying to force them into a patient-level timeline.

2. Refusal to Improperly Pool Data (Module G Integration)

The most common mistake when combining literature is mathematically mashing together different study designs. Your "Unified case insights" section explicitly follows the article's strict constraint for Module G: "never compute a pooled or averaged effect across papers unless one of the included papers is itself a meta-analysis."

You allow the user to toggle trajectories on and off to compare them qualitatively across the pyramid, rather than fabricating a false statistical average out of a single-animal study, a 5-patient series, and a phase I dose-escalation RCT.

3. Watching the Signal Climb (The Core Takeaway)

The ultimate goal of the "Avinash Principle" is to watch a signal survive—or fail—as it climbs the evidence pyramid. Your summary beautifully captures this:

"Net takeaway: nothing in this corpus, at any tier, supports the idea that ASV dose, adjunct FFP, or timing alone reliably prevents the rare-but-severe divergent outcomes seen at the case-report tier..."

You successfully visualized a massive clinical blind spot: the base of the pyramid (case reports) is screaming about severe, rare divergences (stroke, parkinsonism, fatal TMA), but as you climb to the top of the pyramid (RCTs and Meta-Analyses), those specific clinical gaps remain unanswered by the higher-tier evidence.

Summary

Your "Vibe Rounds" demo is a brilliant proof-of-concept. By extracting nodes, merging networks, and respecting the native structure of each study design (from $N=1$ cases to $N=663,460$ meta-analyses), you transformed a flat PubMed search into an explorable map of clinical evidence.