From Averages to Trajectories: Mapping Case Series with the Avinash Principle

Case series and case reports are usually read one patient at a time, then summarized into a table of aggregate percentages — X% had complication Y, median time to Z was N hours. Something gets lost in that flattening: the actual shape of how patients diverge from each other, and the specific checkpoint where a "normal" case turns into an outlier.

The Avinash Case-Series Trajectory Mapper is a small, focused extension of the Avinash Principle — the idea that expert clinical cognition doesn't calculate every branch of a decision tree, it prunes toward the handful of hub nodes that actually carry the trajectory's gravity. Applied to a single patient, that principle finds the 1% of nodes that matter for this case. Applied to a case series, it does something slightly different: it merges many patients' node chains into one network, so the textbook path and the outlier forks become visible side by side, as a picture instead of a table.

Three demo runs of the tool show what that looks like at three different levels of data quality — from rich individual trajectories, down to a published research paper that only reports aggregates.

How the mapper actually works

The tool runs a fixed three-step pipeline, laid out in the working prompt:

1. Extract nodes per patient. Each case is compressed into 3–6 key events — a presentation node, a decision/intervention node, a reaction/complication node, a disposition node — never the full chart, only the events that would have changed the trajectory's direction if they'd gone differently. Time, objective values, and narrative/behavioral detail are captured at each node where the source reports them, and marked explicitly as missing where it doesn't.
2. Merge into a network. Structurally equivalent nodes across patients get clustered into shared nodes. Edges are weighted by how many patients' paths pass through them. This surfaces the hub nodes (highest connectivity), the textbook path (the single highest-density route through the network), and the outlier paths — with the exact node and variation layer where each divergence happens.
3. Render an interactive network. Node size encodes hub weight, edge thickness encodes shared-path frequency, and clicking a patient thread lights up their individual trajectory against the textbook path for direct comparison.

The one constraint that matters most, and the one the demos take seriously, is this: don't fabricate patient-level data the source doesn't contain. If a paper only gives aggregate percentages, the tool is required to say so plainly rather than quietly inventing joint trajectories that look more granular than the evidence actually supports.

Demo 1 — deeper data, real individual threads

mapping1.html runs the mapper against four unrelated cases pulled from individual e-log-book case discussions — a general presentation, a pancytopenia workup that turns into an outlier, an AKI-on-CKD case, and a CKD-on-MHD case. Because each source is a full narrative case write-up rather than a summary table, the mapper can extract genuine patient-level chains: real timestamps, real lab values, real narrative detail, for each of the four patients individually.

That's what "deeper data" buys here — the interactive plot can legitimately highlight a single patient's thread woven through the shared network and show, node by node, exactly where the pancytopenia case forks away from the more common path. The green highlighted route marks the textbook path; red marks outlier divergence; node size marks hub weight; edge thickness marks how many patients actually passed through that checkpoint. Nothing in this version is synthetic — every node traces back to a real, individually reported case.

Demo 3 — superficial data, the same structure with thinner evidence

mapping3.html takes the same pipeline and applies it to another set of unrelated cases — but this time the underlying write-ups are thinner: less granular timing, fewer objective values, sparser narrative context per checkpoint. The network still renders, the hub nodes and textbook path still emerge, but the honest thing the tool has to do here is show less confidence at each node — smaller variation spreads not because the disease is more homogeneous, but because the source material didn't report enough to characterize the spread.

Side by side, mapping1 and mapping3 make a point that's easy to miss when you only ever see one finished diagram: the same tool, run faithfully, produces different amounts of real signal depending entirely on what the underlying case reports actually contain. A trajectory map is only as deep as its source data — it can't manufacture granularity that was never written down.

Demo 2 — a published case series, and the limits of aggregate data

mapping2.html is the most instructive of the three, because it runs the mapper against something categorically different: a real, published, peer-reviewed case series — Strokes following snakebite envenomations: A systematic review and individual patient data meta-analysis (Almeida et al., PLoS Neglected Tropical Diseases, 2025), pooling 130 cases of stroke following snakebite.

Here the mapper runs directly into the constraint it's built to respect. The paper reports its 130 pooled cases almost entirely as aggregate frequencies across Tables 1–5. True individual, linked patient trajectories exist for only six fatal autopsy cases, tabulated separately in Table 6 — a Notechis scutatus bite, a Viperid case complicating into endocarditis, a C. o. helleri envenomation, a Bothrops atrox bite, a Daboia russelii case, and a Viperid bite with massive intracerebral hemorrhage.

The resulting map is explicit about this two-tier reality rather than blurring it:

• The six fatal cases are rendered as genuine, individually threaded patient paths — real trajectories a user can click through and trace node by node, exactly as in mapping1.
• The rest of the network — the grey and blue "population" nodes — represents sequential clinical checkpoints weighted by their marginal reported prevalence across the full 130-case cohort. The mapper is careful to label this for what it is: not a verified joint trajectory for the other 124 patients, because the paper's individual-level supplementary data wasn't available in the source document provided. Node weights are marginal percentages against whatever denominator each variable was actually reported against — n=130, n=111, n=102, n=117 — and those denominators are surfaced in the hover text rather than smoothed over.

This is the mapper doing exactly what its constraint demands: building the best network the paper's data can actually support, and drawing a hard line between the real threaded outliers and the population-level scaffolding around them — instead of quietly presenting 130 fabricated individual journeys that the source paper never actually gave it.

Why the distinction matters

Put the three demos next to each other and a single lesson falls out cleanly: a trajectory map is not a picture of the disease — it's a picture of the disease as far as the evidence lets you see it. Rich individual case narratives (mapping1) let hub nodes and outlier forks be traced with real confidence. Thinner case write-ups (mapping3) still produce a usable network, but an honest one shows its lower resolution rather than papering over it. And a published aggregate case series (mapping2) forces the sharpest discipline of all: report what's genuinely patient-linked, and clearly separate it from what's merely population-weighted scaffolding built to keep the rest of the network readable.

That discipline is the whole point of building this as a case-series extension of the Avinash Principle rather than a single-patient tool. The original principle is about a clinician pruning 60 million theoretical decision paths down to the 1% of nodes that matter for one patient in real time. This extension asks a related but distinct question: across a whole published cohort, where do individual patients' trajectories actually overlap into a real textbook path, and where does a paper's own reporting granularity quietly stop telling you the truth about any single patient at all? Getting that second question right — refusing to fabricate joint trajectories the source never gave you — is what keeps a trajectory map a genuine training tool instead of a confident-looking fiction.

Try it yourself

• Demo 1 — deeper individual case data
• Demo 2 — published case series (PLoS NTD, stroke-after-snakebite)
• Demo 3 — superficial/thin case data
• The working system prompt, if you want to run it against a case series of your own

And for the underlying framework these all extend:

• The Avinash Principle: Critical Hub-Node Navigation
• The Avinash Principle: From Trajectory...
• The Avinash Principle: From One...

As with the single-patient version of this framework, none of this is meant to be read as ground truth about the underlying diseases. It's a sparring partner for building the specific, learnable skill of spotting real hub nodes and honestly distinguishing them from artifacts of thin reporting — not an answer key, and not a substitute for reading the primary literature itself.