schematex 0.7.0 → 0.8.0

package/dist/{chunk-CTMJ3XP2.cjs → chunk-RKN6QJ7K.cjs}

@@ -1,6 +1,6 @@
 'use strict';
 
-var chunkHFATQXFN_cjs = require('./chunk-HFATQXFN.cjs');
+var chunk3CSST5GZ_cjs = require('./chunk-3CSST5GZ.cjs');
 
 // src/ai/registry.ts
 var DIAGRAM_REGISTRY = [
@@ -340,6 +340,81 @@ var DIAGRAM_REGISTRY = [
     cluster: "generic",
     standard: "Timeline convention with era bands",
     syntaxKey: "timeline"
+  },
+  // ── Risk & reliability (Bucket B) ────────────────────────────
+  {
+    type: "eventtree",
+    name: "Event Tree Analysis",
+    tagline: "Forward-looking risk: one initiating event branches through each safety function into outcome sequences, with computed path frequencies.",
+    useWhen: "Use to propagate the consequences of an initiating event through a chain of barriers/safety functions and quantify each outcome's frequency \u2014 the inductive complement to a fault tree and the right wing of a bowtie. Header `eventtree`/`eta`; declare the initiating event with a frequency, the ordered functions with success/failure branch probabilities, and outcome rows with `s`/`f`/`*` patterns. The engine computes path frequency = f_initiating \xD7 \u03A0 branch-probabilities and flags the dominant sequence.",
+    cluster: "risk-reliability",
+    standard: "IEC 62502:2010 \xB7 NUREG/CR-2300 (PRA) \xB7 ISO 31010 Annex B; see 39-EVENT-TREE-STANDARD.md",
+    syntaxKey: "eventtree"
+  },
+  {
+    type: "fmea",
+    name: "FMEA (Failure Mode and Effects Analysis)",
+    tagline: "The reliability worksheet that computes its own risk \u2014 RPN = S\xD7O\xD7D plus AIAG-VDA Action Priority, ranked and colour-coded.",
+    useWhen: "Use to score and prioritise how each component/process step can fail \u2014 severity, occurrence, detection \u2014 and decide what to fix first. Header `fmea`; declare item/function \u2192 failure mode \u2192 effect (with `sev`) \u2192 cause (with `occ`) \u2192 controls (with `det`). The engine computes RPN = S\xD7O\xD7D and the AIAG-VDA Action Priority (High/Medium/Low), sorts the sheet, and colour-fills the RPN/AP cells by risk. Schematex's first table-shaped diagram.",
+    cluster: "risk-reliability",
+    standard: "AIAG-VDA FMEA Handbook (2019) \xB7 IEC 60812:2018 \xB7 SAE J1739 \xB7 MIL-STD-1629A; see 40-FMEA-STANDARD.md",
+    syntaxKey: "fmea"
+  },
+  // ── Systems thinking / stochastic ────────────────────────────
+  {
+    type: "causalloop",
+    name: "Causal Loop Diagram",
+    tagline: "System-dynamics feedback map \u2014 signed causal links the engine reads to classify each loop as reinforcing (R) or balancing (B).",
+    useWhen: 'Use for systems thinking / system dynamics: variables connected by `+`/`\u2212` causal links, where the engine detects feedback loops and labels each R (even number of negative links) or B (odd). Header `causalloop`/`cld`; write `A -> B : +` links and optional `loop R1 "name"` annotations and `delay` marks. Distinct from `sociogram` (social ties, no polarity) and `flowchart` (process steps).',
+    cluster: "causality-analysis",
+    standard: "Sterman, Business Dynamics (2000) \xB7 Meadows, Thinking in Systems; see 41-CAUSAL-LOOP-STANDARD.md",
+    syntaxKey: "causalloop"
+  },
+  {
+    type: "markov",
+    name: "Markov chain",
+    tagline: "Discrete-time Markov chain \u2014 circles + probability arcs, with the stationary distribution and recurrent/transient/absorbing classification computed for you.",
+    useWhen: "Use to model a probabilistic state process (reliability/availability, queueing, regime models) where you want the long-run distribution or absorption answer, not just the picture. Header `markov`/`markovchain`; write `S1 -> S2 : 0.3` transitions (each state's out-edges sum to 1). The engine computes the stationary distribution, classifies states, and for absorbing chains the fundamental matrix. Sibling of `state` and `petri`.",
+    cluster: "behavior-modeling",
+    standard: "Norris, Markov Chains (1997) \xB7 Kemeny & Snell, Finite Markov Chains; see 42-MARKOV-CHAIN-STANDARD.md",
+    syntaxKey: "markov"
+  },
+  // ── Software / process engineering ───────────────────────────
+  {
+    type: "gitgraph",
+    name: "Git commit graph",
+    tagline: "Branch-and-merge commit history on per-branch swimlanes \u2014 Mermaid gitGraph compatible.",
+    useWhen: 'Use to visualise a git branching/merging history. Header `gitGraph`; ordered `commit`, `branch <name>`, `checkout <name>`, `merge <name>`, `cherry-pick id: "\u2026"`, with `commit id:/tag:/type: HIGHLIGHT|REVERSE`. Mermaid `gitGraph` syntax parity so LLM output is drop-in compatible. Commits sit on per-branch lanes ordered chronologically; merges join lanes.',
+    cluster: "software-uml",
+    standard: "Mermaid gitGraph syntax \xB7 git DAG model; see 43-GIT-GRAPH-STANDARD.md",
+    syntaxKey: "gitgraph"
+  },
+  {
+    type: "epc",
+    name: "Event-driven Process Chain (EPC)",
+    tagline: "ARIS business-process notation \u2014 alternating events (red hexagons) and functions (green rounded rects) joined by AND/OR/XOR connectors, with the alternation rule validated.",
+    useWhen: "Use for ARIS-style business process modelling (SAP / enterprise BPM). Header `epc`; declare `event`, `function`, connectors `and`/`or`/`xor`, and the control flow between them. The engine validates strict event\u2194function alternation and connector legality (an event cannot be the source of an OR/XOR split). Distinct from `bpmn` and `flowchart` \u2014 a separate published standard with stricter rules.",
+    cluster: "corporate-legal",
+    standard: "ARIS / Keller, N\xFCttgens & Scheer (1992); see 44-EPC-STANDARD.md",
+    syntaxKey: "epc"
+  },
+  {
+    type: "idef0",
+    name: "IDEF0 function model",
+    tagline: "Federal function-modelling standard \u2014 boxes are activities, arrows are positional (the ICOM rule: Input-left, Control-top, Output-right, Mechanism-bottom).",
+    useWhen: "Use to model what a system/process does and its inputs/controls/outputs/mechanisms \u2014 systems engineering, defence/government process docs, enterprise architecture. Header `idef0`; declare `function` boxes and ICOM arrows (`input`/`control`/`output`/`mechanism`) plus box\u2192box flows that name the target ICOM side. The engine enforces ICOM placement and assigns node numbers, in a diagonal box staircase.",
+    cluster: "project-management",
+    standard: "FIPS PUB 183 (1993) \xB7 SADT (Ross); see 45-IDEF0-STANDARD.md",
+    syntaxKey: "idef0"
+  },
+  {
+    type: "threatmodel",
+    name: "Threat model (DFD + STRIDE)",
+    tagline: "Security data-flow diagram where the engine annotates each element with its applicable STRIDE threats and flags every flow that crosses a trust boundary.",
+    useWhen: "Use for security threat modelling (Microsoft SDL / OWASP Threat Dragon workflow): DFD shapes (external entity, process, data store), labelled data flows, and `boundary` trust zones. Header `threatmodel`/`stride`. The engine maps each element type to its STRIDE categories (external = S,R; process = all six; store = T,I,D + conditional R for logs; flow = T,I,D) and accents flows crossing a trust boundary. Includes the DFD base notation (no separate `dfd` engine).",
+    cluster: "network-infrastructure",
+    standard: "Shostack, Threat Modeling (2014) STRIDE-per-element \xB7 Microsoft SDL \xB7 base DFD DeMarco/Yourdon; see 46-THREAT-MODEL-STRIDE-STANDARD.md + 31-DFD-STANDARD.md",
+    syntaxKey: "threatmodel"
   }
 ];
 var DIAGRAM_SINCE = {
@@ -390,7 +465,16 @@ var DIAGRAM_SINCE = {
   // 0.6.5
   faulttree: "0.6.5",
   // 0.6.6
-  bowtie: "0.6.6"
+  bowtie: "0.6.6",
+  // 0.8.0 — Bucket B (event tree, FMEA, causal loop, Markov, git graph, EPC, IDEF0, threat model)
+  eventtree: "0.8.0",
+  fmea: "0.8.0",
+  causalloop: "0.8.0",
+  markov: "0.8.0",
+  gitgraph: "0.8.0",
+  epc: "0.8.0",
+  idef0: "0.8.0",
+  threatmodel: "0.8.0"
 };
 function getDiagramSince(type) {
   const resolved = resolveDiagramType(type);
@@ -672,6 +756,44 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'breadboard\nboard: half\ntitle: "HC-SR04 distance sensor + Arduino Uno"\n\nparts\n  uno: mcu uno @beside-left\n  s1:  sensor hcsr04 @8a\n\nwires\n  s1:VCC  --red--    @+t1\n  s1:GND  --black--  @-t1\n  s1:TRIG --yellow-- @9c\n  s1:ECHO --green--  @10c\n  uno:5V  --red--    @+t1\n  uno:GND --black--  @-t1\n  uno:D9  --yellow-- @9c\n  uno:D10 --green--  @10c',
     "notes": "The HC-SR04 is the most common ultrasonic distance sensor in beginner Arduino kits. Four pins, four wires, no driver IC needed. The sensor module is rendered as a blue PCB tile with its four pin labels (VCC / TRIG / ECHO / GND) sitting above the breadboard rows where they plug in.\n\nThe TRIG line is a digital output from the Arduino \u2014 pulse it high for 10 \xB5s and the sensor fires an ultrasonic chirp. The ECHO line is a digital input \u2014 its high-time, in microseconds, is twice the round-trip distance divided by the speed of sound. Conventional wiring uses yellow for TRIG and green for ECHO so the two signals are visually distinguishable, though the colors carry no electrical meaning."
   },
+  {
+    "slug": "causalloop-growth-engine",
+    "diagram": "causalloop",
+    "title": "Startup growth engine (R and B loops)",
+    "description": "A system-dynamics model of a viral product whose growth is capped by scaling strain. The engine enumerates every feedback loop and classifies each reinforcing (R) or balancing (B) by Sterman's even/odd rule.",
+    "standard": "Sterman, Business Dynamics (2000)",
+    "tags": [
+      "causalloop",
+      "cld",
+      "system-dynamics",
+      "feedback",
+      "reinforcing",
+      "balancing"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'causalloop "Startup growth engine"\n  "Active users" -> "Word of mouth" : +\n  "Word of mouth" -> "New signups" : +\n  "New signups" -> "Active users" : +\n  "Active users" -> "Server load" : +\n  "Server load" -> "App performance" : -\n  "App performance" -> "Active users" : + delay\n  "Active users" -> Revenue : +\n  Revenue -> "Infra investment" : +\n  "Infra investment" -> "App performance" : + delay\n  loop R1 "Viral flywheel"\n  loop B1 "Scaling strain"',
+    "notes": '## What this shows\n\nThe two-sided story of every viral product. One reinforcing loop drives growth: more active users produce more word of mouth, which drives signups, which adds users \u2014 an amplifying cycle. A second, balancing loop pushes back: more users raise server load, which degrades app performance, which (after a delay) loses users. The `delay` markers put the system-dynamics hash mark on the slow legs, where the lag between cause and effect is what makes the system overshoot.\n\nThe engine finds and labels the loops for you, which a drawing tool cannot. It enumerates every elementary cycle in the signed graph with Johnson\'s algorithm, then applies Sterman\'s rule \u2014 count the negative links, even means reinforcing (R), odd means balancing (B) \u2014 and numbers them R1, B1\u2026 The growth cycle comes back R (zero negatives), the load cycle B (one negative). The named `loop` declarations attach the human phrasing \u2014 "Viral flywheel", "Scaling strain" \u2014 onto the loops the engine detects.'
+  },
+  {
+    "slug": "causalloop-traffic-congestion",
+    "diagram": "causalloop",
+    "title": "Urban traffic congestion (two balancing loops)",
+    "description": "The classic system-dynamics counterintuitive result \u2014 widening roads induces demand. The engine enumerates the feedback loops and classifies each reinforcing or balancing by link polarity.",
+    "standard": "Sterman, Business Dynamics (2000)",
+    "tags": [
+      "causalloop",
+      "cld",
+      "system-dynamics",
+      "induced-demand",
+      "balancing",
+      "transit"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": 'causalloop "Urban traffic congestion"\n  "Road capacity" -> "Travel speed" : +\n  "Travel speed" -> "Driving attractiveness" : +\n  "Driving attractiveness" -> "Number of cars" : +\n  "Number of cars" -> Congestion : +\n  Congestion -> "Travel speed" : -\n  Congestion -> "Public transit use" : +\n  "Public transit use" -> "Number of cars" : -\n  loop B1 "Congestion brake"\n  loop B2 "Transit substitution"',
+    "notes": "## What this shows\n\nThe system-dynamics model behind one of the most counterintuitive results in transport policy: widening a road does not durably cut congestion, because faster travel makes driving more attractive, which pulls more cars onto the road until it clogs again. Two balancing loops fight the build-up \u2014 congestion itself slows travel and dampens demand, and congestion pushes commuters onto public transit, which removes cars.\n\nThe engine classifies the loops by polarity rather than asking you to. It walks the signed graph, enumerates each elementary cycle, and counts the negative links: both feedback loops here carry an odd number of negative links, so both come back **balancing (B)** and are numbered B1, B2. That even/odd classification \u2014 Sterman's textbook rule \u2014 is the analysis a drawing tool skips, and it is what explains why the system settles back to congestion no matter how much capacity is added."
+  },
   {
     "slug": "circuit-bridge-rectifier-supply",
     "diagram": "circuit",
@@ -961,6 +1083,25 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'entity-structure "Acme Inc. \u2014 post Series A"\nentity acme "Acme Inc." corp@DE\nentity founders "Founders (2)" individual\nentity seed "Seed Fund I" lp@DE\nentity lead "Sequoia Series A" lp@DE\nentity angels "Angel group" individual\nentity esop "Employee Option Pool" trust@DE\nfounders -> acme : 45%\nseed -> acme : 12%\nlead -> acme : 22%\nangels -> acme : 6%\nesop -> acme : 15%',
     "notes": "## Scenario\n\nA startup attorney or CFO documents the post-Series A ownership table for a 409A valuation, board consent, or investor report. The cap table diagram makes the dilution story visual \u2014 founders can immediately see their post-money percentage, and the VC can verify their ownership stake before signing the term sheet.\n\n## Annotation key\n\n- `-> acme : 45%` \u2014 ownership arrow with percentage label; all percentages should sum to 100%\n- `individual` \u2014 natural person (founder, angel)\n- `lp` \u2014 institutional investor entity (fund/LP)\n- `trust` \u2014 the ESOP/option pool (typically a Delaware trust or reserved pool)\n- `corp@DE` \u2014 the issuer (Delaware C-corp)\n\n## How to read\n\nAcme Inc. (Delaware C-corp) sits at the bottom as the issuer. Five shareholder classes flow down with their ownership arrows: founders at 45%, the lead Series A investor at 22%, the employee option pool at 15%, the seed fund at 12%, and angels at 6%. Percentages sum to 100%, representing a clean fully-diluted cap table on the day of Series A close."
   },
+  {
+    "slug": "epc-procurement",
+    "diagram": "epc",
+    "title": "Procurement EPC with XOR split",
+    "description": "An ARIS event-driven process chain for purchase requisitions, branching on an XOR connector and re-joining on an AND. The engine validates EPC well-formedness \u2014 event/function alternation and the event-cannot-decide rule.",
+    "standard": "ARIS EPC (Scheer)",
+    "tags": [
+      "epc",
+      "aris",
+      "business-process",
+      "xor",
+      "and",
+      "control-flow"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'epc "Purchase requisition"\n  layout: tb\n  event E1 "Material need identified"\n  function F1 "Create requisition"\n  function F2 "Determine source of supply"\n  xor X1\n  event E2 "Stock supplier exists"\n  event E3 "New supplier needed"\n  function F3 "Issue purchase order"\n  function F4 "Run tender process"\n  and A1\n  event E4 "Order dispatched"\n  event E5 "Supplier qualified"\n  E1 -> F1 -> F2 -> X1\n  X1 -> E2\n  X1 -> E3\n  E2 -> F3 -> A1\n  E3 -> F4 -> A1\n  A1 -> E4\n  A1 -> E5',
+    "notes": '## What this shows\n\nA SAP-style procurement process modelled as an ARIS event-driven process chain (EPC), the notation that strictly alternates passive **events** ("Material need identified") and active **functions** ("Create requisition"). After sourcing, an **XOR** connector splits the flow on a real decision \u2014 an existing stock supplier versus a new supplier needing a tender \u2014 and the two paths re-converge on an **AND** connector that fans back out to the dispatched order and the qualified-supplier outcome.\n\nEPC\'s value here is structural validation, not a computed number. The engine checks the well-formedness rules and flags violations rather than silently drawing a broken model: event/function alternation along every path, single-in/single-out multiplicity carried by the connectors, reachability from start to end, and the **event-cannot-decide signature rule** \u2014 a passive event may not be the source of an XOR/OR split. That\'s why the decision routes *through* function `F2` before reaching the XOR, which is the correct ARIS form.'
+  },
   {
     "slug": "erd-billing-ledger-audit-trail",
     "diagram": "erd",
@@ -1035,6 +1176,44 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'erd\ntitle: "University Schema"\n\ntable Student {\n  student_id  int       PK\n  name        varchar\n  email       varchar   UK\n  major_id    int       FK -> Major.major_id\n}\n\ntable Major {\n  major_id    int       PK\n  name        varchar\n}\n\ntable Course {\n  course_id   int       PK\n  title       varchar\n  credits     int\n}\n\ntable Enrollment {\n  student_id  int       PK FK -> Student.student_id\n  course_id   int       PK FK -> Course.course_id\n  grade       char\n}\n\nref Student.major_id many-mandatory -- one-mandatory Major.major_id : "majors in"\nref Enrollment.student_id many-mandatory -- one-mandatory Student.student_id\nref Enrollment.course_id many-mandatory -- one-mandatory Course.course_id',
     "notes": "The university schema is the canonical introduction to associative entities. The M:N relationship between Student and Course is resolved through Enrollment, which carries the relationship attribute `grade`. Both Student and Course join Enrollment via composite primary keys (each FK column doubles as part of the PK)."
   },
+  {
+    "slug": "eventtree-flammable-release",
+    "diagram": "eventtree",
+    "title": "Flammable release event tree (process QRA)",
+    "description": "A loss-of-containment release branched through detection, isolation, and ignition. The engine computes each outcome frequency \u2014 safe shutdown, jet fire, dispersion, vapour-cloud explosion \u2014 and flags the dominant one.",
+    "standard": "IEC 62502 / process QRA",
+    "tags": [
+      "eventtree",
+      "eta",
+      "qra",
+      "loss-of-containment",
+      "ignition",
+      "explosion"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": 'eventtree "Flammable release"\n  initiating REL "Loss of containment" freq: 0.02\n  function DET "Gas detection alarms" p: 0.05\n  function ISO "Emergency isolation" p: 0.1\n  function IGN "No ignition source" p: 0.3\n  outcome s s s -> "Safe shutdown"\n  outcome s s f -> "Jet fire"\n  outcome s f * -> "Large dispersion"\n  outcome f * * -> "Vapour cloud explosion"',
+    "notes": "## What this shows\n\nThe quantitative risk assessment (QRA) event tree a process-safety study runs after a HAZOP flags a credible leak. The initiating event \u2014 a flammable release at `0.02` per year \u2014 is challenged by three safety functions in order: gas detection, emergency isolation, and the chance of no ignition source. The `IGN` function reads as a *success* when there is no ignition (`s`), so its failure leg `f` is where the fire or explosion lives.\n\nThe value is the computed end-state frequencies. The engine propagates the release frequency through each branch's success/failure probability to size each consequence \u2014 safe shutdown, jet fire, large dispersion, vapour-cloud explosion \u2014 and accents the dominant sequence in red, the same role the single point of failure plays in a fault tree. That ranked, numeric reading is what turns a forking ladder into an analysis."
+  },
+  {
+    "slug": "eventtree-loca",
+    "diagram": "eventtree",
+    "title": "Large LOCA event tree (reactor PRA)",
+    "description": "A large-break loss-of-coolant accident branched through four reactor safety functions. The engine computes every sequence frequency from the initiating rate and per-function failure probabilities, then highlights the dominant accident sequence.",
+    "standard": "IEC 62502 / NUREG (WASH-1400)",
+    "tags": [
+      "eventtree",
+      "eta",
+      "pra",
+      "nuclear",
+      "sequence-frequency",
+      "core-damage"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'eventtree "Large LOCA"\n  initiating LOCA "Large-break LOCA" freq: 1e-4\n  function RT "Reactor trips" p: 0.001\n  function ECCS "ECCS injection" p: 0.01\n  function CHR "Containment heat removal" p: 0.02\n  function CI "Containment integrity" p: 0.005\n  outcome s s s s -> "OK"\n  outcome s s s f -> "Late release"\n  outcome s s f * -> "Late release"\n  outcome s f * * -> "Early release"\n  outcome f * * * -> "Core damage"',
+    "notes": '## What this shows\n\nThe textbook nuclear probabilistic-risk-assessment (PRA) tree. One initiating event \u2014 a large pipe break draining the coolant at a frequency of `1e-4` per year \u2014 is asked, left to right, whether each safety function holds: reactor trip, emergency core cooling (ECCS), containment heat removal, then containment integrity. Each `*` prunes a path that has already terminated, so the tree stays compact instead of ballooning to a full 2\u2074 ladder.\n\nThe engine does the arithmetic an event tree exists to give. It multiplies the initiating frequency by the success leg (`1 \u2212 p`) or failure leg (`p`) at each branch to get every sequence frequency, sums the two `"Late release"` leaves into one rolled-up outcome, and paints the largest-frequency path \u2014 the dominant accident sequence \u2014 in red. That computed answer, not the forking picture, is the deliverable a drawing tool can\'t produce.'
+  },
   {
     "slug": "faulttree-pump-redundancy",
     "diagram": "faulttree",
@@ -1260,6 +1439,44 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": "flowchart LR\n  start([New order received])\n  start --> validate{Inventory available?}\n  validate -->|Yes| reserve[Reserve items]\n  validate -->|No| notify[Notify customer]\n  notify --> done([End])\n  reserve --> payment{Payment authorized?}\n  payment -->|Yes| ship[Ship order]\n  payment -->|No| cancel[Cancel & release]\n  ship --> confirm[Send confirmation email]\n  confirm --> done\n  cancel --> done",
     "notes": '## Scenario\n\nA product ops lead circulates this flowchart during an ops-review meeting to align engineering, customer support, and fulfillment on the single source of truth for what happens when a new order comes in. It surfaces the two decision gates (inventory, payment) and the three exception paths (out-of-stock notification, payment failure with released hold, successful ship with confirmation).\n\n## Annotation key\n\n- `([\u2026])` \u2014 stadium / terminal; used for Start and End\n- `{\u2026}` \u2014 diamond; decision node\n- `[\u2026]` \u2014 rectangle; process step\n- `-->|label|` \u2014 edge with a branch label (`Yes` / `No`)\n\n## How to read\n\nStart at the top-left terminal. Inventory check gates the first branch \u2014 a "No" routes straight to the End after notification. A "Yes" reserves stock then hits the payment gate. Payment failure releases the reservation and goes to End; success ships and emails the customer. Every path terminates at the same End node, so nothing dangles.'
   },
+  {
+    "slug": "fmea-ev-battery-dfmea",
+    "diagram": "fmea",
+    "title": "EV battery pack DFMEA",
+    "description": "A design FMEA for an electric-vehicle battery pack. The engine flattens the failure chain, computes RPN = S \xD7 O \xD7 D, and derives the AIAG-VDA Action Priority \u2014 keeping a S10 safety failure High even when its RPN looks low.",
+    "standard": "AIAG-VDA FMEA Handbook (2019) / IEC 60812",
+    "tags": [
+      "fmea",
+      "dfmea",
+      "rpn",
+      "action-priority",
+      "severity",
+      "automotive"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'fmea "EV battery pack DFMEA"\n  type: design\n  rank: ap\n  flag: ap >= High\n  number: DFMEA-2026-014\n  item "Cell module" fn "Store and deliver energy"\n    mode "Thermal runaway"\n      effect "Pack fire / occupant injury" sev: 10\n      cause "Internal short from dendrite growth" occ: 3\n        controls prevention: "Cell qualification", detection: "In-line CT scan" det: 4\n      cause "Overcharge past cutoff" occ: 2\n        controls prevention: "BMS voltage clamp", detection: "Redundant voltage sense" det: 3\n    mode "Capacity fade"\n      effect "Reduced range" sev: 6\n      cause "Electrolyte depletion" occ: 5\n        controls detection: "Periodic SOH estimate" det: 6\n  item "Busbar joint" fn "Conduct current between modules"\n    mode "High-resistance connection"\n      effect "Local overheating" sev: 8\n      cause "Loose torque on weld" occ: 4\n        controls detection: "End-of-line resistance test" det: 4',
+    "notes": "## What this shows\n\nA design FMEA (DFMEA) on the highest-stakes subsystem in an electric vehicle. The nested chain reads item \u2192 mode \u2192 effect/cause/controls: a cell module that can suffer thermal runaway or capacity fade, and a busbar joint that can go high-resistance. Each effect carries a Severity, each cause an Occurrence, each control the Detection it earns \u2014 the three AIAG-VDA 1\u201310 scales.\n\nThe engine computes the priority rather than just tabling it. It flattens to one worksheet row per (item, mode, cause), multiplies RPN = S \xD7 O \xD7 D, and \u2014 the part that matters \u2014 derives the AIAG-VDA Action Priority, which is severity-primary. The thermal-runaway row sits at S10\xB7O3\xB7D4 with an RPN of 120; a naive RPN sort would rank it below a noisier low-severity defect, but Action Priority keeps every safety failure (S = 9\u201310) at **High** regardless. The `flag: ap >= High` directive highlights exactly those rows so the safety-critical work rises to the top."
+  },
+  {
+    "slug": "fmea-injection-molding-pfmea",
+    "diagram": "fmea",
+    "title": "Injection-moulding PFMEA",
+    "description": "A process FMEA for an injection-moulding line, ranked the legacy way by RPN. The engine computes RPN = S \xD7 O \xD7 D for every (step, mode, cause) row and flags the ones that breach the 100 threshold.",
+    "standard": "AIAG-VDA FMEA Handbook (2019) / IEC 60812",
+    "tags": [
+      "fmea",
+      "pfmea",
+      "rpn",
+      "process",
+      "manufacturing",
+      "scrap"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": 'fmea "Injection moulding PFMEA"\n  type: process\n  rank: rpn\n  flag: rpn > 100\n  item "Mould fill step" fn "Fill cavity with melt"\n    mode "Short shot"\n      effect "Incomplete part scrapped" sev: 7\n      cause "Injection pressure too low" occ: 5\n        controls prevention: "Pressure setpoint lock", detection: "Vision check" det: 4\n      cause "Blocked gate" occ: 3\n        controls detection: "Cycle-time monitor" det: 6\n  item "Cooling step" fn "Solidify part to spec"\n    mode "Warpage"\n      effect "Out-of-tolerance dimension" sev: 6\n      cause "Uneven cooling channel flow" occ: 6\n        controls detection: "CMM sampling" det: 7',
+    "notes": "## What this shows\n\nA process FMEA (PFMEA) following the steps of an injection-moulding line \u2014 the fill step and the cooling step \u2014 rather than the parts of a product. Each process step gets its failure modes (short shot, warpage), the effect each has on the part, the process causes behind it, and the in-line controls that prevent or detect it.\n\nThis worksheet is ranked the legacy way with `rank: rpn`, so the engine sorts purely on RPN = S \xD7 O \xD7 D and the `flag: rpn > 100` directive lights up every row above 100 \u2014 here the uneven-cooling warpage row at S6\xB7O6\xB7D7 (RPN 252) and the short-shot pressure row at S7\xB7O5\xB7D4 (RPN 140). Each rendered row carries `data-rpn` and `data-ap`, so even on a legacy RPN worksheet the AIAG-VDA Action Priority is still computed and inspectable underneath."
+  },
   {
     "slug": "genogram-brca-cancer",
     "diagram": "genogram",
@@ -1349,6 +1566,44 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'genogram "The Potter Family"\n  fleamont [male, 1909, 1979, deceased]\n  euphemia [female, 1920, 1979, deceased]\n  fleamont -- euphemia\n    james [male, 1960, 1981, deceased]\n  mr_evans [male, 1925, deceased]\n  mrs_evans [female, 1928, deceased]\n  mr_evans -- mrs_evans\n    lily [female, 1960, 1981, deceased]\n    petunia [female, 1958]\n  james -- lily "m. 1978"\n    harry [male, 1980, index]\n  petunia -- vernon [male, 1951]\n    dudley [male, 1980]\n  harry -cutoff- petunia\n  harry -hostile- dudley\n  harry -close- lily',
     "notes": '## Scenario\n\nA teaching example for social work students learning genogram notation. The Potter family is fictional but emotionally rich \u2014 death years, a marriage date, cross-family emotional relationships, and three distinct relational patterns (cutoff, hostile, close) all in one diagram.\n\n## Annotation key\n\n- `[male/female, birth_year, death_year, deceased]` \u2014 person with death marker\n- `"m. 1978"` \u2014 marriage date label on the union line\n- `index` \u2014 marks Harry as the identified patient (proband)\n- `-cutoff-` \u2014 estrangement; drawn as two parallel bars across the relationship line\n- `-hostile-` \u2014 conflict; drawn as zigzag line\n- `-close-` \u2014 enmeshment/closeness; drawn as double parallel line\n\n## How to read\n\nRead each indented block as a family unit. James and Lily (index generation) both died in 1981. Harry\'s emotional world is defined by three relational lines: cutoff from Aunt Petunia, hostility toward cousin Dudley, and closeness to his deceased mother.'
   },
+  {
+    "slug": "gitgraph-release-flow",
+    "diagram": "gitgraph",
+    "title": "Git Flow release history",
+    "description": "A realistic Git Flow branch/merge/tag history \u2014 develop, a feature branch, a tagged release, and a hotfix merged back to both lines. Mermaid gitGraph syntax, rendered through Schematex's zero-dependency engine.",
+    "standard": "Mermaid gitGraph dialect",
+    "tags": [
+      "gitgraph",
+      "git-flow",
+      "branch",
+      "merge",
+      "tag",
+      "hotfix"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'gitGraph\n  commit id: "init"\n  commit id: "scaffold"\n  branch develop\n  checkout develop\n  commit id: "feature scaffold"\n  branch feature/login\n  checkout feature/login\n  commit id: "login UI"\n  commit id: "login API"\n  checkout develop\n  merge feature/login\n  commit id: "polish"\n  checkout main\n  merge develop tag: "v1.0"\n  branch hotfix\n  checkout hotfix\n  commit id: "patch CVE" type: HIGHLIGHT\n  checkout main\n  merge hotfix tag: "v1.0.1"\n  checkout develop\n  merge main',
+    "notes": "## What this shows\n\nA full Git Flow release cycle, the branching strategy teams adopt to keep a clean trunk. Work forks off `main` into a long-lived `develop`, then into a short-lived `feature/login` branch; the feature merges back to develop, develop merges to `main` as the tagged `v1.0` release. Then a security `hotfix` branches straight off `main`, lands a HIGHLIGHT commit, ships as `v1.0.1`, and is merged back down into develop so the fix isn't lost \u2014 the discipline that keeps the two lines from diverging.\n\nThe DSL is the Mermaid `gitGraph` dialect verbatim, so existing Mermaid sources port directly. The engine replays the operation list in order to assign each commit to a lane, routes the merge connectors from each branch tip without crossings, renders the patch commit emphasised as a HIGHLIGHT, and draws the version tags as flags \u2014 all from a KB-scale, dependency-free bundle."
+  },
+  {
+    "slug": "idef0-order-fulfilment",
+    "diagram": "idef0",
+    "title": "IDEF0 A0 \u2014 fulfil customer order",
+    "description": "An IDEF0 A0 function decomposition with all four ICOM arrow types. Inputs, controls, mechanisms and outputs each pin to a fixed box edge, so the model is correct by construction per FIPS PUB 183.",
+    "standard": "FIPS PUB 183 (IDEF0)",
+    "tags": [
+      "idef0",
+      "icom",
+      "function-model",
+      "decomposition",
+      "fips-183",
+      "structured-analysis"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'idef0 "Fulfil customer order"\nnode A0\nfunction A1 "Validate order"\nfunction A2 "Pick and pack"\nfunction A3 "Ship and invoice"\ninput     A1 "Customer order"\ncontrol   A1 "Credit policy"\nmechanism A1 "Order management system"\nA1 -> A2 "Validated order"\ninput     A2 "Inventory"\ncontrol   A2 "Picking rules"\nmechanism A2 "Warehouse staff"\nA2 -> A3 "Packed shipment"\ncontrol   A3 "Carrier contract"\nmechanism A3 "Shipping carrier"\noutput    A3 "Delivered order"\noutput    A3 "Invoice"',
+    "notes": '## What this shows\n\nAn IDEF0 A0 diagram \u2014 the top-level functional decomposition of an order-fulfilment system \u2014 showing all four ICOM arrow roles. Reading the box edges by convention: **I**nputs enter on the left (the customer order, inventory), **C**ontrols govern from the top (credit policy, picking rules, carrier contract), **M**echanisms supply resources from the bottom (the order system, warehouse staff, carrier), and **O**utputs leave on the right (delivered order, invoice). The box-to-box flows (`A1 -> A2 "Validated order"`) chain the three activities.\n\nThe differentiator is that the model is correct by construction, not just drawn. Because the arrow keyword *is* the box edge it attaches to, the engine enforces ICOM placement \u2014 you cannot accidentally draw a control as an input. It resolves every box reference, assigns decomposition numbers (A0 \u2192 A1..A3), codes the boundary arrows down each edge (I1/C1/O1/M1\u2026), and applies the FIPS 3-to-6-box guideline. A flow that tried to *enter* a box via its `.output` edge would be rejected, because an output leaves a box \u2014 the standard is enforced, not suggested.'
+  },
   {
     "slug": "ladder-conveyor-interlock",
     "diagram": "ladder",
@@ -1459,6 +1714,58 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'logic "1-bit Full Adder"\ninput A, B, Cin\noutput Sum, Cout\ns1 = XOR(A, B)\nSum = XOR(s1, Cin)\nc1 = AND(A, B)\nc2 = AND(s1, Cin)\nCout = OR(c1, c2)',
     "notes": "## Scenario\n\nThe 1-bit full adder is the foundational building block of every arithmetic logic unit. Digital logic students derive it in lecture; FPGA engineers instantiate it in RTL. Schematex renders it from a purely functional description \u2014 no manual gate placement, no wire routing \u2014 making it easy to embed in textbooks, datasheets, or AI-generated hardware documentation.\n\n## Annotation key\n\n- `input A, B, Cin` \u2014 declare named input ports\n- `output Sum, Cout` \u2014 declare named output ports\n- `s1 = XOR(A, B)` \u2014 intermediate signal `s1` is the XOR of inputs A and B\n- `Sum = XOR(s1, Cin)` \u2014 the sum bit is the XOR of the partial sum and carry-in\n- `c1 = AND(A, B)` \u2014 carry generated when both A and B are 1\n- `c2 = AND(s1, Cin)` \u2014 carry propagated when partial sum is 1 and Cin is 1\n- `Cout = OR(c1, c2)` \u2014 carry-out is 1 if either generate or propagate carry is active\n\n## How to read\n\nThe diagram renders two XOR gates for the sum path (A\u2295B, then \u2295Cin) and two AND gates feeding an OR for the carry-out (the standard generate/propagate structure). The layout is automatically ranked so data flows left to right, inputs on the left edge, outputs on the right. Every 4-bit or 8-bit ripple-carry adder in textbooks is just this circuit chained together."
   },
+  {
+    "slug": "markov-customer-lifecycle",
+    "diagram": "markov",
+    "title": "Customer lifecycle (ergodic chain, stationary \u03C0)",
+    "description": "A SaaS trial \u2192 active \u2192 churned chain. The engine validates the row-stochastic matrix, confirms the chain is ergodic, and computes the long-run stationary distribution \u03C0 \u2014 the steady-state share of customers in each state.",
+    "standard": "Kemeny & Snell, Finite Markov Chains",
+    "tags": [
+      "markov",
+      "stationary",
+      "ergodic",
+      "lifecycle",
+      "churn",
+      "steady-state"
+    ],
+    "complexity": 2,
+    "featured": false,
+    "dsl": 'markov "Customer lifecycle"\n  analysis: classify, stationary\n  Trial -> Trial : 0.4\n  Trial -> Active : 0.5\n  Trial -> Churned : 0.1\n  Active -> Active : 0.8\n  Active -> Trial : 0.05\n  Active -> Churned : 0.15\n  Churned -> Churned : 0.7\n  Churned -> Trial : 0.3',
+    "notes": "## What this shows\n\nA SaaS customer modelled as a memoryless hop between three states \u2014 Trial, Active, Churned \u2014 each month. Every row of probabilities leaving a state sums to 1 (the row-stochastic rule), and because churned customers can re-enter via Trial (`Churned -> Trial : 0.3`), no state is a dead end: the chain is **ergodic**, every state reachable from every other.\n\nThe engine does the linear algebra. It validates the matrix, runs SCC analysis to confirm a single recurrent class with no absorbing sink, then computes the **stationary distribution \u03C0** \u2014 the long-run share of your customer base sitting in each state once the system settles, independent of where it started. That steady-state answer (and the per-state classification) is carried in `data-*`, and it is the number a churn model exists to produce, not the circles-and-arrows."
+  },
+  {
+    "slug": "markov-gamblers-ruin",
+    "diagram": "markov",
+    "title": "Gambler's ruin (absorbing chain)",
+    "description": "The classic absorbing Markov chain with two sinks. The engine classifies the transient and absorbing states and computes the fundamental matrix \u2014 the probability of ending broke vs rich and the expected number of steps to absorption.",
+    "standard": "Kemeny & Snell, Finite Markov Chains",
+    "tags": [
+      "markov",
+      "absorbing",
+      "fundamental-matrix",
+      "gamblers-ruin",
+      "transient",
+      "expected-steps"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": `markov "Gambler's ruin"
+  analysis: classify, absorbing
+  state Broke "$0" absorbing
+  state Rich "$4" absorbing
+  state S1
+  state S2
+  state S3
+  Broke -> Broke : 1
+  Rich -> Rich : 1
+  S1 -> Broke : 0.5
+  S1 -> S2 : 0.5
+  S2 -> S1 : 0.5
+  S2 -> S3 : 0.5
+  S3 -> S2 : 0.5
+  S3 -> Rich : 0.5`,
+    "notes": "## What this shows\n\nThe canonical absorbing Markov chain. A gambler with \\$1, \\$2, or \\$3 (states S1\u2013S3) bets on a fair coin, moving up or down \\$1 each round, and stops only at ruin (\\$0) or the target (\\$4). The two endpoints are declared `absorbing` \u2014 once entered, never left (a self-loop of probability 1) \u2014 and the engine cross-checks that assertion against the matrix.\n\nThis is where the engine's linear algebra pays off. It classifies S1\u2013S3 as **transient** and Broke/Rich as **absorbing**, then forms the fundamental matrix N = (I \u2212 Q)\u207B\xB9 to compute the two answers an absorbing chain is built for: the **absorption probabilities** (starting from each state, the chance of ending broke vs rich \u2014 for a fair game, proportional to the distance to each barrier) and the **expected number of steps to absorption**. Those computed values, carried in `data-*`, are the result no drawing tool can give."
+  },
   {
     "slug": "matrix-9-box-talent",
     "diagram": "matrix",
@@ -2711,6 +3018,25 @@ If the LED doesn't light up, three things to check, in order: LED polarity (the
     "dsl": 'state "Traffic Light"\n\ninitial i\nfinal f\n\ni -> Red\nRed -> Green : timer\nGreen -> Yellow : timer\nYellow -> Red : timer\nRed -> f : power_off',
     "notes": "The traffic light is to state diagrams what the pump loop is to P&IDs: every textbook uses it, every engineer has drawn it, and if you understand it you understand the grammar of every more complex model.\n\n**Why a state diagram and not a flowchart.** A flowchart for a traffic light would show a loop: start \u2192 Red \u2192 (timer fires?) \u2192 Green \u2192 (timer fires?) \u2192 Yellow \u2192 back to Red. That works for describing an algorithm, but it misses the essential question: *what is the system doing right now?* A state machine makes the current state a first-class concept. The traffic light is not executing a loop \u2014 it *is* Red, or it *is* Green. Transitions are events that change what it is. This distinction matters the moment you add complexity: \"what happens if a pedestrian button is pressed while we're in Green?\" You answer that by looking at the transitions out of Green, not by tracing a flowchart path.\n\n**UML pseudo-states.** The filled black circle (`initial i`) and the bull's-eye circle (`final f`) are pseudo-states \u2014 they are not real states the system can dwell in, just notational entry and exit points. The initial pseudo-state shows where the machine starts; the arrow from `i` to Red tells you Red is the first real state. The final pseudo-state shows where the machine terminates. In the traffic light, termination is the `power_off` event from Red \u2014 the system shuts down from the Red state only (it wouldn't be safe to power off mid-Green).\n\n**Transition labels.** Each arrow is labeled with the trigger event that causes the transition. `timer` means \"the countdown for this phase has elapsed.\" In a real embedded implementation, this would be a hardware timer interrupt or a software watchdog expiry. Schematex doesn't execute the state machine \u2014 it renders the model. The labels are free text; you write exactly what your system calls the event.\n\n**Cyclic structure.** The three main states form a cycle: Red \u2192 Green \u2192 Yellow \u2192 Red. Most state diagrams describing continuous systems have cycles \u2014 the system runs until something external stops it. The `power_off` transition is the only way to reach the final state, and it is only modeled on Red because that is the safe state to stop in. If you wanted to model an emergency override (traffic officer stops the light mid-cycle), you would add `power_off` transitions from Green and Yellow too.\n\n**From model to code.** A UML state diagram maps directly to an enum + switch statement, a state table, or a state-machine framework (XState, Boost.MSM, Qt State Machine). The diagram is the specification; the implementation strategy is separate. Generating this diagram from a DSL means you can keep the spec in version control alongside the code, diff it in PRs, and regenerate it from an LLM prompt when requirements change."
   },
+  {
+    "slug": "threatmodel-ecommerce-checkout",
+    "diagram": "threatmodel",
+    "title": "E-commerce checkout threat model (STRIDE)",
+    "description": "A security data-flow diagram for a checkout flow with three trust boundaries. The engine applies the STRIDE-per-element mapping and flags every flow that crosses a trust boundary \u2014 where spoofing and tampering concentrate.",
+    "standard": "Microsoft STRIDE / Shostack (2014)",
+    "tags": [
+      "threatmodel",
+      "stride",
+      "dfd",
+      "trust-boundary",
+      "security",
+      "data-flow"
+    ],
+    "complexity": 3,
+    "featured": false,
+    "dsl": 'threatmodel "E-commerce checkout"\nexternal: Customer\nexternal: Payment Gateway\nprocess 1.0: Web App\nprocess 2.0: Order Service\ndatastore D1: Orders DB\ndatastore D2: Audit Log\nCustomer -> 1.0 : "HTTPS Checkout"\n1.0 -> 2.0 : "Place order"\n2.0 -> D1 : "Write order"\n2.0 -> Payment Gateway : "Charge card"\n2.0 -> D2 : "Order event"\nboundary "Internet" { Customer, Payment_Gateway }\nboundary "DMZ" { 1.0 }\nboundary "Internal" { 2.0, D1, D2 }',
+    "notes": "## What this shows\n\nA STRIDE threat model of an e-commerce checkout drawn as a data-flow diagram (DFD): two external entities (the customer and a third-party payment gateway), two processes (the web app in the DMZ, the order service internally), and two data stores (the orders database and an audit log). Three trust boundaries partition the system \u2014 Internet, DMZ, Internal \u2014 and the labelled flows carry the data crossing between them.\n\nThe engine does the STRIDE-per-element analysis, not just the boxes. It applies the canonical mapping \u2014 externals get Spoofing/Repudiation, processes get the full S-T-R-I-D-E, stores get Tampering/Information-disclosure/DoS, and the **audit log additionally gets Repudiation** because it matches the log/journal pattern. Most usefully, it **flags every flow that crosses a trust boundary** \u2014 the customer\u2192web-app HTTPS request (Internet\u2192DMZ), the order-service\u2192payment-gateway charge (Internal\u2192Internet) \u2014 because boundary crossings are where spoofing, tampering, and information disclosure concentrate. Each element and flow carries its applicable STRIDE categories in `data-*`."
+  },
   {
     "slug": "timeline-company-milestones",
     "diagram": "timeline",
@@ -3138,6 +3464,38 @@ var SYNTAX = {
   "bowtie": {
     "title": "Bowtie Risk Diagram",
     "content": '## 1. Your first diagram\n\nEvery document starts with the `bowtie` keyword, an optional title, then the hazard, the top event, and the two wings:\n\n```\nbowtie\ntopevent "Loss of containment"\nthreat "Corrosion"\n  prevent "Inspection programme"\nconsequence "Release to atmosphere"\n  mitigate "Gas detection + ESD"\n```\n\n`topevent` declares the single knot at the centre (mandatory, exactly one). Each `threat` starts a left-wing line; each `consequence` ends a right-wing line. A barrier under a `threat` is **preventative** (`prevent`); under a `consequence` it is **mitigative** (`mitigate`). The diagram is laid out symmetrically about the knot \u2014 threats fan in from the left, consequences fan out to the right.\n\nThe DSL is **indentation-structured** and mirrors the CCPS 7-step build methodology: identify the hazard \u2192 the top event \u2192 the threats \u2192 the consequences \u2192 the preventative barriers \u2192 the mitigative barriers \u2192 the escalation factors.\n\nHeader directives (any order):\n\n- `layout: symmetric | compact` \u2014 band model (default `symmetric`).\n- `legend: on | off | bottom | top` \u2014 the auto-derived colour legend (default on).\n\n---\n\n## 2. Hazard and top event\n\n```\nhazard "Working at height"\ntopevent "Person falls from height"\n```\n\n- **`hazard`** \u2014 the operation or material with the potential to cause harm: the *context* the bowtie is about (e.g. "Working at height", "Hydrocarbon under pressure"). Optional; renders as a header box above the knot with a tie-line down to it. At most one.\n- **`topevent`** \u2014 the moment control of the hazard is **lost** (e.g. "Loss of containment", "Person falls from height"). The knot of the bowtie, drawn as a green circle. **Mandatory, exactly one.**\n\nA hazard is a *thing/activity*, not a failure; the top event is the precise moment of *loss of control* \u2014 not a cause, and not yet a consequence.\n\n---\n\n## 3. Threats and consequences\n\n```\nthreat "Guardrail removed for access"\n  prevent "Permit-to-work system"\n\nconsequence "Fatality"\n  mitigate "Fall-arrest harness + lanyard"\n```\n\n- A **threat** is a credible cause that, *on its own*, could trigger the top event. Each threat is the start of one left-wing line, drawn as an orange box on the left edge.\n- A **consequence** is a credible outcome *of the top event* (not of the threat), drawn as a red box on the right edge.\n\nThreats and consequences may be declared in any interleaved order \u2014 the parser groups all left-wing blocks and all right-wing blocks regardless of sequence. A bowtie needs **at least one of each**: a one-wing diagram is a fault tree (see `faulttree`) or an event tree, not a bowtie.\n\n---\n\n## 4. Barriers (the controls in between)\n\n```\nthreat "Guardrail removed for access"\n  prevent "Permit-to-work system"\n  prevent "Temporary edge protection"\n  prevent "Spotter / banksman"\n```\n\nA **barrier** is a control that interrupts the threat \u2192 top-event path (preventative) or reduces the consequence after the top event (mitigative). Each is a grey box *on the line*. Chains are free length (1..n) \u2014 the wing simply extends.\n\n**Barrier order is declaration order**: the first declared is the **outermost** (closest to the threat/consequence, the first line of defence); the last declared is the **innermost** (closest to the knot). This matches the left-to-right reading of a real bowtie. Each barrier carries `data-order` (0 = outermost) and `data-side` (`prevent` / `mitigate`) for downstream interactivity.\n\nWhen chains differ in length, barriers are **centre-anchored**: the innermost barriers align in a neat column near the knot, and the threat/consequence boxes are ragged by chain depth \u2014 reading as defence-in-depth.\n\n---\n\n## 5. Escalation factors\n\n```\nthreat "Corrosion"\n  prevent "UT thickness inspection"\n    escalation "Inspection interval too long"\n      barrier "Risk-based inspection scheme"\n```\n\nAn **escalation factor** (or degradation factor) is a condition that *degrades a specific barrier\'s effectiveness* \u2014 e.g. "Edge protection not inspected", "Operator fatigue". It attaches to **one** barrier (not to the line) and drops vertically below it as an amber box, joined by a muted "degrades" connector.\n\nAn **escalation-factor barrier** is a control placed on the escalation factor itself \u2014 it protects the barrier from being degraded (e.g. a pre-use inspection regime). It nests one level deeper, under the escalation factor, and renders as a grey box below it.\n\nIndentation binds the nesting: `prevent`/`mitigate` at 2 spaces, `escalation` at 4, `barrier` at 6.\n\n---\n\n## 6. Correct by construction (the barrier rule set)\n\nBefore it draws a single shape, the engine validates the structural half of the CCPS/EI barrier rule set and **refuses to render** on failure \u2014 exactly as `prisma` refuses missing counts:\n\n- **Exactly one top event** \u2014 zero or several is an error.\n- **Every threat has \u2265 1 preventative barrier** \u2014 a bare threat is a Swiss-cheese cartoon, not a bowtie.\n- **Every consequence has \u2265 1 mitigative barrier** \u2014 the mirror rule.\n- **Every escalation factor is attached to a barrier** \u2014 it cannot float on a line or on the top event.\n- **At least one threat and one consequence** \u2014 a one-wing diagram is an FTA or an ETA.\n\nMessages name the offending element and the rule in plain English, e.g. *"Threat \'Corrosion\' has no preventative barrier \u2014 every threat must reach the top event through at least one barrier (CCPS/EI barrier rule). Add a `prevent` line under it."* This is what separates a real bowtie from a doodle. The engine does **not** judge whether a barrier is truly *effective* or *independent* \u2014 that is the analyst\'s qualitative judgement.\n\n---\n\n## 7. Bowtie vs fault tree\n\nA fully-developed bowtie *is* a fault tree glued to an event tree at the top event: the left wing read backwards is the fault tree whose top event is the bowtie\'s knot, and the right wing is the event tree that propagates it into consequences. Schematex keeps them as two engines because their use differs:\n\n- **`bowtie`** is qualitative and symmetric \u2014 the barrier inventory and the at-a-glance defence-in-depth story; no probability arithmetic.\n- **`faulttree`** is quantitative and Boolean \u2014 AND/OR gates, basic-event probabilities, minimal cut sets, a probability rollup.\n\nWhere you want the gate-level detail behind a single threat, draw a separate `faulttree`.\n\n---\n\n## 8. Theming\n\n`default` uses the recognised BowTieXP / bowtiemaster palette \u2014 **orange threats** (left), **grey barriers** on the line, a **green top-event disc** (centre knot), **red consequences** (right), **amber escalation factors** dropping below \u2014 mapped onto Schematex\'s semantic slots so it stays coherent with `prisma` / `pert` / `petri`. `monochrome` reproduces the regulator-print black-and-white look, where element distinction rides on shape/border + position (escalation factors get a dashed border, the knot a doubled ring) rather than colour. `dark` follows Catppuccin Mocha. All strokes/fills come from `BowtieTokens`; every element carries `data-*` (`data-role`, `data-side`, `data-line`, `data-order`, `data-barrier`) so the structure is inspectable downstream.'
+  },
+  "eventtree": {
+    "title": "Event Tree Analysis",
+    "content": '## 1. Your first event tree\n\nEvery document starts with the `eventtree` keyword (alias `eta`), an optional title, then a flat list of declarations:\n\n```\neventtree "Smoke detector demand"\n  initiating FIRE "Fire starts" freq: 0.01\n  function D "Detector actuates" p: 0.02\n  function S "Suppression works" p: 0.05\n  outcome s s -> "Controlled"\n  outcome s f -> "Damage, contained"\n  outcome f * -> "Uncontrolled fire"\n```\n\n- **`initiating ID "label" freq: N`** \u2014 exactly one. The challenge frequency, accepting decimals or scientific notation (`freq: 0.01` or `freq: 1e-4`).\n- **`function ID "label" p: N`** \u2014 one per branch column, **declared left\u2192right in query order**. `p:` is the **failure** probability; the engine derives the success leg as its complement `1 \u2212 p` (you never state both).\n- **`outcome <pattern> -> "end state"`** \u2014 one realised leaf each.\n\n---\n\n## 2. The s / f / * outcome pattern\n\nEach `outcome` row reads left\u2192right over the function columns:\n\n```\noutcome s s s -> "OK"           # every function succeeds\noutcome s s f -> "Late release" # C fails on the last query\noutcome s f * -> "Early release"# B fails; C is never queried (pruned)\noutcome f * * -> "Core damage"  # A fails; path terminates immediately\n```\n\n- **`s`** \u2014 success leg (upper branch).\n- **`f`** \u2014 failure leg (lower branch).\n- **`*`** \u2014 pruned: the path is not queried here, it runs flat to its leaf.\n\nThis is how an event tree avoids being a full balanced 2\u207F tree: once a function failure makes later questions moot, you write `*` and the sequence terminates early. Two hard rules: a pattern may not be **longer** than the column count, and **once a column is pruned (`*`) every later column must also be `*`** \u2014 a path that has terminated cannot resume querying.\n\n---\n\n## 3. Computed path frequencies & outcomes\n\nThis is the differentiator. With the failure probabilities and `freq`, the engine computes:\n\n- **Each path frequency** = `f\u2080 \xB7 \u220F branch-probabilities` along its `s`/`f` legs (success legs contribute `1 \u2212 p`, failure legs `p`).\n- **Outcome roll-up**: outcomes with the same end-state label are summed across every path that reaches them (every `"Core damage"` leaf adds up).\n- **The dominant sequence** \u2014 the largest-frequency path \u2014 gets the reserved-red accent, the ETA analogue of the fault tree\'s single point of failure.\n\nEvery leaf carries `data-*` (`data-freq`, `data-outcome`) so the computed numbers are inspectable downstream.\n\n---\n\n## 4. Common mistakes\n\n```\n# WRONG \u2014 function with no failure probability\nfunction A "ECCS"\n\n# WRONG \u2014 querying after a pruned column (path already terminated)\noutcome * s -> "bad"\n\n# WRONG \u2014 more tokens than declared columns\nfunction A p: 0.1\noutcome s s -> "ok"\n\n# WRONG \u2014 initiating event with no frequency\ninitiating LOCA "Large LOCA"\n```\n\nEach is rejected with a plain-English message naming the line. State `p:` as a **failure** probability (small), give the initiating event a `freq:`, keep prunes trailing, and you are correct by construction.\n\n---'
+  },
+  "fmea": {
+    "title": "FMEA Worksheet",
+    "content": '## 1. Your first worksheet\n\nEvery document starts with `fmea`, an optional title, optional directives, then a **nested** failure chain. Structure comes from the keyword, not the indent depth:\n\n```\nfmea "Pump DFMEA"\n  item "Impeller" fn "Move fluid"\n    mode "No flow"\n      effect "Process stops" sev: 8\n      cause "Impeller wear" occ: 4\n        controls detection: "Flow sensor" det: 5\n```\n\n- **`item "name" fn "function"`** \u2014 a part and the function it delivers. `fn` is optional.\n- **`mode "failure mode"`** \u2014 how that function fails. An item may hold several.\n- **`effect "consequence" sev: 1..10`** \u2014 what the failure causes; carries its own **Severity**. A mode may have several (the engine uses the *worst* for every row of that mode).\n- **`cause "root cause" occ: 1..10`** \u2014 why it happens; carries **Occurrence**.\n- **`controls prevention: "\u2026", detection: "\u2026" det: 1..10`** \u2014 current controls and the **Detection** rating they earn. With no control, Detection defaults to **10** (undetectable).\n\nAll three ratings are integers 1\u201310; anything outside that range is rejected.\n\n---\n\n## 2. Header directives\n\n```\ntype: design          # design (dfmea) | process (pfmea) | msr\nrank: ap              # ap (default) | rpn \u2014 the sort/priority key\nflag: ap >= High      # or `rpn > 100` \u2014 highlight rows over a threshold\nnumber: FMEA-2026-014 # free metadata: number/team/author/date/revision/dept/process/product\n```\n\n`rank` chooses how rows are prioritised; `flag` highlights the rows that breach a threshold (`ap >= High` / `ap == High`, or `rpn > 100` / `rpn >= 120`).\n\n---\n\n## 3. Computed RPN & Action Priority\n\nThis is the differentiator. From the nested AST the engine:\n\n1. **Flattens** to one row per (item, mode, cause); the mode\'s worst effect severity governs every row of that mode.\n2. **RPN = S \xD7 O \xD7 D** (1\u20131000).\n3. **Action Priority** by the AIAG-VDA band structure \u2014 **Severity is the primary axis**, Occurrence second, Detection third. S = 9\u201310 (safety/regulatory) is High for *every* O and D; mid-severity degrades High\u2192Medium\u2192Low as Occurrence falls.\n4. **Sorts** by the chosen key. For `ap`: High > Medium > Low, tie-broken by Severity then RPN \u2014 *never* RPN alone, which would re-introduce the bug AP was designed to fix.\n5. **Flags** rows over the threshold.\n\nEach row carries `data-rpn` and `data-ap` so the computed priority is inspectable.\n\n---\n\n## 4. After-action follow-up\n\nRecord corrective actions and the revised ratings to show the before/after delta:\n\n```\nfmea "Brake DFMEA"\n  item "MC"\n    mode "Seal leak"\n      effect "Loss of braking" sev: 9\n      cause "Degradation" occ: 3 det: 4\n  action "Seal leak" / "Degradation"\n    do: "Upgrade seal to EPDM" owner: "J. Lee" target: 2026-Q3\n    revised sev: 9 occ: 1 det: 4\n```\n\n`action "Mode" / "Cause"` targets a chain by its quoted mode and (optional) cause; `do:` is the recommendation; `revised sev/occ/det` recomputes the after-action RPN and AP so the engine reports the risk reduction.\n\n---\n\n## 5. Common mistakes\n\n```\n# WRONG \u2014 rating out of the 1..10 band\neffect "Leak" sev: 11\n\n# WRONG \u2014 mode before any item\nmode "orphan mode"\n\n# WRONG \u2014 effect before any mode\nitem "x"\n  effect "e" sev: 3\n```\n\nRatings must be integers 1\u201310; the failure chain must nest `item \u2192 mode \u2192 effect/cause`; out-of-order keywords are rejected by name. Detection silently defaults to 10 if no control rates it \u2014 state `det:` (on the cause or its `controls`) when you have a detection control.\n\n---'
+  },
+  "causalloop": {
+    "title": "Causal Loop Diagram",
+    "content": '## 1. Your first causal loop\n\nStart with the `causalloop` keyword (alias `cld`), an optional title, then **signed links**. Variables are auto-created from the links \u2014 you rarely declare them:\n\n```\ncausalloop "Adoption model"\n"Adoption rate" -> Adopters : +\nAdopters -> "Adoption rate" : +\nloop R1 "Word of mouth"\n```\n\nA link is `SOURCE -> TARGET : POLARITY`. Multi-word variable names are quoted (`"Adoption rate"`); single words need no quotes (`Adopters`). At least one link is required.\n\n---\n\n## 2. Link polarity\n\nPolarity is the sign of the causal influence and is **mandatory** on every link:\n\n```\nA -> B : +          # same direction (more A \u2192 more B)\nB -> C : -          # opposite direction (more B \u2192 less C)\nA -> B : s          # alias for + (same)\nB -> C : o          # alias for \u2212 (opposite)\nC -> D : same       # alias for +\nD -> E : opposite   # alias for \u2212\nA -> B +            # the colon is optional\n```\n\n`+` / `s` / `same` mean *same direction*; `\u2212` / `o` / `opposite` mean *opposite*. A link with no polarity is rejected.\n\n---\n\n## 3. Delays and explicit variables\n\n```\n"Training quality" -> "Salesperson skills" : + delay   # marked delay (\u2225 hash on the arrow)\nA -> B : + ~delay                                       # the ~delay form also works\nvar "Adoption rate"                                     # pin a variable so it isn\'t auto-created\nloop R1 "Word of mouth"                                 # name/annotate a loop\n```\n\n- **`delay`** / **`~delay`** marks a link as delayed (the system-dynamics hash mark).\n- **`var "name"`** declares a variable explicitly (fixes its label; not auto-created).\n- **`loop ID "phrase"`** attaches a human-readable name to a loop the engine detects.\n\n---\n\n## 4. Computed feedback loops\n\nThis is the differentiator. The engine:\n\n1. Builds the **signed directed graph** (nodes = variables, edges = signed links).\n2. Enumerates **every elementary feedback loop** (simple directed cycle) with Johnson\'s algorithm \u2014 deterministically, in declaration order.\n3. **Classifies** each loop by counting negative links:\n   - **even** count (including 0) \u2192 **R** (reinforcing); product of signs = +1\n   - **odd** count \u2192 **B** (balancing); product of signs = \u22121\n\nThis is exactly Sterman\'s even/odd rule. Loops are numbered in detection order by kind (R1, B1, R2\u2026) and drawn with their `R`/`B` rotation glyph at the loop centre. Each loop carries `data-loop` and `data-kind`.\n\n---\n\n## 5. Common mistakes\n\n```\n# WRONG \u2014 link with no polarity\nA -> B\n\n# WRONG \u2014 a diagram with no links at all\ncld\n```\n\nEvery link needs a polarity (`: +` or `: -`); a CLD with no links is rejected. Remember polarity is about *direction of change*, not desirability \u2014 a link from "deaths" to "population" is still `-` (more deaths \u2192 less population) even though deaths are bad.\n\n---'
+  },
+  "markov": {
+    "title": "Markov Chain",
+    "content": '## 1. Your first chain\n\nStart with the `markov` keyword (alias `markovchain`), an optional title, then **probability-weighted transitions**. States are auto-created from the first arc that mentions them:\n\n```\nmarkov "Weather"\n  Sunny -> Sunny : 0.9\n  Sunny -> Rainy : 0.1\n  Rainy -> Sunny : 0.5\n  Rainy -> Rainy : 0.5\n```\n\nA transition is `FROM -> TO : PROBABILITY`. A self-loop (`Sunny -> Sunny`) is the probability of staying put. Every probability must be in `[0, 1]`, and **the probabilities leaving each state must sum to 1**.\n\n---\n\n## 2. Declaring states\n\nYou can declare states explicitly to fix label, order, or mark them absorbing:\n\n```\nmarkov "Gambler\'s ruin"\n  state Broke "$0" absorbing\n  state Rich  "$4" absorbing\n  state S1\n  state S2\n  Broke -> Broke : 1\n  Rich  -> Rich  : 1\n  S1 -> Broke : 0.5\n  S1 -> S2 : 0.5\n  S2 -> S1 : 0.5\n  S2 -> Rich : 0.5\n```\n\n`state ID "label" absorbing` \u2014 the label is optional; `absorbing` asserts the state is a sink (a self-loop of probability 1). The engine cross-checks the assertion against the matrix.\n\n---\n\n## 3. Directives\n\n```\nlayout: layered       # layout mode\nnormalize: true        # scale each row to sum to 1 instead of hard-erroring\nanalysis: classify, absorbing   # what to compute: classify | absorbing | stationary\n```\n\n- **`normalize: true`** rescales each row to sum to 1 (handy for unnormalised weights like `A -> B : 1`, `A -> C : 1`). Without it, a row that does not sum to 1 is a hard error.\n- **`analysis:`** selects which computations to run and surface.\n\n---\n\n## 4. The computed answer\n\nThis is the differentiator. Three hand-written, dependency-free linear-algebra passes:\n\n1. **Matrix assembly + validation** \u2014 build P and enforce the row-sum policy (hard error, or rescale under `normalize`).\n2. **State classification** \u2014 Tarjan SCC \u2192 communicating classes; a class is **recurrent** iff closed, **transient** otherwise; a closed singleton with a probability-1 self-loop is **absorbing**.\n3. **The quantitative answer**:\n   - **Stationary distribution** \u03C0 (\u03C0P = \u03C0, \u03A3\u03C0 = 1) by power iteration with an exact Gaussian-elimination fallback for periodic chains.\n   - For **absorbing chains**: the fundamental matrix N = (I\u2212Q)\u207B\xB9, absorption probabilities B = N\xB7R, and expected steps to absorption t = N\xB71.\n\nTransient states, recurrent classes, and absorbing states are rendered distinctly; computed values are carried in `data-*`.\n\n---\n\n## 5. Common mistakes\n\n```\n# WRONG \u2014 probability outside [0,1]\nA -> B : 1.5\n\n# WRONG \u2014 transition with no probability\nA -> B\n\n# WRONG \u2014 rows that don\'t sum to 1 (without `normalize: true`)\nA -> B : 0.3\nA -> C : 0.3\n```\n\nEvery transition needs a probability in `[0, 1]`; each state\'s outgoing probabilities must sum to 1, or you must set `normalize: true`. An empty chain (no transitions) is rejected.\n\n---'
+  },
+  "gitgraph": {
+    "title": "Git Graph",
+    "content": '## 1. Your first git graph\n\nStart with the `gitGraph` keyword (case-insensitive; a trailing colon is allowed), then one operation per line. The first commit lands on the main branch:\n\n```\ngitGraph\n  commit\n  branch develop\n  checkout develop\n  commit id: "feature work"\n  checkout main\n  merge develop tag: "v1.0"\n```\n\nEvery operation runs against the **currently checked-out branch**. `commit` appends to it; `branch` creates a new line from the current commit; `checkout` (alias `switch`) moves the cursor; `merge` brings another branch into the current one.\n\n---\n\n## 2. Operations\n\n```\ncommit                         # plain commit on the current branch\ncommit id: "init"              # give the commit an explicit id\ncommit tag: "v0.1"             # attach a release tag\ncommit type: HIGHLIGHT         # NORMAL (default) | HIGHLIGHT | REVERSE\nbranch develop                 # fork a branch from the current commit\nbranch hotfix order: 3         # pin its lane order\ncheckout develop               # switch the cursor (alias: switch)\nmerge develop tag: "v1.0"      # merge a branch into the current one\ncherry-pick id: "abc"          # copy a commit onto the current branch\n```\n\n- **`commit`** takes optional `id:`, `tag:`, and `type:` (`NORMAL` / `HIGHLIGHT` / `REVERSE`).\n- **`branch NAME`** takes an optional `order:` to control lane placement.\n- **`checkout` / `switch`** are interchangeable.\n- **`cherry-pick id:`** copies a commit; an optional `parent:` disambiguates a merge commit.\n\n---\n\n## 3. Orientation\n\nThe graph defaults to left-to-right. Set the direction inline on the header:\n\n```\ngitGraph TB:\n  commit\n  branch feature\n  checkout feature\n  commit\n  checkout main\n  merge feature\n```\n\n`LR` (default), `TB`, and `BT` are accepted. Config can also be supplied via a leading `%%{init: {\'gitGraph\': {...}}}%%` directive or a YAML frontmatter `config:` block for Mermaid compatibility (`mainBranchName`, `showCommitLabel`, `rotateCommitLabel`).\n\n---\n\n## 4. How the engine lays it out\n\nMermaid-compatibility is the differentiator, but the layout is the work:\n\n- The operation list is **replayed in order** to build the commit DAG and assign each commit to its branch lane.\n- Branch lanes are ordered by appearance (overridable with `order:`); merge connectors are routed from the merged branch\'s tip to the new merge commit.\n- Commit nodes are styled by `type:` \u2014 a HIGHLIGHT commit is emphasised, a REVERSE commit marked \u2014 and tags render as flags. Cherry-picks draw a dashed copy edge to the source.\n\nEvery commit carries `data-*` (branch, id, type) for downstream interaction.\n\n---\n\n## 5. Common mistakes\n\n```\n# WRONG \u2014 no gitGraph header\ncommit\ncommit\n\n# WRONG \u2014 unknown operation\ngitGraph\n  rebase main\n\n# WRONG \u2014 unknown commit type\ngitGraph\n  commit type: SQUASH\n```\n\nThe document must start with `gitGraph`; only `commit` / `branch` / `checkout` / `switch` / `merge` / `cherry-pick` are valid operations; `type:` must be `NORMAL`, `HIGHLIGHT`, or `REVERSE`. `%%` starts a comment, matching Mermaid.\n\n---'
+  },
+  "epc": {
+    "title": "EPC (Event-driven Process Chain)",
+    "content": '## 1. Your first EPC\n\nStart with the `epc` keyword, an optional title, then declare **nodes by id** and **wire them with arrows**:\n\n```\nepc "Order fulfilment"\n  event E1 "Order received"\n  function F1 "Check credit"\n  event E2 "Credit OK"\n  E1 -> F1 -> E2\n```\n\nNodes carry an id and an optional quoted label; arrows reference ids. The canonical form declares connectors as nodes (`xor X1`) and wires everything by id \u2014 closest to how ARIS stores an EPC.\n\n---\n\n## 2. Node kinds\n\n```\nevent E1 "Order received"     # passive state (rounded hexagon)\nfunction F1 "Check credit"    # active task (rounded rectangle); alias: func\nfunc F2 "Send invoice"        # `func` is shorthand for `function`\nand  A1                       # AND connector (\u2227)\nor   O1                       # OR connector (\u2228)\nxor  X1                       # exclusive-OR connector (\xD7)\n```\n\nA connector fans either way (split or join) depending on its incoming/outgoing arcs, so the same glyph serves both. Connector labels are optional.\n\n---\n\n## 3. Wiring control flow\n\n```\nE1 -> F1 -> X1        # a chain is sugar for the pairwise arcs E1\u2192F1, F1\u2192X1\nX1 -> E2              # connector split into two branches\nX1 -> E3\nF2 -> E2 : sent       # a single arc may carry a \': label\'\n```\n\n- A `->` **chain** expands to pairwise edges.\n- A trailing **`: label`** annotates a single arc.\n- An arrow endpoint not yet declared is **auto-created** (and flagged by the validator), so you can sketch fast and clean up later.\n\n```\nepc "Procure-to-pay"\n  layout: tb\n  event E1 "Need identified"\n  function F1 "Create PO"\n  and A1\n  function F2 "Notify supplier"\n  function F3 "Update budget"\n  E1 -> F1 -> A1\n  A1 -> F2\n  A1 -> F3\n```\n\n`layout: tb` lays the chain top-to-bottom (default is also vertical-friendly).\n\n---\n\n## 4. Computed well-formedness\n\nThis is the differentiator. The engine validates (flags, doesn\'t throw):\n\n1. **Bipartite alternation** \u2014 events and functions strictly alternate along any path; connectors don\'t break it.\n2. **Start/end must be events** \u2014 a function may not be a start or end node.\n3. **Signature rule** \u2014 an *event must not be the source of an OR/XOR split* (a passive event cannot decide); an AND-split after an event is allowed.\n4. **Split/join balancing** \u2014 a split of type T should be closed by a join of type T; mismatches are warnings (real EPCs are sometimes unbalanced).\n5. **Single-in / single-out** per event and function \u2014 connectors carry the multiplicity.\n6. **Reachability** \u2014 every node reachable from a start and reaching an end.\n\nOffending nodes are highlighted with `data-*` flags; the diagram still renders.\n\n---\n\n## 5. Common mistakes\n\n```\n# WRONG \u2014 invalid id (must start with a letter)\nevent 9bad\n\n# AVOID \u2014 redeclaring a node (the first wins, a warning is raised)\nevent E1 "first"\nevent E1 "second"\n```\n\nIds must start with a letter; a redeclared node keeps the first definition and warns. Because event\u2192XOR/OR splits are flagged, route a decision through a **function** that produces the decision, then split.\n\n---'
+  },
+  "idef0": {
+    "title": "IDEF0 Function Model",
+    "content": '## 1. Your first IDEF0 diagram\n\nStart with the `idef0` keyword, an optional title, an optional `node` (the diagram\'s node number), then **function boxes** and their **ICOM arrows**:\n\n```\nidef0 "Fill order"\nfunction A1 "Receive order"\ninput     A1 "Customer request"\ncontrol   A1 "Order policy"\nmechanism A1 "Order clerk"\noutput    A1 "Confirmed order"\n```\n\n`function ID "name"` declares a box (in declaration order). `node A0` sets the parent node number used to derive child node numbers (A0 \u2192 A1..An). FIPS guidance is 3\u20136 boxes per diagram; outside that range the engine warns.\n\n---\n\n## 2. ICOM boundary arrows\n\nEach keyword pins an arrow to a specific side of a box, and that *is* its role:\n\n```\ninput     A1 "Sales orders"        # enters the LEFT edge\ncontrol   A1 "Production schedule" # enters the TOP edge (governs the activity)\noutput    A1 "Product"             # leaves the RIGHT edge\nmechanism A1 "CNC machines"        # enters the BOTTOM edge (the resource)\n```\n\n`input`, `control`, and `mechanism` route from the diagram frame **into** the box; `output` routes from the box **out** to the frame. The engine codes these boundary arrows down each edge (I1, I2 / C1 / O1 / M1).\n\n---\n\n## 3. Flow arrows between boxes\n\nA `->` arrow connects two boxes; by default it lands on the target\'s **input**, but you can name the target\'s ICOM side:\n\n```\nA1 -> A2 "Work plan"            # box\u2192box; defaults to A2\'s input\nA2 -> A3.control "Parts spec"   # land on A3\'s control (top) edge\ninput A2 "Raw material" (tunnel) # (tunnel) hides the arrow at this level\n```\n\n- `target.control` / `target.input` / `target.mechanism` picks the landing side.\n- A flow **cannot land on the target\'s `.output`** \u2014 an output leaves a box, it does not enter one.\n- `(tunnel)` marks a tunnelled arrow (suppressed on the parent/child diagram per FIPS).\n\n---\n\n## 4. Computed structural enforcement\n\nThis is the differentiator \u2014 what makes the model correct where a drawing tool is not:\n\n1. **ICOM placement enforcement** \u2014 the role is resolved against the box\'s geometry side; a malformed role, or a flow asked to *enter* a box via `.output`, is rejected.\n2. **Reference resolution** \u2014 every box id named by an arrow must be declared.\n3. **Decomposition numbering** \u2014 boxes get contiguous box numbers 1..n (lower-right corner) and node numbers (A0 \u2192 A1..An); explicit `#N` numbers are checked for contiguity, range, and duplicates.\n4. **Boundary coding** \u2014 boundary arrows are coded I1/C1/O1/M1 down each edge.\n5. **Box-count guideline** \u2014 fewer than 3 or more than 6 boxes raises a FIPS-183 warning.\n\n---\n\n## 5. Common mistakes\n\n```\n# WRONG \u2014 no idef0 header\nfunction A1 "x"\n\n# WRONG \u2014 a flow landing on the target\'s output\nA1 -> A2.output "bad"\n\n# WRONG \u2014 an unknown ICOM side word\nA1 -> A2.sideways "bad"\n```\n\nThe document must start with `idef0`; arrows may target `.input` / `.control` / `.mechanism` only; every referenced box id must be declared. Because the keyword encodes the side, you cannot accidentally draw a control as an input \u2014 the standard is enforced, not suggested.\n\n---'
+  },
+  "threatmodel": {
+    "title": "Threat Model (STRIDE DFD)",
+    "content": '## 1. Your first threat model\n\nStart with the `threatmodel` keyword (alias `stride`), an optional title, then **declare elements** and **wire flows**:\n\n```\nthreatmodel "Login flow"\nexternal: User\nprocess 1.1: Web Server\ndatastore D1: User DB\nUser -> 1.1 : "Login request"\n1.1 -> D1 : Lookup\n```\n\nEach element is `kind: ID: Label` (or `kind: Label`, where the id is slugged from the label \u2014 `external: Mobile App` becomes id `Mobile_App`). A flow is `SOURCE -> TARGET : label`, and the **label is mandatory** (it names the data crossing).\n\n---\n\n## 2. Element kinds and flows\n\n```\nexternal: User              # external entity (the attacker\'s side)\nprocess 1.1: Web Server     # a process / service\ndatastore D1: User DB       # a data store\ndatastore D2: Audit log     # a log/audit store (gets conditional Repudiation)\nUser -> 1.1 : "HTTPS Request"   # directed flow, quoted or bare label\n1.1 <-> D1 : Read/Write         # <-> expands into two directed flows\n```\n\n- Process ids are often dotted DFD numbers (`1.1`, `2.3`); external/store ids are usually short slugs (`User`, `D1`).\n- A `<->` flow expands into **two** directed flows.\n- A store whose name/id matches `log|audit|journal` (or carries an explicit hint) is treated as a log store.\n\n**Flow rules** the engine enforces: no store\u2192store flows (data stores are passive), no external\u2192external flows, and every endpoint must be a declared element.\n\n---\n\n## 3. Trust boundaries\n\n```\nboundary "Internet"  { User }\nboundary "DMZ"       { 1.1 }\nboundary "Internal"  { D1, D2 }\n```\n\n`boundary "name" { id, id, \u2026 }` groups elements into a trust zone. An element may belong to **at most one** boundary; members must be declared. Elements in no boundary share an implicit untrusted zone.\n\n---\n\n## 4. Computed STRIDE analysis\n\nThis is the differentiator. The engine applies the **STRIDE-per-element** mapping:\n\n| DFD element     | Threats applied        |\n|-----------------|------------------------|\n| External entity | S, R                   |\n| Process         | S, T, R, I, D, E       |\n| Data store      | T, I, D (+ R if log)   |\n| Data flow       | T, I, D                |\n\n- The data-store **Repudiation** is conditional \u2014 added for log / audit / journal stores (the Shostack green "?").\n- **Boundary crossing**: a flow whose endpoints sit in different trust zones is flagged, because that is where Spoofing / Tampering / Information-disclosure concentrate. Two elements in the same (or implicit) zone do not cross.\n\nEach element and flow carries its applicable STRIDE categories in `data-*` so the analysis is inspectable.\n\n---\n\n## 5. Common mistakes\n\n```\n# WRONG \u2014 flow with no label\nUser -> 1.1\n\n# WRONG \u2014 store to store (data stores are passive)\nD1 -> D2 : x\n\n# WRONG \u2014 external to external\nA -> B : x\n\n# WRONG \u2014 unknown flow endpoint\nP -> Ghost : x\n\n# WRONG \u2014 an element in two boundaries\nboundary "A" { P }\nboundary "B" { P }\n```\n\nEvery flow needs a label; stores and externals cannot be flow partners with their own kind; endpoints must be declared; an element belongs to at most one trust boundary. Duplicate ids are rejected.\n\n---'
   }
 };
 
@@ -3703,6 +4061,224 @@ var PROFILES = {
       "'needs at least one threat/consequence' \u2014 a one-wing diagram is a fault tree or event tree; add the missing wing.",
       "'exactly one top event' \u2014 keep a single `topevent` line."
     ]
+  },
+  eventtree: {
+    type: "eventtree",
+    header: 'eventtree "Title"',
+    mode: "initiating event + ordered safety functions, then outcome rows with s/f/* branch patterns",
+    forms: [
+      'initiating LOCA "Large LOCA" freq: 1e-4',
+      'function A "ECCS injects" p: 0.001',
+      'function B "Containment spray" p: 0.01',
+      'outcome s s -> "OK"',
+      'outcome s f -> "Late release"',
+      'outcome f * -> "Core damage"'
+    ],
+    prefer: [
+      "Keyword `eventtree` (or `eta`). One `initiating` line with a `freq:`; then `function` lines in left-to-right order, each with its failure probability `p:` (success is auto-complemented to 1\u2212p).",
+      'Each `outcome` row gives a `s`/`f`/`*` pattern (one symbol per function) then `-> "label"`. `*` = path already terminated (pruned) \u2014 runs flat to its leaf, no further branching.',
+      "Let the engine compute path frequencies (f_initiating \xD7 \u03A0 branch-probs) \u2014 don't hand-write them."
+    ],
+    avoid: [
+      "Don't try to make a balanced 2\u207F tree \u2014 prune with `*` where a sequence ends early.",
+      "Don't put probabilities on outcome rows; `p:` belongs on `function` lines.",
+      "Don't reverse the success/failure convention \u2014 success branches up, failure down."
+    ],
+    repair: [
+      "'outcome pattern length' \u2014 give exactly one s/f/* per declared function.",
+      "'no initiating event' \u2014 add one `initiating <id> \"\u2026\" freq: \u2026` line.",
+      "'once pruned stays pruned' \u2014 after a `*` in a pattern, the rest must also be `*`."
+    ]
+  },
+  fmea: {
+    type: "fmea",
+    header: 'fmea "Title"',
+    mode: "indentation-structured worksheet: item \u2192 failure mode \u2192 effect/cause/controls with S/O/D scores",
+    forms: [
+      'fmea "Brake System DFMEA"',
+      '  item "Master cylinder" fn "Generate pressure"',
+      '    mode "Internal seal leak"',
+      '      effect "Loss of braking" sev: 9',
+      '      cause "Seal degradation" occ: 3',
+      '        controls detection: "Bench test" det: 4'
+    ],
+    prefer: [
+      "Keyword `fmea`. Nest `item` \u2192 `mode` \u2192 `effect`/`cause` \u2192 `controls`. Put Severity on the effect (`sev:`), Occurrence on the cause (`occ:`), Detection on the controls (`det:`) \u2014 each 1\u201310.",
+      "Let the engine compute RPN = S\xD7O\xD7D and the Action Priority (High/Medium/Low) and rank the sheet \u2014 don't hand-write RPN.",
+      "Optional `rank: ap|rpn` and `flag: ap >= High` / `flag: rpn > 100` to control sorting/highlighting."
+    ],
+    avoid: [
+      "Don't write the RPN or AP yourself \u2014 they are computed.",
+      "Don't use scores outside 1\u201310.",
+      "Don't put `occ:` on an effect or `sev:` on a cause \u2014 they bind to the wrong column."
+    ],
+    repair: [
+      "'score out of range' \u2014 keep S/O/D in 1\u201310.",
+      "'mode has no effect/cause' \u2014 every failure mode needs at least one effect and one cause."
+    ]
+  },
+  causalloop: {
+    type: "causalloop",
+    header: 'causalloop "Title"',
+    mode: "signed causal links between variables; engine detects R/B loops",
+    forms: [
+      'causalloop "Adoption model"',
+      '"Adoption rate" -> Adopters : +',
+      'Adopters -> "Adoption rate" : +',
+      '"Adoption rate" -> "Potential adopters" : -',
+      'loop R1 "Word of mouth"',
+      'loop B1 "Market saturation"'
+    ],
+    prefer: [
+      "Keyword `causalloop` (or `cld`). Write `A -> B : +` or `A -> B : -` (you may use `s`/`o` aliases). Multi-word variables go in quotes.",
+      'Let the engine classify loops R (reinforcing) / B (balancing) by counting negative links; optionally name them with `loop R1 "\u2026"`.',
+      "Put the `+`/`\u2212` polarity at the end of each link."
+    ],
+    avoid: [
+      "Don't draw boxes around variables \u2014 CLD variables are boxless text.",
+      "Don't omit polarity \u2014 every causal link is signed."
+    ],
+    repair: [
+      "'link needs a polarity' \u2014 append `: +` or `: -`.",
+      "'unknown variable' \u2014 variables are created on first use; check quoting/spelling."
+    ]
+  },
+  markov: {
+    type: "markov",
+    header: 'markov "Title"',
+    mode: "probability-labelled state transitions; engine computes stationary distribution + classification",
+    forms: [
+      'markov "Weather"',
+      "Sunny -> Sunny : 0.9",
+      "Sunny -> Rainy : 0.1",
+      "Rainy -> Sunny : 0.5",
+      "Rainy -> Rainy : 0.5"
+    ],
+    prefer: [
+      "Keyword `markov` (or `markovchain`). Write `S1 -> S2 : 0.3` transitions; each state's outgoing probabilities must sum to 1.",
+      "Mark absorbing states by a 1.0 self-loop (or the `absorbing` keyword); the engine computes the stationary distribution and classifies states.",
+      "For an absorbing chain add `analysis: classify, absorbing` to get absorption probabilities + expected steps."
+    ],
+    avoid: [
+      "Don't let a state's out-probabilities sum to \u2260 1 (the engine errors); use `normalize: true` only if you intend rescaling.",
+      "Don't hand-compute the stationary distribution \u2014 it is derived."
+    ],
+    repair: [
+      "'row does not sum to 1' \u2014 fix the probabilities or add `normalize: true`.",
+      "'probability out of range' \u2014 keep each on (0,1]."
+    ]
+  },
+  gitgraph: {
+    type: "gitgraph",
+    header: "gitGraph",
+    mode: "Mermaid-compatible ordered git operations (commit/branch/checkout/merge)",
+    forms: [
+      "gitGraph",
+      '  commit id: "init"',
+      "  branch develop",
+      "  checkout develop",
+      '  commit tag: "v0.1"',
+      "  checkout main",
+      "  merge develop"
+    ],
+    prefer: [
+      'Header `gitGraph` (Mermaid syntax). Operations in order: `commit`, `branch <name>`, `checkout <name>`, `merge <name>`, `cherry-pick id: "\u2026"`.',
+      'Annotate commits with `id: "\u2026"`, `tag: "\u2026"`, `type: HIGHLIGHT|REVERSE|NORMAL`.',
+      "`checkout` (or `switch`) before committing onto a branch; `merge <name>` merges that branch into the current one."
+    ],
+    avoid: [
+      "Don't `merge` or `checkout` a branch you never created with `branch`.",
+      "Don't merge a branch into itself."
+    ],
+    repair: [
+      "'unknown branch' \u2014 add a `branch <name>` before `checkout`/`merge`.",
+      "'cannot merge current branch' \u2014 checkout the target lane first."
+    ]
+  },
+  epc: {
+    type: "epc",
+    header: 'epc "Title"',
+    mode: "alternating events/functions joined by AND/OR/XOR connectors; alternation validated",
+    forms: [
+      'epc "Order fulfilment"',
+      '  event E1 "Order received"',
+      '  function F1 "Check credit"',
+      "  xor X1",
+      '  event E2 "Credit OK"',
+      '  event E3 "Credit rejected"',
+      "  E1 -> F1 -> X1",
+      "  X1 -> E2",
+      "  X1 -> E3"
+    ],
+    prefer: [
+      "Keyword `epc`. Declare `event`, `function`, and connectors `and`/`or`/`xor` with ids; then the control flow `A -> B -> C`.",
+      "Strictly alternate events and functions (a connector may sit between them); start and end with events.",
+      "Use a connector node to split/join \u2014 e.g. a `xor` after a function fans out to alternative events."
+    ],
+    avoid: [
+      "Don't make an event the source of an OR/XOR split (only functions may decide) \u2014 the engine rejects it.",
+      "Don't connect event\u2192event or function\u2192function directly."
+    ],
+    repair: [
+      "'event cannot be an OR/XOR split source' \u2014 put a function (decision) before the connector.",
+      "'alternation violated' \u2014 insert the missing event/function between two same-kind nodes."
+    ]
+  },
+  idef0: {
+    type: "idef0",
+    header: 'idef0 "Title"',
+    mode: "function boxes + positional ICOM arrows (input-left, control-top, output-right, mechanism-bottom)",
+    forms: [
+      'idef0 "Manufacture product"',
+      '  function A1 "Plan production"',
+      '  function A2 "Make parts"',
+      '  input A1 "Sales orders"',
+      '  control A1 "Production schedule"',
+      '  A1 -> A2 "Work plan"',
+      '  mechanism A2 "CNC machines"',
+      '  output A2 "Product"'
+    ],
+    prefer: [
+      "Keyword `idef0`. Declare `function` boxes; attach boundary arrows with `input`/`control`/`output`/`mechanism`.",
+      'Box\u2192box flow `A1 -> A2 "label"` lands on A2\'s input by default; use `A1 -> A2.control "\u2026"` to land on another ICOM side.',
+      "Remember the ICOM rule: Inputs enter left, Controls enter top, Outputs exit right, Mechanisms enter bottom \u2014 the engine enforces it."
+    ],
+    avoid: [
+      "Don't route an output anywhere but the right edge, or a control anywhere but the top \u2014 the engine rejects it.",
+      "Don't hand-number the boxes \u2014 node numbers are assigned."
+    ],
+    repair: [
+      "'output must exit the right edge' \u2014 declare it with `output` / land flows on the correct side.",
+      "'unknown box' \u2014 declare the `function` before referencing it."
+    ]
+  },
+  threatmodel: {
+    type: "threatmodel",
+    header: 'threatmodel "Title"',
+    mode: "DFD elements + data flows + trust boundaries; engine maps STRIDE + flags boundary crossings",
+    forms: [
+      'threatmodel "Web App \u2014 STRIDE"',
+      "external: User",
+      "process 1.1: Web Server",
+      "datastore D1: User DB",
+      "User -> 1.1 : HTTPS Request",
+      "1.1 -> D1 : Lookup",
+      'boundary "Internet" { User }',
+      'boundary "DMZ" { 1.1 }'
+    ],
+    prefer: [
+      'Keyword `threatmodel` (or `stride`). Declare `external:`, `process N:`, `datastore D:`; connect with `A -> B : "label"` flows; group ids into `boundary "name" { \u2026 }` trust zones.',
+      "Let the engine annotate each element's STRIDE letters and flag flows that cross a trust boundary \u2014 don't list threats by hand.",
+      "Name audit/log stores with `log`/`audit`/`journal` so they pick up the conditional Repudiation threat."
+    ],
+    avoid: [
+      "Don't connect store\u2192store or external\u2192external (not valid DFD edges).",
+      "Don't leave data flows unlabelled."
+    ],
+    repair: [
+      "'unknown element' \u2014 declare the external/process/datastore before referencing it.",
+      "'flow needs a label' \u2014 add `: \"\u2026\"` to the flow."
+    ]
   }
 };
 function getGenerationProfile(type) {
@@ -3786,7 +4362,7 @@ function getExamples(type, opts = {}) {
 function validateDsl(type, dsl) {
   const resolvedType = type ? resolveDiagramType(type) : void 0;
   const config = type ? { type: resolvedType ?? type } : void 0;
-  const result = chunkHFATQXFN_cjs.parseResult(dsl, config);
+  const result = chunk3CSST5GZ_cjs.parseResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -3812,7 +4388,7 @@ function renderDsl(type, dsl, options = {}) {
     ...options,
     ...type ? { type: resolvedType ?? type } : {}
   };
-  const result = chunkHFATQXFN_cjs.renderResult(dsl, config);
+  const result = chunk3CSST5GZ_cjs.renderResult(dsl, config);
   if (result.ok) {
     return {
       ok: true,
@@ -3865,5 +4441,5 @@ exports.listDiagrams = listDiagrams;
 exports.renderDsl = renderDsl;
 exports.resolveDiagramType = resolveDiagramType;
 exports.validateDsl = validateDsl;
-//# sourceMappingURL=chunk-CTMJ3XP2.cjs.map
-//# sourceMappingURL=chunk-CTMJ3XP2.cjs.map
+//# sourceMappingURL=chunk-RKN6QJ7K.cjs.map
+//# sourceMappingURL=chunk-RKN6QJ7K.cjs.map