schematex 0.4.0 → 0.4.1

package/dist/{chunk-7LNIBHO6.cjs → chunk-WCAADEXJ.cjs}

@@ -1,6 +1,6 @@
 'use strict';
 
-var chunkO2HN4WRG_cjs = require('./chunk-O2HN4WRG.cjs');
+var chunkDHHVYSQX_cjs = require('./chunk-DHHVYSQX.cjs');
 
 // src/ai/registry.ts
 var DIAGRAM_REGISTRY = [
@@ -439,6 +439,43 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'circuit "CE Amp (netlist)" netlist\nV1 vcc 0 9V\nRc vcc c 2.2k\nRb vcc b 100k\nQ1 c b e npn\nRe e 0 1k',
     "notes": '## Scenario\n\nThe NPN common-emitter amplifier is the first transistor circuit every electronics student builds. Schematex renders it from a five-line SPICE netlist \u2014 the same format used in LTspice, ngspice, and Cadence \u2014 with automatic component placement and rail routing, so the diagram matches the hand-drawn textbook version without any manual layout.\n\n## Annotation key\n\n- `circuit "..." netlist` \u2014 enables netlist parsing mode (SPICE syntax)\n- `V1 vcc 0 9V` \u2014 voltage source named V1, positive terminal at node `vcc`, negative at `0` (ground), value 9V\n- `Rc vcc c 2.2k` \u2014 resistor Rc between nodes `vcc` and `c` with value 2.2 k\u03A9\n- `Rb vcc b 100k` \u2014 base bias resistor between `vcc` and node `b`\n- `Q1 c b e npn` \u2014 NPN BJT transistor: collector=c, base=b, emitter=e\n- `Re e 0 1k` \u2014 emitter degeneration resistor between node `e` and ground\n\n## How to read\n\nThe supply rail (Vcc = 9 V) connects to the top of both resistors. Rc is the collector load; the output signal is taken across it. Rb biases the base into the active region. Re provides emitter degeneration for stability. Q1 amplifies a small base current into a large collector-to-emitter current flow. The auto-layout positions Vcc at top, ground at bottom, and Q1 in the center.'
   },
+  {
+    "slug": "decisiontree-buy-vs-lease-ev",
+    "diagram": "decisiontree",
+    "title": "Buy vs. lease an electric vehicle",
+    "description": "Howard-Raiffa expected-value tree for the buy/lease/used-EV decision \u2014 with resale probability and incentive chance nodes.",
+    "standard": "Raiffa & Schlaifer (1961)",
+    "tags": [
+      "decision-analysis",
+      "ev",
+      "buy-vs-lease",
+      "expected-value",
+      "consumer"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'decisiontree:decision "EV Acquisition Decision"\n\ndecision "Which acquisition path?"\n  choice "Buy new EV"\n    chance "Federal tax credit eligible?"\n      prob 0.7 chance "Resale market in 5yr (w/ credit)"\n        prob 0.55 end "Strong resale + credit" payoff=28500\n        prob 0.45 end "Weak resale + credit" payoff=16000\n      prob 0.3 chance "Resale market in 5yr (no credit)"\n        prob 0.55 end "Strong resale, no credit" payoff=21000\n        prob 0.45 end "Weak resale, no credit" payoff=8500\n  choice "Lease EV 3yr"\n    end "Predictable lease cost" payoff=14000\n  choice "Buy used EV"\n    chance "Battery health \u2265 80%?"\n      prob 0.6 end "Good battery \u2014 low TCO" payoff=22000\n      prob 0.4 end "Battery replacement needed" payoff=8000',
+    "notes": '## Scenario\n\nA household is choosing between three electric vehicle acquisition paths: buying new (eligible for a $7,500 federal tax credit with 70% probability, depending on income and vehicle MSRP cap), leasing for three years at a fixed all-in cost, or buying used. The buy-new path carries two sequential chance nodes \u2014 credit eligibility then a five-year resale market outcome \u2014 while used carries battery-health uncertainty. Payoffs represent net five-year economic value (savings versus equivalent ICE ownership, residual value, minus acquisition and maintenance costs).\n\n## Annotation key\n\n- `decision "\u2026"` \u2014 decision node; actor chooses a branch\n- `choice "\u2026"` \u2014 label on a decision branch\n- `chance "\u2026"` \u2014 chance node; nature chooses; `prob N` on children must sum to 1\n- `end "\u2026" payoff=N` \u2014 terminal leaf with net five-year economic value in dollars\n- `prob N` \u2014 probability (0\u20131) on a chance branch\n- EV rollback: chance = probability-weighted sum; decision = max child EV\n\n## How to read\n\nRoll back from leaves to root. Buy-new EV (with credit branch): 0.55 \xD7 28,500 + 0.45 \xD7 16,000 = **24,075**; without credit: 0.55 \xD7 21,000 + 0.45 \xD7 8,500 = **19,275**. Combined: 0.7 \xD7 24,075 + 0.3 \xD7 19,275 = **22,635**. Lease: flat **14,000**. Used EV: 0.6 \xD7 22,000 + 0.4 \xD7 8,000 = **16,400**. Under these assumptions *Buy new EV* dominates, largely because the 70% credit probability shifts the overall EV substantially upward. Sensitivity analysis on credit eligibility probability and the five-year resale spread is where the real MBA discussion lives.'
+  },
+  {
+    "slug": "decisiontree-go-nogo-product",
+    "diagram": "decisiontree",
+    "title": "Product launch go/no-go decision",
+    "description": "Stage-gate launch decision with market-size chance node, competitor-response chance, and NPV terminal values for a PM strategy review.",
+    "standard": "Raiffa & Schlaifer (1961)",
+    "tags": [
+      "launch",
+      "go-nogo",
+      "npv",
+      "strategy",
+      "product",
+      "chance"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'decisiontree:decision "Product Launch Strategy"\n\ndecision "Launch strategy?"\n  choice "Launch Q1 (full)"\n    chance "Market reception"\n      prob 0.4 chance "Competitor copies within 6mo? (strong)"\n        prob 0.5 end "Strong + copied" payoff=3200000\n        prob 0.5 end "Strong + defended" payoff=5800000\n      prob 0.35 chance "Competitor copies within 6mo? (moderate)"\n        prob 0.5 end "Moderate + copied" payoff=1400000\n        prob 0.5 end "Moderate + defended" payoff=2600000\n      prob 0.25 end "Weak reception" payoff=400000\n  choice "Launch Q3 (scoped)"\n    chance "Market reception (scoped)"\n      prob 0.45 end "Strong scoped" payoff=3100000\n      prob 0.35 end "Moderate scoped" payoff=1800000\n      prob 0.20 end "Weak scoped" payoff=600000\n  choice "No launch"\n    end "Saved development cost" payoff=900000',
+    "notes": '## Scenario\n\nA PM team is evaluating three paths ahead of an annual planning cycle: a full Q1 launch with the complete feature set, a scoped Q3 launch targeting the highest-confidence segments, and a no-launch option that recovers the estimated development spend. The Q1 full-launch path carries two sequential chance nodes \u2014 market reception (strong/moderate/weak) followed, for the non-weak outcomes, by a competitor-response chance (copies vs. defends). Payoffs are five-year NPV estimates in dollars, net of launch and ongoing operating costs.\n\n## Annotation key\n\n- `decision "\u2026"` \u2014 decision node; PM team chooses a branch\n- `choice "\u2026"` \u2014 label on a decision branch\n- `chance "\u2026"` \u2014 chance node; market or competitor behavior; `prob N` sums to 1 per node\n- `end "\u2026" payoff=N` \u2014 terminal leaf with five-year NPV in dollars\n- `prob N` \u2014 probability (0\u20131) on a chance branch\n- EV rollback: chance = probability-weighted sum; decision = max child EV\n\n## How to read\n\nFor Q1 full launch: strong-reception EV = 0.5 \xD7 3,200,000 + 0.5 \xD7 5,800,000 = **4,500,000**; moderate EV = 0.5 \xD7 1,400,000 + 0.5 \xD7 2,600,000 = **2,000,000**. Full-launch EV = 0.40 \xD7 4,500,000 + 0.35 \xD7 2,000,000 + 0.25 \xD7 400,000 = **2,600,000**. Scoped-Q3 EV = 0.45 \xD7 3,100,000 + 0.35 \xD7 1,800,000 + 0.20 \xD7 600,000 = **2,118,000**. No launch: **900,000**. Q1 full launch produces the highest EV, but the moderate-reception + copied scenario at $1.4M is a painful downside worth stress-testing \u2014 reducing competitor copy probability from 0.5 to 0.3 in that branch raises the EV meaningfully and may justify a launch accelerator investment.'
+  },
   {
     "slug": "decisiontree-investment-analysis",
     "diagram": "decisiontree",
@@ -457,6 +494,44 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'decisiontree:decision "Platform Vendor Choice"\n\ndecision "Which vendor?"\n  choice "Build in-house"\n    chance "Project outcome"\n      prob 0.6 end "On-time delivery" payoff=900000\n      prob 0.4 end "Over budget / delayed" payoff=150000\n  choice "Managed SaaS vendor"\n    end "Predictable cost" payoff=500000\n  choice "Hybrid approach"\n    chance "Integration complexity"\n      prob 0.5 end "Smooth integration" payoff=700000\n      prob 0.5 end "Integration rework" payoff=300000',
     "notes": '## Scenario\n\nA CTO is deciding how to stand up a new data-platform layer: build internally, buy managed SaaS, or take a hybrid. Each path has outcomes with probabilities and net-value estimates. The decision-analysis tree rolls the expected value back to the decision node so the optimal branch is identified automatically.\n\n## Annotation key\n\n- `decision "\u2026"` \u2014 actor chooses a branch\n- `chance "\u2026"` \u2014 nature chooses; `prob N` on each child (must sum to 1)\n- `end "\u2026" payoff=N` \u2014 terminal payoff\n- `choice "label"` \u2014 label on an outgoing decision branch\n- EV rollback: chance = probability-weighted sum; decision = max child EV\n\n## How to read\n\nEvaluate each branch\'s expected value. Build in-house: 0.6 \xD7 900k + 0.4 \xD7 150k = **600k**. Managed SaaS: flat **500k**. Hybrid: 0.5 \xD7 700k + 0.5 \xD7 300k = **500k**. Under these estimates the optimal branch is *Build in-house* \u2014 the parser flags it on render. The chart\'s real value is in forcing stakeholders to state probabilities explicitly; sensitivity to them is where the interesting argument happens.'
   },
+  {
+    "slug": "decisiontree-iris-sklearn",
+    "diagram": "decisiontree",
+    "title": "Iris species classifier (scikit-learn CART)",
+    "description": "The classic sklearn Iris CART decision tree \u2014 three species, two splits on petal length and width, rendered from a functional ML-tree description.",
+    "standard": "Breiman CART (1984)",
+    "tags": [
+      "cart",
+      "sklearn",
+      "iris",
+      "classification",
+      "ml",
+      "decision-tree"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": 'decisiontree:ml "Iris Classifier"\n\nsplit "petal length (cm) \u2264 2.45"\n  true leaf "Setosa" [support=50, impurity=0.0, class=setosa]\n  false split "petal width (cm) \u2264 1.75"\n    true leaf "Versicolor" [support=47, impurity=0.168, class=versicolor]\n    false leaf "Virginica" [support=45, impurity=0.043, class=virginica]',
+    "notes": '## Scenario\n\nThe Iris dataset \u2014 150 samples of three species (Iris setosa, versicolor, and virginica) measured across four features \u2014 is the canonical teaching example for classification. A CART tree trained with scikit-learn `DecisionTreeClassifier(max_depth=2)` produces exactly this two-level tree. Setosa is perfectly linearly separable on petal length alone; versicolor and virginica require a second split on petal width. The resulting tree achieves ~96% cross-validated accuracy.\n\n## Annotation key\n\n- `split "condition"` \u2014 internal node; routes left (`true`) when condition holds, right (`false`) when it does not\n- `true` / `false` \u2014 branch direction prefix indicating which child is reached when the split condition evaluates to that boolean\n- `leaf "label"` \u2014 terminal classification node\n- `[support=N]` \u2014 number of training samples reaching this leaf\n- `[impurity=N]` \u2014 Gini impurity at the node (0 = pure, 0.5 = maximally impure for binary)\n- `[class=\u2026]` \u2014 majority class label at the leaf\n\n## How to read\n\nStart at the root split. If petal length \u2264 2.45 cm, the sample is classified as **Setosa** immediately (Gini = 0, perfectly pure \u2014 all 50 setosa training samples land here). Otherwise, evaluate petal width: \u2264 1.75 cm predicts **Versicolor** (47 samples, Gini = 0.168 \u2014 a small number of virginica blur this boundary); > 1.75 cm predicts **Virginica** (45 samples, Gini = 0.043 \u2014 nearly pure). This tree is shallow enough to fit on an index card and remains the first model every ML course deploys.'
+  },
+  {
+    "slug": "decisiontree-litigation-settle",
+    "diagram": "decisiontree",
+    "title": "Litigation vs. settlement analysis",
+    "description": "Expected-value analysis of settling a $2M breach-of-contract claim vs. going to trial \u2014 with verdict probability and appeal chance nodes.",
+    "standard": "Raiffa & Schlaifer (1961)",
+    "tags": [
+      "litigation",
+      "settlement",
+      "legal",
+      "expected-value",
+      "trial",
+      "appeal"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'decisiontree:decision "Litigation Strategy"\n\ndecision "Litigation strategy?"\n  choice "Settle now"\n    end "Settlement payment" payoff=-350000\n  choice "Proceed to trial"\n    chance "Verdict"\n      prob 0.55 chance "Plaintiff appeals? (defense wins)"\n        prob 0.3 chance "Appeal outcome"\n          prob 0.4 end "Reversed on appeal" payoff=0\n          prob 0.6 end "Upheld on appeal" payoff=-2200000\n        prob 0.7 end "No appeal \u2014 defense prevails" payoff=0\n      prob 0.45 end "Plaintiff verdict \u2014 damages + fees" payoff=-2000000',
+    "notes": '## Scenario\n\nA corporate defendant faces a $2 million breach-of-contract claim. Outside counsel has assessed a 55% probability of a defense verdict at trial and a 45% probability of a plaintiff verdict (full damages plus attorney fees). If the defense wins, there is a 30% chance the plaintiff appeals; an appeal resolves with a 40% probability of reversal (cost: zero) and a 60% probability of affirmance, which adds appellate costs bringing total exposure to $2.2M. The client can alternatively settle immediately for $350,000. All payoffs are expressed as costs to the defendant (negative = outflow).\n\n## Annotation key\n\n- `decision "\u2026"` \u2014 decision node; counsel and client choose the path\n- `choice "\u2026"` \u2014 label on a decision branch\n- `chance "\u2026"` \u2014 chance node; court or opposing party behavior; `prob N` sums to 1\n- `end "\u2026" payoff=N` \u2014 terminal leaf; negative values represent costs to defendant\n- `prob N` \u2014 probability (0\u20131) on a chance branch\n- EV rollback: chance = probability-weighted sum; decision = max child EV (least negative)\n\n## How to read\n\nRoll back from leaves. Appeal-outcome EV: 0.4 \xD7 0 + 0.6 \xD7 \u22122,200,000 = **\u22121,320,000**. Defense-wins-verdict branch EV: 0.3 \xD7 \u22121,320,000 + 0.7 \xD7 0 = **\u2212396,000**. Trial EV: 0.55 \xD7 \u2212396,000 + 0.45 \xD7 \u22122,000,000 = **\u22121,117,800**. Settlement: **\u2212350,000**. Under these probability estimates, settling for $350,000 is the rational choice \u2014 it avoids the \u2212$1.12M expected cost of going to trial. The key sensitivity is the defense-verdict probability: if counsel is more than ~75% confident of winning at trial, the EV of proceeding drops below \u2212350,000 and trial becomes preferred.'
+  },
   {
     "slug": "decisiontree-support-triage",
     "diagram": "decisiontree",
@@ -475,6 +550,45 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'decisiontree "Customer Support Triage"\ndirection: top-down\n\nquestion "Is the service completely down?"\n  yes: question "Outage confirmed on status page?"\n    yes: answer "Follow incident protocol \u2014 page on-call"\n    no: answer "Check monitoring \u2014 open severity-1 ticket"\n  no: question "Is the issue affecting billing?"\n    yes: answer "Escalate to billing team \u2014 SLA breach risk"\n    no: question "Can user reproduce consistently?"\n      yes: answer "Collect HAR trace \u2014 file bug report"\n      no: answer "Ask for screenshot \u2014 watch for recurrence"',
     "notes": '## Scenario\n\nThe support lead bakes this tree into the agent runbook so new hires can triage in week one without a buddy. Three gates \u2014 outage, billing, reproducibility \u2014 route 90% of tickets deterministically. The remaining 10% (edge cases, multi-category) get flagged for human escalation instead of guessed at.\n\n## Annotation key\n\n- `question "text"` \u2014 internal decision node\n- `answer "text"` \u2014 terminal outcome\n- `yes:` / `no:` \u2014 branch label\n- Indentation (2 spaces) \u2014 parent-child nesting\n\n## How to read\n\nStart at the root. At each `question` node the agent answers yes or no and follows the matching branch. Every path terminates in an `answer` \u2014 a concrete next action, not another decision. The tree is deliberately shallow (max depth 3) so agents can hold it in their head; deeper branches would push into a runbook rather than a decision tree.'
   },
+  {
+    "slug": "decisiontree-triage-chest-pain",
+    "diagram": "decisiontree",
+    "title": "ED chest pain triage",
+    "description": "Emergency department chest-pain triage algorithm \u2014 HEART score pathway, STEMI/NSTEMI rule-out, and disposition decision for the ED physician.",
+    "standard": "AHA/ACC 2021 Chest Pain Guidelines",
+    "tags": [
+      "triage",
+      "chest-pain",
+      "ed",
+      "stemi",
+      "heart-score",
+      "clinical",
+      "aha"
+    ],
+    "complexity": 4,
+    "featured": false,
+    "dsl": 'decisiontree:taxonomy "ED Chest Pain Triage"\n\nquestion "ECG: ST elevation present?"\n  yes: answer "Activate cath lab \u2014 STEMI protocol"\n  no: question "Troponin elevated at 0h or 3h?"\n    yes: question "Dynamic troponin rise (\u2265 3 ng/L delta)?"\n      yes: answer "NSTEMI confirmed \u2014 cardiology consult, anticoagulate"\n      no: answer "Possible NSTEMI \u2014 repeat troponin at 6h"\n    no: question "HEART score \u2265 4?"\n      yes: answer "High risk \u2014 observation unit + stress test or CTA"\n      no: question "All low-risk features present?"\n        yes: answer "Discharge \u2014 outpatient follow-up within 72h"\n        no: answer "Observation \u2014 shared decision making with patient"',
+    "notes": '## Scenario\n\nChest pain accounts for roughly 8 million ED visits per year in the United States. The AHA/ACC 2021 Chest Pain Guidelines provide a tiered rule-out pathway: first exclude STEMI via ECG, then use high-sensitivity troponin at 0h and 3h to distinguish NSTEMI from unstable angina or non-cardiac causes, and finally apply the HEART score (History, ECG, Age, Risk factors, Troponin) to stratify remaining patients into high-risk observation vs. safe discharge. This tree encodes the core algorithmic structure for a busy ED attending.\n\n## Annotation key\n\n- `question "\u2026"` \u2014 internal clinical decision node; physician evaluates the criterion\n- `answer "\u2026"` \u2014 terminal disposition or action\n- `yes:` / `no:` \u2014 branch label indicating the clinical finding\n- HEART score: 0\u20133 low risk, 4\u20136 moderate, 7\u201310 high risk\n- Dynamic troponin: delta \u2265 3 ng/L between 0h and 3h draws meets ESC high-sensitivity criterion\n\n## How to read\n\nEntry is the 12-lead ECG. ST elevation routes directly to cath-lab activation \u2014 time is myocardium and no further branching is needed. Absence of ST elevation triggers the troponin pathway: a positive draw at either time point prompts delta assessment to distinguish true NSTEMI from a chronic elevation; a negative troponin advances to HEART score stratification. A score of 4 or higher mandates observation-unit admission with functional testing; a score below 4 with all low-risk clinical features present supports discharge with prompt outpatient follow-up. The final branch \u2014 observation with shared decision making \u2014 captures the borderline-HEART-score patient where physician judgment, patient preference, and social circumstances all contribute to disposition.'
+  },
+  {
+    "slug": "decisiontree-xgboost-churn",
+    "diagram": "decisiontree",
+    "title": "Customer churn prediction tree (XGBoost)",
+    "description": "One tree from an XGBoost churn model \u2014 days since last login, MRR tier, support tickets \u2014 showing how gradient boosting splits differ from CART.",
+    "standard": "Chen & Guestrin XGBoost (2016)",
+    "tags": [
+      "xgboost",
+      "churn",
+      "ml",
+      "gradient-boosting",
+      "saas",
+      "prediction"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'decisiontree:ml "Churn Prediction Tree (XGBoost)"\n\nsplit "days_since_login > 21"\n  true split "mrr_tier < 2"\n    true leaf "High churn risk" [score=0.72, class=churn]\n    false leaf "Medium risk \u2014 monitor" [score=0.41, class=churn]\n  false split "support_tickets_30d > 3"\n    true leaf "Medium risk \u2014 support-driven" [score=0.38, class=churn]\n    false leaf "Low churn risk" [score=0.09, class=retain]',
+    "notes": '## Scenario\n\nA SaaS company trains an XGBoost churn model on 90 days of product usage data. This is one representative tree from the ensemble, illustrating the three strongest churn signals in the dataset: recency of login (days since last login > 21 is the dominant split), MRR tier (lower-tier accounts churn faster when disengaged), and recent support ticket volume (elevated tickets correlate with frustration even among recently active users). Unlike a standalone CART tree, XGBoost trees output raw scores (log-odds contributions) that are summed across the ensemble before sigmoid transformation \u2014 the `score` values shown are per-tree contributions, not final probabilities.\n\n## Annotation key\n\n- `split "condition"` \u2014 internal split node; `true` branch when condition holds\n- `true` / `false` \u2014 branch direction prefix\n- `leaf "label"` \u2014 terminal node with a descriptive risk label\n- `[score=N]` \u2014 raw XGBoost leaf score (log-odds contribution from this tree)\n- `[class=\u2026]` \u2014 dominant class assignment at this leaf\n- XGBoost does not use Gini/entropy impurity; splits are chosen to maximize second-order gradient gain\n\n## How to read\n\nStart at the root. Accounts with more than 21 days since last login are immediately flagged: if they are also on MRR tier 0 or 1 (lowest-value tiers), the leaf score is 0.72 \u2014 the highest churn signal in this tree. High-tier disengaged accounts score 0.41, indicating meaningful but lower risk, consistent with higher switching costs. For recently active accounts (login \u2264 21 days), elevated support tickets (> 3 in 30 days) push score to 0.38 \u2014 a product-experience alert \u2014 while accounts that are both active and support-quiet score 0.09, the healthiest segment. In production, this tree\'s scores are summed with hundreds of sibling trees and passed through a sigmoid to yield a final churn probability between 0 and 1.'
+  },
   {
     "slug": "ecomap-refugee-resettlement",
     "diagram": "ecomap",
@@ -694,6 +808,63 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'fishbone "Fishbone diagram \u2014 Website traffic drop"\n\neffect "Traffic decline"\n\ncategory content     "Content"\ncategory tech        "Technical"\ncategory links       "Backlinks"\ncategory ux          "UX"\ncategory competition "Competition"\ncategory algo        "Algorithm"\n\ncontent : "Publishing frequency down"\ncontent : "Content too generic"\ncontent : "Keyword gaps"\ncontent : "Low-quality AI content"\n\ntech : "Core Web Vitals failing"\ntech : "Crawl coverage drop"\ntech : "Crawler blocked by WAF"\ntech : "Missing structured data"\n\nlinks : "High-quality backlinks lost"\nlinks : "High ratio of low-quality links"\nlinks : "Referring domain growth stalled"\nlinks : "Low anchor text diversity"\n\nux : "Bounce rate rising"\nux : "Poor mobile experience"\nux : "Slow above-fold load"\nux : "Excessive popup ads"\n\ncompetition : "New competitors entering"\ncompetition : "AI tools replacing search"\ncompetition : "Weakening brand recall"\ncompetition : "Competitors publishing faster"\n\nalgo : "Core Update penalty"\nalgo : "Weak E-E-A-T signals"\nalgo : "AI Overviews / SGE cutoff"\nalgo : "Search intent drift"',
     "notes": '## Scenario\n\nAn ops lead runs a growth post-mortem after a 30% organic traffic drop. The Ishikawa (fishbone) diagram structures the team\'s brainstorm into six standard causal categories, preventing the meeting from fixating on the most vocal hypothesis while ignoring systemic causes. The completed diagram becomes the project brief for the remediation sprint.\n\n## Annotation key\n\n- `effect "..."` \u2014 the problem statement, placed at the fish\'s head (right side)\n- `category id "Label"` \u2014 defines a major causal branch (a "bone"); use a short `id` to assign causes\n- `id : "cause text"` \u2014 assigns a cause string to the named category branch\n- Each category renders as a diagonal rib pointing toward the effect\n- Sub-causes (second-order) can be added by nesting if the DSL supports it\n\n## How to read\n\nThe effect (traffic decline) sits at the right. Six causal ribs branch from the spine: Content, Technical, Backlinks, UX, Competition, and Algorithm. Each rib lists four specific hypotheses. In a workshop, the team votes on each cause, color-codes high-confidence ones, and converts the highest-priority items into action items. The diagram serves as both a brainstorming artifact and a living post-mortem document.'
   },
+  {
+    "slug": "flowchart-algo-binary-search",
+    "diagram": "flowchart",
+    "title": "Binary search algorithm",
+    "description": "Iterative binary search over a sorted array \u2014 the classic CS teaching flowchart, from array + target input to found/not-found output.",
+    "standard": "ISO 5807:1985",
+    "tags": [
+      "algorithm",
+      "binary-search",
+      "teaching",
+      "cs",
+      "sorted-array",
+      "iterative"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": "flowchart TD\n  input([Input: sorted array A, target T]) --> init[low = 0, high = n \u2212 1]\n  init --> loopcheck{low \u2264 high?}\n  loopcheck -->|No| notfound([Return \u22121 \u2014 target not found])\n  loopcheck -->|Yes| mid[mid = floor((low + high) / 2)]\n  mid --> eqcheck{A[mid] == T?}\n  eqcheck -->|Yes| found([Return mid \u2014 target found at index mid])\n  eqcheck -->|No| ltcheck{A[mid] < T?}\n  ltcheck -->|Yes \u2014 search right half| newlow[low = mid + 1]\n  newlow --> loopcheck\n  ltcheck -->|No \u2014 search left half| newhigh[high = mid \u2212 1]\n  newhigh --> loopcheck",
+    "notes": "## Scenario\n\nA CS teacher is preparing lecture slides on divide-and-conquer algorithms and wants a textbook-quality flowchart students can annotate alongside the pseudocode. The iterative formulation makes the loop invariant \u2014 the search space halving each iteration \u2014 visually explicit, and the two boundary-update branches give students a concrete mental model for why the algorithm runs in O(log n) time.\n\n## Annotation key\n\n- `([\u2026])` \u2014 stadium; algorithm entry with inputs and terminal return values\n- `{\u2026}` \u2014 diamond; loop-continuation test and value-comparison decisions\n- `[\u2026]` \u2014 rectangle; variable initialization and index update assignments\n- `-->|label|` \u2014 branch labels stating the condition outcome and which half is selected\n- Back edges from `newlow` and `newhigh` to `loopcheck` form the iterative loop body\n\n## How to read\n\nThe algorithm initializes two index pointers \u2014 `low` at zero and `high` at the last index \u2014 then enters the main loop gate. If `low` exceeds `high` the search space is exhausted and \u22121 is returned. Otherwise `mid` is computed as the floor average of the two pointers and the element at that index is compared to the target. An exact match terminates with the index; a mismatch routes to the less-than check, which moves `low` one past `mid` to discard the left half, or moves `high` one below `mid` to discard the right half. Either update sends control back to the loop gate, halving the remaining search space on every iteration."
+  },
+  {
+    "slug": "flowchart-approval-bpmn",
+    "diagram": "flowchart",
+    "title": "Purchase order approval",
+    "description": "Employee submits PO \u2192 manager review \u2192 finance approval \u2192 payment \u2014 BPMN gateway shapes for a business approval workflow.",
+    "standard": "ISO 5807:1985",
+    "tags": [
+      "approval",
+      "bpmn",
+      "purchase-order",
+      "workflow",
+      "finance",
+      "gateway"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": "flowchart TD\n  submit([Employee submits purchase order]) --> amtcheck{Amount > $10,000?}\n  amtcheck -->|Yes \u2014 CFO track| cfo[CFO review queue]\n  amtcheck -->|No \u2014 standard track| mgr[Department manager review]\n  mgr --> mapproved{Manager approved?}\n  mapproved -->|No| revise[Request revision from employee]\n  revise --> submit\n  mapproved -->|Yes| cfo\n  cfo --> capproved{CFO approved?}\n  capproved -->|No| reject([Reject PO \u2014 notify employee with reason])\n  capproved -->|Yes| finance[Finance processes payment]\n  finance --> vendor[Send payment confirmation to vendor]\n  vendor --> done([PO closed \u2014 archived to ERP])",
+    "notes": "## Scenario\n\nA business analyst is documenting a company's purchase order workflow to support an ERP implementation and audit readiness review. The diagram makes explicit the dollar-amount threshold that gates which approval track a PO enters, the revision loop that keeps rejected items in flight rather than discarding them, and the two possible terminal outcomes \u2014 closed PO or formal rejection with written rationale.\n\n## Annotation key\n\n- `([\u2026])` \u2014 stadium; employee-initiated event and terminal closure or rejection nodes\n- `{\u2026}` \u2014 diamond; BPMN-style exclusive gateways branching on amount threshold or approval decision\n- `[\u2026]` \u2014 rectangle; human review steps and system actions (payment, notification, archival)\n- `-->|label|` \u2014 branch label showing threshold condition or approval outcome\n- Loop from `revise` back to `submit` keeps the PO in flight through the standard track after revision\n\n## How to read\n\nEvery PO enters the amount-check gateway immediately after submission. Orders above ten thousand dollars skip manager review and go directly to the CFO queue; orders at or below the threshold must first receive manager approval. A manager rejection sends the PO back to the employee for revision, which re-enters the same gateway \u2014 the amount does not change, so revised orders under the threshold loop through manager review again. Once the CFO approves (either from the high-value track or an escalated standard-track PO), finance executes payment and notifies the vendor, closing the PO in the ERP. A CFO rejection terminates the flow with a formal notice to the employee."
+  },
+  {
+    "slug": "flowchart-auth-flow",
+    "diagram": "flowchart",
+    "title": "OAuth 2.0 authorization code + PKCE",
+    "description": "OAuth 2.0 authorization code flow with PKCE \u2014 the recommended grant for SPAs and mobile apps, per RFC 7636.",
+    "standard": "ISO 5807:1985",
+    "tags": [
+      "oauth",
+      "pkce",
+      "authorization-code",
+      "security",
+      "spa",
+      "rfc7636"
+    ],
+    "complexity": 4,
+    "featured": false,
+    "dsl": 'flowchart LR\n  subgraph "Client App"\n    start([User initiates login]) --> gen[Generate code verifier + SHA-256 challenge]\n    gen --> redirect[Redirect to authorization endpoint with challenge + state]\n    callback[Receive authorization code] --> exchange[POST /token \u2014 code + code verifier]\n    tokens[Store access + refresh tokens] --> bearer[Attach Bearer token to API request]\n  end\n  subgraph "Authorization Server"\n    redirect --> login[Present login + consent UI]\n    login --> consent{User consents?}\n    consent -->|No| deny([Authorization denied \u2014 redirect with error])\n    consent -->|Yes| issue[Issue authorization code \u2014 redirect to callback]\n    issue --> callback\n    exchange --> verify{code_challenge matches verifier hash?}\n    verify -->|No| err([400 Bad Request \u2014 PKCE mismatch])\n    verify -->|Yes| mint[Mint access token + refresh token]\n    mint --> tokens\n  end\n  subgraph "Resource Server"\n    bearer --> validate{Bearer token valid + not expired?}\n    validate -->|No| unauth([401 Unauthorized])\n    validate -->|Yes| data([Return protected resource])\n  end',
+    "notes": '## Scenario\n\nA security engineer is reviewing a team\'s SPA authentication implementation against RFC 7636 to verify that the implicit grant has been fully removed in favor of authorization code with PKCE. The diagram makes the cryptographic handshake \u2014 code verifier generated client-side, challenge sent to the authorization server, verifier submitted at token exchange \u2014 visible alongside the three distinct server boundaries, helping reviewers confirm that no secret is ever stored in browser memory.\n\n## Annotation key\n\n- `([\u2026])` \u2014 stadium; user-initiated events and terminal success/error responses\n- `{\u2026}` \u2014 diamond; server-side validation gates (consent, PKCE hash match, token validity)\n- `[\u2026]` \u2014 rectangle; client or server processing steps\n- `subgraph "\u2026"` \u2014 trust boundary lanes for Client App, Authorization Server, and Resource Server\n- `-->|label|` \u2014 branch labels showing consent outcome or validation result\n\n## How to read\n\nThe flow starts in the Client App lane where the application generates a random code verifier and derives its SHA-256 challenge before redirecting the user. In the Authorization Server lane the user authenticates and consents; the server returns an authorization code bound to the challenge. The client then submits the original verifier in the token exchange request \u2014 the Authorization Server hashes it and compares it to the stored challenge, rejecting mismatches with a 400. Valid exchanges produce short-lived access and refresh tokens. The Resource Server lane shows the final step: every API call presents the Bearer token and the server validates its signature and expiry before returning data, enforcing a clean separation between authorization and resource access.'
+  },
   {
     "slug": "flowchart-cicd-pipeline",
     "diagram": "flowchart",
@@ -712,6 +883,62 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": "flowchart TD\n  commit([Push to main]) --> build[Build artifact]\n  build --> unit{Unit tests pass?}\n  unit -->|No| fail([Fail build])\n  unit -->|Yes| scan[Security scan]\n  scan --> vuln{High-severity CVEs?}\n  vuln -->|Yes| fail\n  vuln -->|No| stage[Deploy to staging]\n  stage --> smoke{Smoke tests green?}\n  smoke -->|No| fail\n  smoke -->|Yes| approve{Manual approval?}\n  approve -->|No| wait([Await approver])\n  approve -->|Yes| prod[Deploy to production]\n  prod --> health{Post-deploy health check?}\n  health -->|Yes| done([Release complete])\n  health -->|No| rollback[Automatic rollback]\n  rollback --> done",
     "notes": "## Scenario\n\nA platform engineer is documenting the team's trunk-based pipeline for a new-hire runbook. The diagram makes the four automated gates (tests \u2192 scan \u2192 smoke \u2192 post-deploy health) and the single human gate (manual approval) obvious at a glance, and shows that every failure path terminates the pipeline rather than silently continuing.\n\n## Annotation key\n\n- `([\u2026])` \u2014 stadium; start and terminal nodes\n- `{\u2026}` \u2014 diamond; automated or manual gate\n- `[\u2026]` \u2014 rectangle; build / deploy / scan step\n- `-->|Yes/No|` \u2014 branch labels on each gate\n\n## How to read\n\nStart at *Push to main*. Every diamond is a gate \u2014 a *No* on any of unit tests, CVE scan, or smoke tests terminates at *Fail build*. Manual approval is the only human gate; it can park the pipeline at *Await approver* without failing. The post-deploy health check guards production: a failure triggers automatic rollback, which still completes at *Release complete* because the rollback itself is a successful outcome."
   },
+  {
+    "slug": "flowchart-etl-pipeline",
+    "diagram": "flowchart",
+    "title": "ETL data pipeline",
+    "description": "Source extraction through transform, validation, load, and warehouse notification \u2014 the standard data-engineering pipeline diagram.",
+    "standard": "ISO 5807:1985",
+    "tags": [
+      "etl",
+      "pipeline",
+      "data",
+      "warehouse",
+      "validation",
+      "transform"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'flowchart LR\n  subgraph "Sources"\n    pg[(PostgreSQL)] --> extract\n    s3[(S3 bucket)] --> extract\n    api[REST API] --> extract\n  end\n  extract[Extract to raw staging] --> clean[Clean \u2014 strip nulls, deduplicate]\n  clean --> normalize[Normalize \u2014 cast types, unify schemas]\n  normalize --> enrich[Enrich \u2014 join lookup tables]\n  enrich --> validate{Error rate > 1%?}\n  validate -->|Yes| quarantine[Quarantine bad rows]\n  quarantine --> notify[Alert data-quality Slack channel]\n  notify --> retry{Retry batch?}\n  retry -->|Yes| extract\n  retry -->|No| abort([Abort run \u2014 log to incident tracker])\n  validate -->|No| load[Load to data warehouse]\n  load --> qcheck[Run row-count and sum reconciliation]\n  qcheck --> passed{Reconciliation passed?}\n  passed -->|No| rollback[Rollback warehouse load]\n  rollback --> abort\n  passed -->|Yes| publish[Publish partition metadata]\n  publish --> downstream([Notify downstream consumers \u2014 dbt, BI, ML])',
+    "notes": '## Scenario\n\nA data engineer is documenting a nightly batch ETL job that ingests transactional records from three heterogeneous sources into a central warehouse. The diagram serves as both a runbook and a stakeholder communication artifact, showing data-quality enforcement points that prevent silent corruption from propagating to reporting dashboards and machine-learning feature stores.\n\n## Annotation key\n\n- `([\u2026])` \u2014 stadium; terminal run outcomes (abort, notify consumers)\n- `{\u2026}` \u2014 diamond; quality gates with quantitative thresholds\n- `[\u2026]` \u2014 rectangle; processing steps or system actions\n- `[(\u2026)]` \u2014 cylinder; external data stores\n- `subgraph "Sources"` \u2014 groups the three ingestion connectors into one tier\n- Loop from `retry -->|Yes|` back to `extract` models full-batch reprocessing after quarantine\n\n## How to read\n\nThe pipeline fans in from three source connectors into a single extract step that writes to raw staging. The transform chain \u2014 clean, normalize, enrich \u2014 runs sequentially; each step narrows and standardizes the data before passing it forward. The validation gate measures the bad-row error rate: if it exceeds one percent, bad rows are quarantined, an alert fires, and the operator decides whether to retry or abort the run. Rows that pass validation are loaded to the warehouse, then verified with a row-count and sum reconciliation; a failed reconciliation triggers a rollback and abort rather than leaving inconsistent data in place. A successful reconciliation publishes partition metadata and fans out notifications to downstream consumers.'
+  },
+  {
+    "slug": "flowchart-incident-response",
+    "diagram": "flowchart",
+    "title": "On-call incident response",
+    "description": "SRE on-call decision tree from alert page through triage, escalation, mitigation, and post-mortem \u2014 BPMN-shaped TD flow.",
+    "standard": "ISO 5807:1985",
+    "tags": [
+      "incident",
+      "sre",
+      "on-call",
+      "escalation",
+      "mitigation",
+      "postmortem"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": "flowchart TD\n  page([Alert fires \u2014 on-call paged]) --> ack{Acknowledged within 5 min?}\n  ack -->|No| escalate[Escalate to secondary on-call]\n  escalate --> sev\n  ack -->|Yes| sev{Severity assessment}\n  sev -->|SEV1 \u2014 customer-facing outage| sev1[Wake CTO + open war room bridge]\n  sev -->|SEV2 \u2014 degraded service| sev2[Notify team lead + Slack channel]\n  sev -->|SEV3 \u2014 internal only| sev3[Self-resolve within shift]\n  sev1 --> mitigate[Apply mitigation \u2014 rollback or hotfix]\n  sev2 --> mitigate\n  sev3 --> mitigate\n  mitigate --> health{Service health restored?}\n  health -->|No| mitigate\n  health -->|Yes| resolved([Incident resolved \u2014 close bridge])\n  resolved --> postmortem{SEV1 or SEV2?}\n  postmortem -->|Yes| pm[Write post-mortem within 48 h]\n  postmortem -->|No| log[Log in incident tracker]\n  pm --> done([Done])\n  log --> done",
+    "notes": "## Scenario\n\nAn SRE team uses this flowchart as the canonical on-call runbook embedded in their incident-management wiki. When an alert fires at 3 AM the responder can follow the diagram top to bottom without improvising, ensuring that acknowledgment, severity triage, escalation paths, and post-mortem obligations are never skipped regardless of who is on duty.\n\n## Annotation key\n\n- `([\u2026])` \u2014 stadium; trigger events and terminal closure nodes\n- `{\u2026}` \u2014 diamond; time-boxed decisions and severity gates\n- `[\u2026]` \u2014 rectangle; prescribed human actions (escalate, notify, mitigate, document)\n- `-->|label|` \u2014 branch label showing condition or severity band\n- Loop back from `health -->|No|` to `mitigate` represents the retry-until-resolved mitigation cycle\n\n## How to read\n\nThe flow begins the moment an alert fires. The first gate enforces the five-minute acknowledgment SLA; a miss immediately escalates to the secondary responder who then re-enters the severity triage diamond. Severity determines the escalation audience \u2014 SEV1 wakes executive leadership, SEV2 notifies the team lead, SEV3 is self-contained. All three paths converge on the mitigation loop, which repeats until health is restored. The final diamond routes only SEV1 and SEV2 incidents to a formal post-mortem; SEV3 incidents close with a tracker log entry."
+  },
+  {
+    "slug": "flowchart-microservices-request",
+    "diagram": "flowchart",
+    "title": "Microservices request flow",
+    "description": "API gateway routing a request through auth, rate-limit, and three backend services to a shared DB \u2014 LR subgraph layout.",
+    "standard": "ISO 5807:1985",
+    "tags": [
+      "microservices",
+      "api-gateway",
+      "request-flow",
+      "backend",
+      "subgraph"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'flowchart LR\n  subgraph "API Layer"\n    client([Client request]) --> gateway[API Gateway]\n    gateway --> auth{Auth valid?}\n    auth -->|No| reject([401 Unauthorized])\n    auth -->|Yes| rate{Rate limit ok?}\n    rate -->|No| throttle([429 Too Many Requests])\n  end\n  subgraph "Services"\n    rate -->|Yes| route{Route by path}\n    route -->|/users| user[User Service]\n    route -->|/orders| order[Order Service]\n    order --> notify[Notification Service]\n  end\n  subgraph "Data"\n    user --> db[(PostgreSQL)]\n    order --> db\n  end\n  user -->|200 response| client\n  order -->|200 response| client\n  db -->|query error| dberr([500 DB Error])',
+    "notes": '## Scenario\n\nA backend engineer is documenting the runtime topology of a decomposed e-commerce platform so that new team members can trace a request end to end without reading source code. The diagram exposes the two pre-routing gates (authentication and rate limiting) and the downstream fan-out to specialized services, making it clear why a client might receive a 401, 429, or 500 before any business logic executes.\n\n## Annotation key\n\n- `([\u2026])` \u2014 stadium; entry points and terminal error/success nodes\n- `{\u2026}` \u2014 diamond; routing and policy decision gates\n- `[\u2026]` \u2014 rectangle; service or infrastructure processing step\n- `[(\u2026)]` \u2014 cylinder; persistent data store\n- `-->|label|` \u2014 labeled directed edge showing condition or path name\n- `subgraph "name"` \u2014 swimlane grouping API, service, and data tiers\n\n## How to read\n\nStart at *Client request* and follow the arrow into the API Layer subgraph. The request must clear two sequential gates \u2014 authentication then rate limiting \u2014 before reaching the route diamond. The route diamond dispatches to *User Service* or *Order Service* based on the URL path; an order request additionally triggers the *Notification Service* asynchronously. Both services share the same *PostgreSQL* store; a database error at that layer surfaces as a 500 terminal node independent of which service triggered the query.'
+  },
   {
     "slug": "flowchart-order-fulfillment",
     "diagram": "flowchart",
@@ -749,6 +976,25 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'flowchart TD\n  classDef excluded fill:#fef2f2,stroke:#b91c1c,stroke-width:1px,color:#7f1d1d\n\n  subgraph ID ["Identification"]\n    pubmed["PubMed (n = 482)"]\n    embase["Embase (n = 314)"]\n    cochrane["Cochrane (n = 91)"]\n    registers["Trial registers (n = 38)"]\n  end\n\n  subgraph SCREEN ["Screening"]\n    dedup["After duplicates removed (n = 712)"]\n    titles["Title and abstract screened (n = 712)"]\n    excl_titles["Records excluded (n = 598)"]\n    fulltext["Full-text sought (n = 114)"]\n    retrieved["Assessed for eligibility (n = 109)"]\n    not_retrieved["Not retrieved (n = 5)"]\n  end\n\n  subgraph ELIG ["Eligibility"]\n    assessed["Full-text articles assessed (n = 109)"]\n    excl_reasons["Excluded with reasons (n = 60)"]\n    r1["Wrong population (n = 18)"]\n    r2["Wrong intervention (n = 22)"]\n    r3["Wrong outcome (n = 11)"]\n    r4["Conference abstract only (n = 9)"]\n  end\n\n  included(["Studies in qualitative synthesis (n = 49)"])\n  meta(["Studies in meta-analysis (n = 31)"])\n\n  pubmed --> dedup\n  embase --> dedup\n  cochrane --> dedup\n  registers --> dedup\n  dedup --> titles\n  titles -->|excluded| excl_titles\n  titles -->|kept| fulltext\n  fulltext --> retrieved\n  fulltext -->|paywall / no response| not_retrieved\n  retrieved --> assessed\n  assessed -->|excluded with reasons| excl_reasons\n  excl_reasons --> r1\n  excl_reasons --> r2\n  excl_reasons --> r3\n  excl_reasons --> r4\n  assessed -->|met inclusion criteria| included\n  included --> meta\n\n  class excl_titles,not_retrieved,excl_reasons,r1,r2,r3,r4 excluded',
     "notes": '## Scenario\n\nA research librarian working with a clinical team produces the PRISMA 2020 flow diagram for an upcoming Cochrane review submission. The journal **requires** the diagram in this exact four-phase structure (Identification \u2192 Screening \u2192 Eligibility \u2192 Included), with the count `(n = \u2026)` shown explicitly in every box and the excluded-with-reasons box itemizing rejection reasons. Authoring this in a DSL (rather than redrawing in Word or BioRender) means the counts can be regenerated as the screening team updates the search.\n\n## Annotation key\n\n- **Subgraphs** name the four PRISMA phases: `subgraph ID ["Identification"]`, etc. \u2014 the rendered output groups boxes inside a labeled cluster border.\n- **`(n = N)` inline** \u2014 keep the count in the same label (PRISMA 2020 requires the count to be visible in every box; inline is the simplest layout that survives wide labels).\n- **`classDef excluded`** + **`class A,B excluded`** \u2014 applies the red-tinted class to the "records excluded" boxes so the eliminated stream is visually separated from the surviving stream.\n- **Edge labels** (`-->|excluded|`, `-->|met inclusion criteria|`) annotate the screening decision on each fork.\n- **Stadium nodes** (`(["\u2026"])`) mark the two terminal outcomes (qualitative synthesis count, meta-analysis count) so readers\' eyes land there.\n\n## How to read\n\nTop to bottom, the four phases mirror the PRISMA 2020 template exactly:\n\n1. **Identification** \u2014 every database and register the team searched, with raw record counts before deduplication.\n2. **Screening** \u2014 after deduplication, records pass through title/abstract screening (most are excluded here), then eligible records advance to full-text retrieval. Records lost at retrieval (paywall, no response from authors) are split into a separate "not retrieved" box per PRISMA 2020 reporting requirements.\n3. **Eligibility** \u2014 full-text articles are assessed against inclusion/exclusion criteria. Exclusions **must** be itemized with reasons \u2014 this is the box reviewers most often flag if missing.\n4. **Included** \u2014 final study count for the qualitative synthesis, with a sub-count for studies that contributed to the meta-analysis (not all included studies always do).\n\n## Standard reference\n\nPage MJ, McKenzie JE, Bossuyt PM, et al. *The PRISMA 2020 statement: an updated guideline for reporting systematic reviews.* BMJ 2021;372:n71. The flow-diagram template lives at [prisma-statement.org/prisma-2020-flow-diagram](https://www.prisma-statement.org/prisma-2020-flow-diagram).'
   },
+  {
+    "slug": "flowchart-user-onboarding",
+    "diagram": "flowchart",
+    "title": "User onboarding flow",
+    "description": "Signup through email verification, profile setup, first-action tutorial, and activation milestone \u2014 a product manager's north-star flow.",
+    "standard": "ISO 5807:1985",
+    "tags": [
+      "onboarding",
+      "activation",
+      "signup",
+      "tutorial",
+      "user-flow",
+      "product"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": "flowchart TD\n  signup([User submits signup form]) --> email[Send verification email]\n  email --> verified{Email verified?}\n  verified -->|No \u2014 after 24 h| resend[Resend verification email]\n  resend --> verified\n  verified -->|Yes| profile[Profile setup wizard]\n  profile --> skipped{Wizard completed?}\n  skipped -->|Skip| tour[Feature tour \u2014 3 tooltip steps]\n  skipped -->|Complete| tour\n  tour --> action{First core action taken?}\n  action -->|No \u2014 after 48 h| nudge[Send nudge email with shortcut link]\n  nudge --> action\n  action -->|Yes| activate[Record activation event]\n  activate --> welcome([Welcome milestone reached])",
+    "notes": '## Scenario\n\nA product manager is mapping the critical path from sign-up to activation to align engineering, growth, and design on what "activated user" means. The diagram makes every drop-off risk visible \u2014 email verification friction, wizard abandonment, and first-action hesitation \u2014 so each team can own the metric that corresponds to their part of the funnel.\n\n## Annotation key\n\n- `([\u2026])` \u2014 stadium; user-triggered entry and milestone terminal nodes\n- `{\u2026}` \u2014 diamond; binary or conditional state checks\n- `[\u2026]` \u2014 rectangle; system or product actions (send email, show wizard, record event)\n- `-->|label|` \u2014 branch labels showing condition, time trigger, or user choice\n- Loop edges from `resend` and `nudge` model retry cycles that resolve when the user acts\n\n## How to read\n\nThe flow starts at form submission and immediately hits the email verification gate. Users who do not verify within 24 hours loop through a resend step; this loop continues until verification succeeds. Once verified, all users \u2014 whether they complete the profile wizard or skip it \u2014 enter the three-step feature tour. The first-action gate determines activation: users who have not acted within 48 hours receive a nudge email that links directly to the core feature, shortening the path back into the loop. Activation fires a single analytics event that marks the user as "activated" and terminates the onboarding sequence.'
+  },
   {
     "slug": "genogram-brca-cancer",
     "diagram": "genogram",
@@ -1025,6 +1271,83 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": "mindmap\n\n# Q4 Company OKRs\n\n## Grow ARR 30%\n### Expand enterprise pipeline\n- 10 new qualified logos\n- Win rate \u2265 25%\n### Increase expansion\n- Net revenue retention \u2265 120%\n- Seat adoption +40%\n\n## Ship Platform v2\n### Core migration\n- 100% API coverage\n- Zero-downtime cutover\n### Developer experience\n- Sub-5-min quickstart\n- 95% doc satisfaction\n\n## Strengthen team\n### Hiring\n- 8 senior engineers\n- 2 staff PMs\n### Retention\n- Voluntary attrition < 5%\n- eNPS \u2265 40",
     "notes": "## Scenario\n\nThe chief of staff projects this during the Q4 all-hands. Three objectives radiate from the centre; every key result is a leaf with a specific number. The mindmap format reads fast \u2014 every person in the company can find their team's objective within three seconds \u2014 and it tolerates mid-quarter edits without disturbing other branches.\n\n## Annotation key\n\n- `#` \u2014 root; company-level frame\n- `##` \u2014 objective (qualitative direction)\n- `###` \u2014 key-result cluster\n- `-` bullets \u2014 specific measurable KRs\n\n## How to read\n\nThe root names the quarter. The three `##` branches are the objectives \u2014 the things that will be judged at the end of the quarter. Each `###` groups key results by theme; the bullets are the actual measurable targets. If a KR can't be reduced to a number, it probably belongs in a planning doc rather than on this mindmap."
   },
+  {
+    "slug": "orgchart-board-committees",
+    "diagram": "orgchart",
+    "title": "Corporate board and committee structure",
+    "description": "Public-company board governance \u2014 full board with audit, compensation, nominating/governance, and risk subcommittees per SEC requirements.",
+    "standard": "SEC / NYSE governance",
+    "tags": [
+      "orgchart",
+      "board",
+      "governance",
+      "audit",
+      "compensation",
+      "sec",
+      "committee"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'orgchart "Acme Corp \u2014 Board & Committee Structure"\nchair: "Victoria Harmon" | Board Chair [role: advisor]\n  audit_chair: "Ellen Frost, CPA" | Audit Committee Chair [role: finance]\n    audit_m1: "James Liu" | Audit Committee Member [role: finance]\n    audit_m2: "Priya Mehta" | Audit Committee Member [role: finance]\n  comp_chair: "Thomas Osei" | Compensation Committee Chair [role: hr]\n    comp_m1: "Sarah Nakamura" | Compensation Committee Member [role: hr]\n    comp_m2: "Rafael Dominguez" | Compensation Committee Member [role: hr]\n  nom_chair: "Linda Abramowitz" | Nom. & Governance Chair [role: legal]\n    nom_m1: "Derek Abubakar" | Nom. & Governance Member [role: legal]\n    nom_m2: "Yuki Fernandez" | Nom. & Governance Member [role: legal]\n  risk_chair: "Raj Mehta" | Risk Committee Chair [role: ops]\n    risk_m1: "Cynthia Okonkwo" | Risk Committee Member [role: ops]\n    risk_m2: "Simon Park" | Risk Committee Member [role: ops]\nboard_ceo: "David Park" | CEO (Management) [role: ceo]\n  mgmt_cfo: "Angela Torres" | CFO [role: finance]\n  mgmt_clo: "Marcus Reyes" | Chief Legal Officer [role: legal]\nboard_ceo -.-> audit_chair\nboard_ceo -.-> comp_chair\nboard_ceo -.-> nom_chair\nboard_ceo -.-> risk_chair',
+    "notes": '## Scenario\n\nThe corporate secretary is preparing the annual proxy statement and needs to document the board\'s committee structure as required by SEC Regulation S-K Item 407 and NYSE Listed Company Rules. The four standing committees \u2014 Audit, Compensation, Nominating & Governance, and Risk \u2014 each consist entirely of independent directors. The CEO and CFO participate in committee meetings by invitation and report to the relevant committees, but are not members. The dotted lines from the CEO to each committee chair represent this management reporting relationship for operational matters.\n\n## Annotation key\n\n- `chair: "Victoria Harmon" | Board Chair [role: advisor]` \u2014 independent chair; non-executive\n- Committee chairs and members use `[role: finance]`, `[role: hr]`, `[role: legal]`, `[role: ops]` to visually distinguish oversight focus\n- `board_ceo: "David Park" | CEO (Management)` \u2014 management side; inside-the-box CEO distinct from the independent board\n- `board_ceo -.-> audit_chair` \u2014 dotted lines represent management\'s accountability to each committee, not reporting hierarchy\n- All committee members must be independent directors under SEC Rule 10A-3 (Audit) and NYSE Section 303A\n\n## How to read\n\nThe board chart has two distinct clusters. The upper cluster \u2014 Board Chair and the four committees \u2014 is the governance structure: independent directors exercising fiduciary oversight. The lower cluster \u2014 CEO and management \u2014 represents the executive team that is accountable to the board. Dotted lines from the CEO to each committee chair indicate that management attends and reports to committees without being members or having voting rights. The Audit Committee chair (Ellen Frost, CPA) satisfies the SEC\'s financial expert disclosure requirement. NYSE rules require that Compensation and Nom/Gov committees be composed solely of independent directors; the Risk Committee follows the same practice here but is not legally mandated to be fully independent.'
+  },
+  {
+    "slug": "orgchart-engineering-dept",
+    "diagram": "orgchart",
+    "title": "Engineering department \u2014 platform, product, infra squads",
+    "description": "Engineering org with three squad leads under a VP Eng \u2014 platform, product, and infrastructure, with open headcount flagged.",
+    "standard": "HR convention",
+    "tags": [
+      "orgchart",
+      "engineering",
+      "squad",
+      "platform",
+      "infra",
+      "product"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'orgchart "Engineering Department \u2014 Q3 Headcount Plan"\nstaff_pe: "Diana Okonkwo" | Staff Principal Engineer [role: engineer]\nvp_eng: "Sarah Chen" | VP Engineering [role: cto]\n  platform_lead: "Marco Rossi" | Platform Lead [role: engineer]\n    pe1: "Kenji Watanabe" | Senior Engineer | Platform [role: engineer]\n    pe2: "Aaliya Hassan" | Engineer | Platform [role: engineer]\n    pe3: "Lucas Ferreira" | Engineer | Platform [role: engineer]\n    open_sr: open "TBH" | Senior Engineer | Platform [role: engineer]\n  product_lead: "Aisha Okafor" | Product Eng Lead [role: engineer]\n    pe4: "Rohan Mehta" | Senior Engineer | Product [role: engineer]\n    pe5: "Chloe Martin" | Engineer | Product [role: engineer]\n    pe6: "Jae-won Oh" | Engineer | Product [role: engineer]\n    pe7: "Fatima Al-Rashid" | Engineer | Product [role: engineer]\n    draft_staff: draft "TBH" | Staff Engineer | Product [role: engineer]\n  infra_lead: "Dev Patel" | Infra Lead [role: engineer]\n    ie1: "Nadia Kowalski" | Senior SRE [role: engineer]\n    ie2: "Emre Yilmaz" | SRE [role: engineer]\n    open_sre: open "TBH" | Site Reliability Engineer [role: engineer]\nstaff_pe -.-> platform_lead\nstaff_pe -.-> product_lead\nstaff_pe -.-> infra_lead',
+    "notes": '## Scenario\n\nThe engineering director is presenting the Q3 headcount plan to the CFO. The chart shows three squads \u2014 platform, product engineering, and infrastructure \u2014 each under a dedicated lead reporting to the VP of Engineering. A Staff Principal Engineer provides technical oversight across all three squads via dotted-line relationships. Two open reqs are actively being recruited (Platform Senior Engineer, SRE), and one Staff Engineer seat in the product squad is planned for Q4 but not yet approved.\n\n## Annotation key\n\n- `vp_eng: "Sarah Chen" | VP Engineering [role: cto]` \u2014 VP-level node coloured with the cto role style\n- Indentation (2 spaces) \u2014 solid-line reporting hierarchy\n- `open "TBH"` \u2014 approved open requisition, currently recruiting\n- `draft "TBH"` \u2014 planned headcount, not yet approved or posted\n- `staff_pe -.-> platform_lead` \u2014 dotted line; technical authority without HR reporting chain\n\n## How to read\n\nThe tree root is the VP of Engineering. The three squad leads sit at the second level \u2014 equal peers in the org, differentiated only by domain. Headcount marked `open` (Platform Senior Eng, SRE) represents approved budget the director is actively spending; `draft` (Product Staff) is the ask for the next planning cycle. The staff principal at the top of the chart is neither the VP\'s direct report nor a squad lead: the dotted lines to all three leads signal that she sets technical standards and does architecture review across squads without owning any head count.'
+  },
+  {
+    "slug": "orgchart-hospital-dept",
+    "diagram": "orgchart",
+    "title": "Hospital clinical department hierarchy",
+    "description": "Hospital clinical org \u2014 Chief Medical Officer, department heads, attendings, residents, and nursing leads for a teaching hospital.",
+    "standard": "JCAHO / hospital convention",
+    "tags": [
+      "orgchart",
+      "hospital",
+      "clinical",
+      "physician",
+      "nursing",
+      "hierarchy"
+    ],
+    "complexity": 4,
+    "featured": false,
+    "dsl": 'orgchart "General Hospital \u2014 Clinical Leadership"\ncmo: "Dr. Patricia Williams" | Chief Medical Officer [role: medical]\n  chief_med: "Dr. James Park" | Chief of Medicine [role: medical]\n    cardio_head: "Dr. Amara Nwosu" | Division Chief | Cardiology [role: medical]\n      att_card1: "Dr. Elena Sousa" | Attending Physician [role: medical]\n      att_card2: "Dr. Ravi Gupta" | Attending Physician [role: medical]\n      res_card1: "Dr. Yuki Tanaka" | PGY-3 Resident [role: medical]\n      res_card2: "Dr. Malik Johnson" | PGY-2 Resident [role: medical]\n    neuro_head: "Dr. Ingrid Larsen" | Division Chief | Neurology [role: medical]\n      att_neuro1: "Dr. Omar Sharif" | Attending Physician [role: medical]\n      att_neuro2: "Dr. Priya Krishnan" | Attending Physician [role: medical]\n      res_neuro1: "Dr. Tom\xE1s Rivera" | PGY-3 Resident [role: medical]\n      res_neuro2: "Dr. Aisha Conteh" | PGY-2 Resident [role: medical]\n  chief_surg: "Dr. Amara Diallo" | Chief of Surgery [role: medical]\n    gen_surg_head: "Dr. Wei Zhang" | Division Chief | General Surgery [role: medical]\n      att_gs1: "Dr. Sofia Reyes" | Attending Surgeon [role: medical]\n      att_gs2: "Dr. Kwame Mensah" | Attending Surgeon [role: medical]\n    ortho_head: "Dr. Henrik Svensson" | Division Chief | Orthopedics [role: medical]\n      att_orth1: "Dr. Nalini Patel" | Attending Surgeon [role: medical]\n      att_orth2: "Dr. Seun Adeyemi" | Attending Surgeon [role: medical]\n  cno: "Maria Gonzalez, RN, MSN" | Chief Nursing Officer [role: medical]\n    med_surg_mgr: "Lisa Park, RN" | Nurse Manager | Med-Surg [role: medical]\n    icu_mgr: "Robert Osei, RN" | ICU Nurse Manager [role: medical]',
+    "notes": "## Scenario\n\nA hospital administrator is preparing a JCAHO accreditation submission and needs to document the clinical governance structure. The chart shows the three-pillar model common to teaching hospitals: Medicine and Surgery under the CMO handle physician credentialing and clinical protocols, while Nursing reports separately to ensure independent oversight of nursing practice standards. Attendings supervise residents directly; residents rotate between divisions but report to their division chief.\n\n## Annotation key\n\n- `[role: medical]` \u2014 all clinical staff rendered with the medical colour coding\n- Indentation \u2014 solid-line administrative and clinical reporting chain\n- `PGY-2 / PGY-3` \u2014 Post-Graduate Year, the standard US resident designation (PGY-1 = intern)\n- `RN, MSN` \u2014 inline credentials appended to the name field, common in nursing leadership notation\n- Division Chiefs sit between the department Chief and individual attendings \u2014 the standard academic medical centre layer\n\n## How to read\n\nThe CMO owns clinical quality across all departments. Medicine and Surgery are equal pillars \u2014 each Chief has autonomous credentialing authority within their specialty. Within Medicine, Cardiology and Neurology each run their own attending\u2013resident teaching structure: attendings carry clinical responsibility; residents operate under supervision with authority expanding by PGY year. Nursing reports up through the CNO rather than through either clinical chief \u2014 a deliberate governance separation required by Magnet hospital standards. The two nurse managers (Med-Surg floor, ICU) translate CNO policy to unit-level staffing and care protocols."
+  },
+  {
+    "slug": "orgchart-law-firm-partnership",
+    "diagram": "orgchart",
+    "title": "Law firm partnership structure",
+    "description": "AmLaw 100-style law firm org \u2014 equity and non-equity partners, counsel, associates, and professional staff by practice group.",
+    "standard": "NALP convention",
+    "tags": [
+      "orgchart",
+      "law-firm",
+      "partnership",
+      "counsel",
+      "associate",
+      "legal"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'orgchart "Chen & Associates LLP \u2014 Partnership Structure"\nmanaging_partner: "Robert Chen" | Managing Partner [role: ceo]\n  corp_chair: "Jennifer Wu" | Corporate Practice Chair [role: coo]\n    corp_ep1: "David Okafor" | Equity Partner | M&A [role: legal]\n      corp_ep1_sa1: "Mei-Ling Torres" | Senior Associate [role: legal]\n      corp_ep1_a1: "Brendan Nwosu" | Associate [role: legal]\n      corp_ep1_a2: "Priya Sharma" | Associate [role: legal]\n    corp_ep2: "Simone Beaumont" | Equity Partner | Securities [role: legal]\n      corp_ep2_sa1: "Aleksei Volkov" | Senior Associate [role: legal]\n      corp_ep2_a1: "Fatou Diallo" | Associate [role: legal]\n    corp_nep: "Marcus Tran" | Non-Equity Partner | Corporate [role: legal]\n      corp_nep_a1: "Yuna Kim" | Associate [role: legal]\n      corp_para1: "Sandra Lopez" | Paralegal [role: ops]\n  lit_chair: "Marcus Johnson" | Litigation Practice Chair [role: coo]\n    lit_ep1: "Amara Osei" | Equity Partner | Commercial Lit [role: legal]\n      lit_ep1_sa1: "Tobias Gruber" | Senior Associate [role: legal]\n      lit_ep1_a1: "Chimamanda Eze" | Associate [role: legal]\n    lit_ep2: "Hiroshi Nakamura" | Equity Partner | White Collar [role: legal]\n      lit_ep2_sa1: "Valentina Cruz" | Senior Associate [role: legal]\n      lit_ep2_a1: "Daniel Abioye" | Associate [role: legal]\n    lit_counsel: "Rachel Goldstein" | Counsel | Litigation [role: legal]\n  cfo: "Dana Kim" | COO / CFO [role: finance]\n  mkt: "Alex Torres" | Chief Marketing Officer [role: ops]',
+    "notes": "## Scenario\n\nThe managing partner is preparing materials for the annual partnership meeting, including the governance deck and lateral-hire pitch collateral. The chart shows the two-track attorney structure common to AmLaw 100 firms: equity partners share in firm profits and have capital accounts; non-equity partners are on fixed compensation; counsel are senior attorneys on a permanent non-partnership track. Associates are levelled as first-through-fifth-year and senior (sixth-plus). Professional staff \u2014 COO/CFO and CMO \u2014 sit as firm-level directs to the managing partner.\n\n## Annotation key\n\n- `[role: legal]` \u2014 attorney nodes; `[role: finance]` and `[role: ops]` \u2014 professional staff\n- Equity Partner \u2014 profit-sharing, voting interest in firm governance\n- Non-Equity Partner \u2014 title parity without capital account; typically earns a fixed bonus-eligible salary\n- Counsel \u2014 senior non-partner track: often former partners, domain specialists, or attorneys who opted out of the equity track\n- Senior Associate \u2014 sixth year or above; on the partnership evaluation clock\n- `corp_chair` / `lit_chair` \u2014 practice group chairs own lateral hiring, billing rate setting, and matter assignment within their group\n\n## How to read\n\nRobert Chen, as managing partner, chairs the firm's executive committee and carries final governance authority. The two practice chairs report to him and run their groups as semi-autonomous profit centres. Within each group, equity partners own client relationships and sign off on fee arrangements; associates bill under partner supervision. The non-equity partner in Corporate adds capacity without diluting the equity pool \u2014 a common structure when a client relationship is stable but not large enough to justify a new equity slot. Counsel in Litigation handles specialized motions work that would otherwise require lateral-hiring a lateral partner. The COO/CFO and CMO report directly to the managing partner rather than through a practice chair \u2014 they serve the whole firm, not a single group."
+  },
   {
     "slug": "orgchart-matrix-reporting",
     "diagram": "orgchart",
@@ -1317,6 +1640,27 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'timing "SPI Transaction"\nCLK:   pppppppp\nCS_N:  10000001\nMOSI:  x=======  data: ["0xAB","0xCD","0xEF","0x01","0x02","0x03","0x04","0x05"]\nMISO:  zzzz====  data: ["","","","","0xFF","0x12","0x34","0x56"]',
     "notes": "## Scenario\n\nA firmware engineer or hardware designer documents an 8-byte SPI master-to-slave transaction for a device driver review or datasheet. The WaveDrom-compatible syntax means the same DSL can be pasted directly into WaveDrom's online editor or embedded in documentation pipelines.\n\n## Annotation key\n\n- `p` \u2014 clock pulse (high period followed by low); each `p` is one clock cycle\n- `1` / `0` \u2014 logic high / logic low\n- `=` \u2014 data bus: stable data (value unchanged from previous cycle)\n- `x` \u2014 don't-care or undefined state (transition state)\n- `z` \u2014 high-impedance (floating / tri-state)\n- `data: [...]` \u2014 optional data labels for each stable segment, rendered inside the bus bar\n- `CS_N` \u2014 active-low chip select; `1` = deselected, `0` = selected\n\n## How to read\n\nThe clock runs for 8 cycles. CS_N goes low at cycle 1 and returns high at cycle 8, framing the transaction. MOSI (master out) sends 8 bytes starting at cycle 1. MISO (slave in) is high-Z for the first 4 cycles (slave preparing the response) then transitions to stable data bytes 5\u20138. The transaction completes when CS_N de-asserts."
   },
+  {
+    "slug": "venn-audience-overlap-marketing",
+    "diagram": "venn",
+    "title": "Paid audience overlap \u2014 Meta \xD7 Google \xD7 TikTok",
+    "description": "Three ad-platform audience overlap for performance marketing \u2014 Meta, Google, and TikTok intersection counts to guide budget allocation.",
+    "standard": "Venn (1880)",
+    "tags": [
+      "venn",
+      "audience",
+      "meta",
+      "google",
+      "tiktok",
+      "marketing",
+      "overlap",
+      "paid"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": 'venn "Q4 Holiday Campaign \u2014 Paid Audience Overlap"\nset meta "Meta (FB + IG)" [color: "#1877F2"]\nset google "Google Ads" [color: "#EA4335"]\nset tiktok "TikTok" [color: "#010101"]\nmeta & google : 18400\nmeta & tiktok : 24700\ngoogle & tiktok : 9200\nmeta & google & tiktok : 5100\nmeta only : 61000\ngoogle only : 38500\ntiktok only : 42300',
+    "notes": '## Scenario\n\nA performance marketing manager is finalising the Q4 holiday campaign budget across three platforms. The Venn reveals that a meaningful audience of 5,100 users is targetable on all three channels simultaneously \u2014 this cohort will see the brand multiple times, so frequency capping is critical. The 61k Meta-exclusive pool is the largest single-platform opportunity, while TikTok\'s 42k exclusive reach justifies keeping it in the mix even at a higher CPM.\n\n## Annotation key\n\n- `set ID "Label"` \u2014 one ad platform per circle\n- `A & B : n` \u2014 users reachable on both platforms (multi-touch risk)\n- `A only : n` \u2014 users reachable exclusively on one platform\n\n## How to read\n\nEach circle represents the targetable audience on one platform. Intersection counts show users reachable across multiple channels \u2014 useful for setting frequency caps and coordinating creative sequencing. The triple intersection (5,100) is the most saturated segment and should receive unified messaging. Exclusive regions show where each platform provides unique incremental reach that the others cannot access.'
+  },
   {
     "slug": "venn-customer-segments",
     "diagram": "venn",
@@ -1335,6 +1679,65 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'venn "Customer Segments \u2014 Q3 2025"\nset email "Email subscribers" [color: "#1E88E5"]\nset paid "Paid users" [color: "#E53935"]\nset mobile "Mobile app users" [color: "#43A047"]\nemail & paid : 1840\nemail & mobile : 920\npaid & mobile : 2100\nemail & paid & mobile : 650\nemail only : 12400\npaid only : 3200\nmobile only : 8700',
     "notes": '## Scenario\n\nA lifecycle marketer is planning Q4 campaigns and needs to see which audiences overlap before deciding where to spend budget. The 650-strong triple intersection is the highest-LTV segment; the 12.4k email-only group is the biggest conversion opportunity. Putting the numbers on one Venn makes the gaps and overlaps argue for themselves in a 30-second leadership review.\n\n## Annotation key\n\n- `set ID "Label"` \u2014 declare a circle\n- `A & B : n` \u2014 count in the intersection of A and B\n- `A only : n` \u2014 count exclusive to A\n\n## How to read\n\nEach circle is a total audience; each overlap is people who belong to multiple audiences. The triple intersection (email \u2229 paid \u2229 mobile, 650 users) is your most engaged cohort \u2014 the obvious group to upsell. The *email only* and *mobile only* exclusive regions are your largest activation opportunities because each represents users who have not yet crossed into the other channels.'
   },
+  {
+    "slug": "venn-euler-taxonomy",
+    "diagram": "venn",
+    "title": "Euler diagram \u2014 animal kingdom containment",
+    "description": "Euler containment diagram showing Animals \u2283 Vertebrates \u2283 Mammals \u2283 Primates \u2014 a nested subset visualization for biology class.",
+    "standard": "Euler (1768)",
+    "tags": [
+      "euler",
+      "venn",
+      "taxonomy",
+      "mammals",
+      "vertebrates",
+      "biology",
+      "containment"
+    ],
+    "complexity": 1,
+    "featured": false,
+    "dsl": 'venn "Animal Kingdom \u2014 Nested Containment"\nmode: euler\nset animals "Animals" [color: "#43A047"]\nset vertebrates "Vertebrates" [subset-of: animals, color: "#1E88E5"]\nset mammals "Mammals" [subset-of: vertebrates, color: "#FB8C00"]\nset primates "Primates" [subset-of: mammals, color: "#E53935"]',
+    "notes": "## Scenario\n\nA biology teacher uses this Euler diagram to introduce taxonomic hierarchy on the first day of a classification unit. Unlike a Venn diagram \u2014 which implies partial overlap between circles \u2014 an Euler diagram shows true containment: every primate is a mammal, every mammal is a vertebrate, and every vertebrate is an animal. Students can immediately see that the sets are nested, not intersecting.\n\n## Annotation key\n\n- `mode: euler` \u2014 enables containment (subset) layout instead of partial overlap\n- `subset-of: ID` \u2014 declares that this set is fully enclosed within another\n- Nested rings from outermost to innermost: Animals \u2192 Vertebrates \u2192 Mammals \u2192 Primates\n\n## How to read\n\nRead from the outside in. The outermost ring (Animals) contains all others. Each inner ring is a strict subset of the ring enclosing it \u2014 no element can be in Primates without also being in Mammals, Vertebrates, and Animals. The space between Vertebrates and Mammals represents vertebrates that are not mammals (fish, amphibians, reptiles, birds). The space between Mammals and Primates represents mammals that are not primates (dogs, cats, whales, bats)."
+  },
+  {
+    "slug": "venn-feature-comparison-tools",
+    "diagram": "venn",
+    "title": "Feature comparison \u2014 Notion vs. Obsidian vs. Roam",
+    "description": "Three-way Venn of knowledge-management features across Notion, Obsidian, and Roam Research \u2014 for product teams benchmarking a new tool.",
+    "standard": "Venn (1880)",
+    "tags": [
+      "venn",
+      "feature-comparison",
+      "notion",
+      "obsidian",
+      "roam",
+      "product",
+      "competitive"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": 'venn "Knowledge Management Tools \u2014 Feature Overlap"\nset notion "Notion" [color: "#000000"]\nset obsidian "Obsidian" [color: "#7C3AED"]\nset roam "Roam Research" [color: "#3B82F6"]\nnotion & obsidian : 3\nnotion & roam : 2\nobsidian & roam : 2\nnotion & obsidian & roam : 3\nnotion only : 8\nobsidian only : 6\nroam only : 4',
+    "notes": "## Scenario\n\nA product manager is building a competitive teardown before a roadmap review. Rather than a spreadsheet of checkboxes, the Venn communicates at a glance which features are table stakes (the triple intersection), which are differentiators (exclusive regions), and which signal partnership opportunities or feature gaps. The counts here represent clusters of related capabilities, not raw feature counts.\n\n## Annotation key\n\n- `set ID \"Label\"` \u2014 one tool per circle\n- `A & B : n` \u2014 number of feature clusters shared by both tools\n- `A only : n` \u2014 feature clusters unique to one tool\n\n## How to read\n\nEach circle represents one tool's total feature set grouped into capability clusters. The triple intersection (3 clusters: block-based editing, bidirectional links, tagging) represents the baseline every modern knowledge tool must ship. Notion's exclusive region (8 clusters) reflects its broader collaboration and database surface area. Obsidian's exclusive region (6) reflects its plugin ecosystem and local-first architecture. Roam's exclusive region (4) reflects its outliner-first and daily-notes conventions."
+  },
+  {
+    "slug": "venn-prisma-screening",
+    "diagram": "venn",
+    "title": "PRISMA systematic review \u2014 database screening",
+    "description": "Three-database PRISMA deduplication Venn showing PubMed, Embase, and Cochrane overlap counts for a systematic literature review.",
+    "standard": "PRISMA 2020",
+    "tags": [
+      "venn",
+      "prisma",
+      "systematic-review",
+      "literature",
+      "pubmed",
+      "embase"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": 'venn "Database Screening \u2014 PRISMA Deduplication"\nset pubmed "PubMed" [color: "#1E88E5"]\nset embase "Embase" [color: "#E53935"]\nset cochrane "Cochrane" [color: "#43A047"]\npubmed & embase : 1240\npubmed & cochrane : 340\nembase & cochrane : 280\npubmed & embase & cochrane : 180\npubmed only : 4200\nembase only : 2800\ncochrane only : 620',
+    "notes": '## Scenario\n\nA systematic reviewer searches PubMed, Embase, and Cochrane before title/abstract screening. Before any reading begins, duplicates must be removed \u2014 the same paper indexed in multiple databases would inflate the apparent evidence base. This Venn shows where the three databases overlap so the reviewer can report the PRISMA 2020 deduplication step with exact counts and transparently justify why 2,040 records were removed before screening began.\n\n## Annotation key\n\n- `set ID "Label"` \u2014 one database per circle\n- `A & B : n` \u2014 records indexed in both databases (potential duplicates)\n- `A only : n` \u2014 records unique to a single database\n\n## How to read\n\nEach circle represents one database\'s raw retrieval. Overlapping regions are records that appear in more than one source and are the primary deduplication targets. The triple intersection (180) means those papers were found in all three databases simultaneously. After removing all intersections as duplicates, the unique record count is 4 200 + 2 800 + 620 = 7 620 \u2014 the number that proceeds to title/abstract screening and is recorded in the PRISMA flow diagram.'
+  },
   {
     "slug": "venn-programming-paradigms",
     "diagram": "venn",
@@ -1541,7 +1944,7 @@ function getExamples(type, opts = {}) {
 function validateDsl(type, dsl) {
   const config = type ? { type } : void 0;
   try {
-    chunkO2HN4WRG_cjs.parse(dsl, config);
+    chunkDHHVYSQX_cjs.parse(dsl, config);
     return { ok: true, type: type ?? resolveTypeFromText(dsl) };
   } catch (err) {
     return {
@@ -1557,7 +1960,7 @@ function renderDsl(type, dsl, options = {}) {
     ...type ? { type } : {}
   };
   try {
-    const svg = chunkO2HN4WRG_cjs.render(dsl, config);
+    const svg = chunkDHHVYSQX_cjs.render(dsl, config);
     return { ok: true, type: type ?? resolveTypeFromText(dsl), svg };
   } catch (err) {
     return {
@@ -1581,5 +1984,5 @@ exports.getSyntax = getSyntax;
 exports.listDiagrams = listDiagrams;
 exports.renderDsl = renderDsl;
 exports.validateDsl = validateDsl;
-//# sourceMappingURL=chunk-7LNIBHO6.cjs.map
-//# sourceMappingURL=chunk-7LNIBHO6.cjs.map
+//# sourceMappingURL=chunk-WCAADEXJ.cjs.map
+//# sourceMappingURL=chunk-WCAADEXJ.cjs.map