Flow-systems analysis in Studio

Most diagramming tools draw a process. flowss analyses it as well. In the Studio, analysis happens at three levels. First, a family of flow-systems engines works out the numbers its own figure is about: a value stream map works out its own lead time, a control chart works out its own control limits, a fault tree works out its own top-event probability and a queueing network solves its own traffic equations. The arithmetic is drawn into the figure, so the picture and its numbers cannot drift apart. Second, Diagram Intelligence reads the structure of whatever is on the canvas. For an ordinary flowchart drawn in Mermaid, Graphviz or D2, it runs the process and reports lead time, throughput, the bottleneck and where the work waits. Third, process discovery in Data → Chart rebuilds a process from an event log. This page explains all three, engine by engine, with the syntax you write and everything each engine computes and flags.

At a glance

All of these are available on every plan, including Free. Only the optional AI actions in Diagram Intelligence need AI on your plan.

How the flow-systems engines behave

The engines in the Flow systems, Risk & reliability and Quality & control groups of the Studio's engine library share one contract. Knowing it saves you time with each of them.

• The numbers are derived, not typed. You write the facts: cycle times, probabilities, counts, dependencies. The engine computes the totals, limits, probabilities and verdicts and draws them into the figure. There is no field where a summary number can be typed by hand, so a stale total is impossible.
• The findings are part of the figure. Each engine draws its results in a strip of metrics or findings under the diagram, and marks problem elements in the drawing itself, for example a red step, a badged bottleneck or a highlighted cut set. Exports carry them, so a reviewer sees what you saw.
• Half-typed documents keep drawing. The engines are forgiving and line-based. A line that cannot be read is skipped rather than breaking the figure, and an empty document shows a one-line hint about the syntax. They never stop rendering while you type.
• What could not be read is reported. An engine that skipped a line, guessed a value or hit a size limit says so in the figure's notes, rather than presenting an analysis of part of your document as if it were complete. When a document is cut short at a size limit, verdicts such as "balanced" or "in control" are withheld.
• Comments and labels are flexible. In every engine, # and // start a comment anywhere outside quotes, and blank lines are ignored. Quote a label when it contains spaces, punctuation or a word the engine uses as a keyword.
• Units are written the way you would say them. Durations accept forms such as 45s, 12m, 2.5h and 3d. Percentages accept 92%, 0.92 or 92. Each engine's section below notes its own conventions.
• Checks feed the readiness reading. Each engine's own checks also feed the Studio's readiness chip (see The readiness chip below), so an analysis with errors cannot read as finished.

Every flow-systems engine described below renders inside flowss itself, with no external service. That means they work offline, and the render API can draw them on a server. Each has a full reference page at /docs/engines/ followed by its id, linked in each section below, with templates you can open in one click.

Lean and flow

Value stream map

A lean value stream map whose totals are derived from its steps. Reference: Value stream map.

title "ED patient flow — current state"
supplier "Walk-ins + ambulance"
customer "Discharged patients" demand: 320/day
available 24h/day
control "Bed-board / EPR"

process Triage { ct: 6m; co: 0; uptime: 98%; operators: 2; shifts: 3 }
wait 22m
process "Doctor assessment" { ct: 18m; uptime: 92%; operators: 4; fpy: 88% }
inventory 12 patients
process Imaging { ct: 35m; uptime: 80%; operators: 3 }

info "Bed requests" from Triage to control electronic
info "Ward assignment" from control to customer manual

What you write.

• process NAME { … } declares a value-adding step. Its keys are ct (cycle time), co (changeover), uptime, operators, shifts, fpy (first-pass yield), batch and scrap. Common aliases such as cycle time, setup and yield work too. Unknown keys are shown in the step's data box rather than dropped.
• wait, delay and queue add non-value-added time.
• inventory 12 patients adds a queue as a count. When takt is known it is converted to time.
• supplier, customer and control are the boxes across the top. demand: 320/day on the customer line and available 24h/day together give takt, unless takt 4.5m states it outright.
• info "label" from X to Y draws an information arrow, dashed for electronic and solid for manual.

What it computes appears in a metrics strip along the bottom:

The figure draws the supplier and customer band, the process boxes with their data boxes, inventory triangles, and the sawtooth timeline ladder with waits on the upper steps and value-added time on the lower ones.

Flow metrics (CFD)

A cumulative flow diagram with the four numbers Kanban teams manage by. Reference: Flow metrics (CFD).

title "Platform team — Q3"
unit stories
stages: Backlog*, Ready*, In progress, Review*, Done
commit Ready
wip-limit "In progress" 8
2024-07-01 | 148, 26,  8,  4,  0
2024-07-08 | 156, 34, 18, 13,  9
2024-07-15 | 165, 44, 29, 23, 19

What you write.

• stages: lists the workflow from left to right. The last stage is "done".
• Each data row is a date followed by one cumulative count per stage: how many items had entered that stage by that date. Dates may use - or /, the pipe is optional, and rows need not be evenly spaced.
• A trailing *, or (queue), marks a stage as waiting rather than active. Without these marks, flow efficiency is reported as "n/a" rather than guessed.
• commit Ready sets the commitment point, so work before it counts as backlog, not work in progress.
• wip-limit "Stage" 8 draws a WIP limit on that band and flags it when exceeded. unit names what you count.

What it computes:

Cumulative counts cannot fall, and a later stage cannot hold more than an earlier one. When an export breaks those rules, the engine corrects the values and reports how many it raised or capped in a note under the chart.

Queueing network

A queueing network that is solved, not just drawn. Reference: Queueing network.

title "Emergency department — Monday evening"
target 85%
arrivals Triage 12/h

station Triage     { servers: 2; service: 8m }
station Assessment { servers: 3; service: 15m }
station Imaging    { servers: 1; service: 30m; capacity: 6 }
station Discharge  { servers: 3; service: 10m; cv: 1.4 }

route Triage -> Assessment 1.0
route Assessment -> Imaging 0.35
route Assessment -> Discharge 0.65
route Imaging -> Discharge 1.0
route Discharge -> exit 1.0

What you write.

• station NAME { servers: …; service: … } declares a service centre. service is the mean service time, and service rate: 7.5/h can be given instead. capacity limits how many can be in the station, which models blocking and lost arrivals. cv sets the variability of service time, and cva the variability of arrivals. Both default to 1.
• arrivals [station] RATE adds an outside stream. Rates are written 12/h, 0.2/s, 450/day, 42/min, 18/shift (8 hours) or 12 per hour. A bare number means per hour.
• route A -> B 0.35 gives a routing probability, which can also be written 35%. Any probability a station does not route away leaves the network. exit, out, sink, end, done and depart all mean "leaves".
• target 85% is the utilisation the verdict aims for. Durations are 30s, 8m, 2.5h, 1d, 250ms or 1h30m. A bare number means seconds.

What it computes.

• Arrival rates. It solves the traffic equations for the arrival rate at every station, feedback loops included.
• Per-station results. For each station it gives the utilisation, the probability of waiting, the mean queue length, the waiting time and the time in the station. It uses the right model for what you declared: M/M/1 and M/M/c by Erlang C, M/M/c/K with exact blocking when a capacity is set, and M/G/1 exactly or G/G/c by the Allen–Cunneen approximation when variability is set.
• Whole-network results. It gives the total in the system, the throughput (arrivals minus blocked arrivals) and the end-to-end response time.
• The verdict. A one-line verdict names the bottleneck and the number of servers that would bring it under target.

Server circles are coloured by utilisation: green under 70%, amber up to 85% and red above. The bottleneck carries a badge. A station at or above 100% utilisation makes the network unstable. Its queue grows without limit, so its results are shown as "—" and the verdict says why, rather than printing an infinity that looks like an answer. Up to 14 stations are analysed. Beyond that the network is reported as cut short and no bottleneck verdict is given.

Spaghetti diagram

A lean motion study in which the walking is measured. Reference: Spaghetti diagram.

title "Nurse motion study — ward B, night shift"
scale 1m = 20px
room "Ward B" 24m x 14m
zone "Clean store" at 1,1 size 4x3
station Desk at 12,7
station Bed1 at 3,6
station Bed2 at 5,11
station "Meds room" at 20,3
path "Nurse A" : Desk -> Bed1 -> "Meds room" -> Bed1 -> Desk
path "Nurse B" colour: amber : Desk -> Bed2 -> "Meds room" -> Desk

scenario "After relayout"
station "Meds room" at 11,4

What you write.

• room sets the floor rectangle in real units.
• station NAME at X,Y places a destination. zone draws a shaded area that is context only and is not counted as a destination.
• path "Actor" : A -> B -> C traces one person's round. A leg can end at a literal point written (12,4). colour: pins an actor's colour.
• scenario "After relayout" starts a second layout. It inherits everything from the first, so you restate only what moved.
• scale affects the drawing only. Distances are always computed in your units.

What it computes: travel per actor and in total, the number of legs (a retraced leg counts twice), the longest leg, the most-travelled station pair (the link a relayout should shorten first), visits per station and the number of crossings where routes properly cross. With a second scenario it also computes the distance and crossings saved, both absolute and as a percentage. A station named in a path but never placed is put on a ring inside the floor, so the figure keeps drawing until you type its real position.

Quality and improvement

Control chart (SPC)

Statistical process control charts whose limits are computed from your data. Reference: Control chart (SPC).

title "Fill volume — line 3"
chart xbar-r
unit ml
spec lsl: 495 usl: 505 target: 500
rules: all
subgroup 500.1 499.8 500.4 500.0
subgroup 500.9 501.2 500.7 500.5
subgroup 499.6 500.1 499.9 500.2

Attribute charts take counts instead of measurements:

chart p
sample n: 1180 defects: 62
sample n: 1240 defects: 55

What you write.

• chart chooses i-mr, xbar-r, xbar-s, p, np, c or u. Without it, the type is inferred: counts give p, or c when no n is given. Subgroups of one give I-MR, subgroups of nine or more give X̄-S, and anything else gives X̄-R.
• subgroup (or group, sg) holds one subgroup of readings. value or point adds individual readings. A bare line of numbers is data too, so pasted columns work.
• sample n: … defects: … gives attribute data. For a u chart, n is an area of opportunity and may be fractional.
• spec lsl: … usl: … target: … sets specification limits and turns on capability.
• labels: sets tick labels. rules: chooses all, a list such as 1,2,5, or off.

What it computes.

• Limits. The centre line and control limits come from the standard unbiasing constants: I-MR from the moving range, X̄-R from the mean range, X̄-S from the mean standard deviation. Limits step per point when subgroup sizes vary. Attribute charts use their own formulas, also stepped when n varies, and a lower limit never goes below zero.
• Nelson rules. All eight Nelson rules run over the plotted series. Each violation is marked on the point that completes the pattern and listed. Only rule 1 applies to the range or sigma panel.
• Capability. When specification limits are given, the engine reports Cp and Cpk (from within-subgroup variation), Pp and Ppk (from overall variation) and the expected parts per million out of specification. Capability quoted for an unstable process carries an explicit caveat. On an X̄ chart the dashed specification lines are drawn for orientation only, and the figure says so, because specification limits apply to individual readings rather than to subgroup means.
• Verdict. A one-line verdict reads, for example, "Out of control — 1 of 3 points flagged by rule 1." or "In control — 2 points, no Nelson-rule violations."

Pareto chart

The 80/20 chart with its headline sentence derived from the data. Reference: Pareto chart.

title "Customer complaints — H1 2027 vs H2 2026"
unit complaints
period "H1 2027"
compare "H2 2026"
threshold 80%
other-below 2%

"Late delivery"        412   351
"Damaged packaging"    227   254
"Wrong item shipped"   141   132
"Billing error"         96    88
Unhelpful agent         64    71

What you write. Each data line is a label followed by one or two numbers: the charted period, then optionally the comparison period. Separators are flexible (:, =, | and commas all work), and repeated labels are added together. The directives are threshold (the vital-few cut, default 80%), other-below (fold small categories into Other), max-bars (fold everything past this many bars), period and compare (series names), unit and note.

What it computes: each category's share and the running cumulative percentage, the vital few (the leading categories up to and including the one that crosses the threshold), the share they carry and the Pareto ratio sentence. With a comparison period it adds a reference curve in the current period's order, and lists the categories that entered or left the vital few. Other is always drawn last and never counted among the vital few, because "Other" is not a cause anyone can fix.

SIPOC

The Six Sigma scoping diagram, which also checks itself. Reference: SIPOC.

title "New patient registration"
scope "Referral received" -> "Confirmation sent to patient"
owner "Access services team"
metric "Referral-to-appointment days" target: 14 actual: 19
metric "First-pass referral acceptance" target: 95% actual: 88% better: higher

suppliers: Referring GP practice, Insurer, Patient
inputs: Referral letter, Insurance eligibility response, Patient demographics
process: Receive referral -> Verify eligibility -> Create record -> Book appointment -> Send confirmation
outputs: Booked appointment, Confirmation letter, Updated record
customers: Patient, Outpatient clinic, Billing office

requirement input "Referral letter": "Complete, legible, dated within 30 days" (CTQ)
requirement output "Booked appointment": "Within 14 days of referral receipt" (CTQ)

What you write. Each of the five columns opens with its name. Items are comma-separated, or one per - bullet line, and a column opened twice accumulates. process: steps split on ->. scope, owner and metric fill the header. requirement attaches a critical-to-quality criterion to an item, and (CTQ) or ctq flags it as critical. A metric's better: defaults to lower, so write better: higher for yields and rates.

What it computes, in a notes strip: item counts per column, requirement gaps (inputs and outputs with no stated requirement, named one by one), requirement coverage, a scope check (whether the declared start and end match the first and last process steps, matched loosely), and each metric's variance against target in the declared direction.

Risk, safety and reliability

Fault tree (FTA)

Quantitative fault-tree analysis in IEC 61025 notation. Reference: Fault tree (FTA).

title "Loss of reactor cooling"
mission 8760h

top "Reactor cooling lost" = AND(pump_fail, backup_fail)
gate pump_fail "Main pump train fails" = OR(motor, power, control)
gate backup_fail "Backup train fails"  = KOFN(2, dg1, dg2, dg3)
gate control "Control loop fails"      = INHIBIT(ctl_fault, high_temp)

event motor "Pump motor failure"   p=0.02
event power "Bus power loss"       rate=1.2e-6
event ctl_fault "Controller fault" mtbf=45000h
condition high_temp "Coolant above 320 C" p=0.15
undeveloped dg1 "Diesel generator 1" p=0.03
undeveloped dg2 "Diesel generator 2" p=0.03
undeveloped dg3 "Diesel generator 3" p=0.03

What you write. The root is top … = EXPR, and intermediate events are gate id "Label" = EXPR. The gates are AND, OR, KOFN(k, …) (or the shorthand 2OF3(…)) and INHIBIT(event, condition). The leaves are event (a basic event), undeveloped, house … on or off, and condition. A leaf's probability comes from p, from rate or lambda per hour, from mtbf, or from fit (failures per 10⁹ hours), converted over the mission time, which defaults to one year.

What it computes.

• The exact top-event probability. It is computed exactly, even when one basic event feeds several branches. The common rare-event approximation is shown beside it, so you can see how far off the shortcut would have been.
• Minimal cut sets. They are ordered by size and then by probability. Order-one cut sets are single points of failure and are highlighted on the tree.
• Importance measures. Birnbaum importance shows which component would repay design effort, and Fussell–Vesely importance shows what share of the current risk runs through each component. Criticality importance is given too.

XOR, NOT, NAND and NOR gates are accepted but reported and computed as OR, because they make a tree non-coherent and the cut-set method assumes otherwise. An operator the engine does not know is also drawn and computed as OR, with a warning, so a half-typed tree keeps drawing. A gate that refers back to itself is reported as an error card naming the loop. A gate used twice is drawn once and referenced elsewhere by a transfer triangle.

Bowtie risk

A barrier-based risk diagram with the residual risk computed. Reference: Bowtie risk.

title "Loss of containment — LPG storage"
hazard "LPG stored under pressure"
top "Loss of containment"
unit "/yr"

threat "Corrosion of vessel wall" likelihood: 0.1 {
  barrier "Inspection programme" effectiveness: 0.8 type: detection
  barrier "Cathodic protection" effectiveness: 0.6
  escalation "Inspection deferred for turnaround" {
    control "Deferral requires VP sign-off"
  }
}

consequence "Vapour cloud explosion" severity: 5 {
  barrier "Gas detection + ESD" effectiveness: 0.85
  barrier "Emergency response" effectiveness: 0.5
}

What you write.

• threat lines carry a likelihood, which is a frequency (events per period). consequence lines carry a severity on any scale you use.
• barrier lines carry an effectiveness. pfd: is accepted too and inverted for you, so pfd: 0.1 means 90% effective.
• escalation hangs under the barrier it threatens, and control hangs under an escalation.
• Braces are optional: each barrier attaches to the latest threat or consequence.

What it computes:

Findings: a path defended by fewer than two barriers, a barrier with an escalation factor but no degradation control, and a "paper barrier" whose removal changes nothing.

Assumptions: a missing likelihood is taken as 0.1, a missing severity as 3 and a missing effectiveness as 0.5. Each assumption is listed in the findings, and effectiveness is capped at 0.99, because a barrier that cannot fail does not exist.

Reliability block diagram

System reliability, MTTF and availability, computed. Reference: Reliability block diagram.

title "Redundant power train"
mission 8760h

block grid "Grid supply"      mtbf: 4000h  mttr: 6h
block ups1 "UPS A"            r: 0.98
block ups2 "UPS B"            r: 0.98
block pdu1 "PDU 1"            mtbf: 260000h
block pdu2 "PDU 2"            mtbf: 260000h
block pdu3 "PDU 3"            mtbf: 260000h
block pumpA "Pump A"          rate: 2.5e-5 /h
block pumpB "Pump B"          rate: 2.5e-5 /h

series {
  grid
  parallel { ups1; ups2 }
  kofn 2 of 3 { pdu1; pdu2; pdu3 }
  standby cold { primary: pumpA; spare: pumpB; switch: 0.99 }
}

What you write.

• Blocks state their reliability as r:, as unreliability q:, as mtbf: or mttf:, or as a failure rate (rate:, which also accepts fit). mttr: adds repair time, which turns on availability.
• The arrangements are series, parallel, kofn k of n (members need not be identical) and standby with cold, warm or hot spares, an optional dormancy: and a switch: success probability.
• mission sets the mission time, which defaults to one year. A block referenced but never declared is drawn dashed and assumed perfect.

What it computes: system reliability at the mission time; system MTTF, integrated numerically and reported as a lower bound when the system is too reliable to decay within the horizon; steady-state availability when repair times are given; and a ranked importance for each block, with its share of system unreliability, so the weakest link is named. A redundancy check deletes each redundant branch in turn and flags any branch worth less than 0.1% of system reliability, meaning redundancy you pay to maintain but that buys almost nothing.

Attack tree

Threat modelling with the attacker's cheapest path. Reference: Attack tree (cybersec).

title "Steal credentials"
goal G "Steal user credentials"
OR   G1 "Phishing"          parent G
AND  G2 "Server compromise" parent G
leaf L1 "Send phishing email"  parent G1  cost 1   skill low    detect medium
leaf L2 "User clicks link"     parent G1  cost 0   skill none   detect low
leaf L3 "Exploit RCE"          parent G2  cost 5   skill high   detect medium
leaf L4 "Dump password DB"     parent G2  cost 2   skill medium detect high

AND nodes need all their children to succeed, and OR nodes need any one of them. Leaf cost, skill and detect values show as chips. Cost rolls up the tree: an AND adds its children's costs and an OR takes the cheapest. When a child has no cost, the chip says how many steps the number leaves out. A node whose parent names nothing, or an id declared twice, is reported, because either would quietly remove part of the threat model. Diagram Intelligence adds the number of attack scenarios, the cheapest attack and defender choke points (see below).

Decision tree

Decision analysis with the expected-value rollback computed. Reference: Decision tree.

title "Commercialise the X-200 sensor?"
currency $
unit k

decision "Commercialise?"
  "Launch in-house" cost 1,200 -> chance "Market response"
    "Strong"   p 0.35 -> 5,200
    "Moderate" p 0.45 -> 2,400
    "Weak"     p rest -> 300
  "License to partner" -> end "Royalty stream" 1,500
  "Shelve" -> 0

What you write. Indentation is structure. decision, chance (alias uncertainty) and end (aliases terminal and payoff) declare nodes, and the first node line is the root. Each branch is a label followed by optional p (a probability such as 0.35, 35%, 1/3, or rest for the complement of its siblings), cost, gain and an arrow (->, => or →) to the node or value it leads to. A bare value after an arrow is an outcome. The directives currency, unit, objective max or objective min (payoffs or costs), measure, risk-tolerance, risk-profile on or risk-profile compare, probabilities percent, branches orthogonal, terminals natural and decimals control the analysis and the drawing.

What it computes: the rollback from right to left (each chance node is replaced by its probability-weighted value and each decision by its best alternative, with branch costs paid on the way through), the optimal choice at every decision with rejected alternatives struck through, the expected value on every node, and the probability of reaching each outcome under the optimal strategy. The example's verdict reads "Best first choice: “Launch in-house”, EV $1,760k". With risk-profile, it draws the distribution of outcomes and, in compare mode, names first-order stochastic dominance between the first choices. With risk-tolerance, it adds exponential-utility certainty equivalents and says when they change the decision.

What it flags: chance probabilities that do not sum to 1 (the affected values print as "—"), sums within ±0.002 of 1 (normalised, and said), missing or out-of-range probabilities, a probability written on a decision branch, dead ends, single-branch nodes, and lines it could not read or place.

Risk matrix

A risk register and its heat map, scored rather than coloured by hand. Reference: Risk matrix.

title "Enterprise risk register"
bands: Low 1-3, Medium 4-6, High 8-12, Critical 15-25
appetite: Medium

risk R1 "Ransomware encrypts the ERP"
  owner: CISO
  likelihood: 4
  impact: 5
  control "Immutable offline backups"
  residual: 2x5
  action "Segment the plant network" due: 2027-06 owner: "Head of IT"

risk R2 "Key supplier insolvency" 3x4 -> 2x4 owner: Procurement

What you write. risk [ID] "Title" (or hazard) opens a risk. Under it, likelihood and impact take a level number or a level name, residual and target take positions such as 2x5, and control, action (with due: and owner:), owner, category and trend fill in the register. Inline, 3x4 -> 2x4 -> 1x4 is inherent, residual and target. likelihood-levels: and impact-levels: name 2 to 7 levels per axis (the default is 5 × 5). bands: (or thresholds:) rates the scores, matrix rates each cell directly for matrices that are not likelihood × impact, appetite: takes a band or a score, and sort: and view: control the register order and what the heat map plots.

What it computes: the score and rating of every position, the register sorted by current position, the change from inherent to residual, the band profile, total exposure and its reduction, and every risk above appetite. The example's headline reads "2 risks; residual exposure 18 against 32 inherent (−44%); 2 above the Medium appetite; 2 warnings."

What it flags: a residual worse than the inherent position, a reduction no control explains, controls with no residual assessed, a target worse than the residual, a risk with no owner, a risk above appetite with no treatment action, bands that leave a score unrated or rate it twice, a non-monotonic cell matrix, duplicate ids and unreadable lines. Every cell carries its band name and score as text, so colour is never the only signal.

Data flow diagram

Gane–Sarson data flow diagrams that double as a threat model. Reference: Data flow diagram.

title "Payments — level 1"
level 1
entity Customer
entity "Card network"
process 1   "Accept order"
process 2.1 "Authorise payment"
store D1 "Orders"
store D2 "Audit log"
boundary "Public internet" { Customer }
boundary "PCI zone" { 2.1, D2 }
Customer -> 1 : "order + card details"
1 -> 2.1 : "auth request"
2.1 -> "Card network" : "ISO 8583"
2.1 -> D2 : "auth result"
D1 -> 1 : "order status"

What you write.

• entity, process and store declare the elements. An id such as 1, 2.1 or D1 is recognised, and names used in a flow without a declaration are created with a kind inferred from their shape.
• boundary "Name" { … } draws a trust zone. A member that never resolves is dropped rather than invented.
• A -> B : "label" draws a flow, and <-> draws flows both ways.
• level sets the diagram level, and findings off hides the analysis strip.

What it flags, errors first:

Design structure matrix

Dependency matrices with partitioning. Reference: Design structure matrix.

title "Vehicle programme dependencies"
mode process
convention ir-fad
elements: Concept, Styling, Packaging, Body, Chassis, Powertrain, Testing
Styling    <- Concept
Packaging  <- Concept, Styling
Body       <- Packaging, Styling(2)
Chassis    <- Packaging
Powertrain <- Concept, Packaging
Testing    <- Body, Chassis, Powertrain
Styling    <- Testing

What you write. A <- B, C means A takes input from B and C. A -> B reads the other way, and A depends on B works too. A strength from 1 to 9 is written Name(2) or Name:2. elements: fixes the declared order. mode is process, component, team or parameter. convention is ir-fad (inputs in rows, feedback above the diagonal, the default) or ic-fbd (the transpose), and the figure prints which one is in force.

What it computes: the cycles (strongly connected groups), a partitioned order that sequences independent work first and gathers each cycle into an iteration block that must be worked together, and the number of feedback marks before and after partitioning. The footer states the result as a sentence such as "23 feedback marks reduced to 6 across 2 iteration blocks.", "3 feedback marks eliminated — the partitioned sequence is fully ordered." or "No feedback marks — this dependency set is already fully ordered." The figure shows the declared and partitioned matrices side by side, with the iteration blocks boxed.

Automation and control

Ladder logic (PLC)

IEC 61131-3 ladder diagrams that are solved for one scan. Reference: Ladder logic (PLC).

title "Motor starter"
state: Start_PB, Stop_PB, Motor_Run

rung "Seal-in"
  branch
    xic Start_PB
    xic Motor_Run
  xic Stop_PB
  ote Motor_Run

rung "Jam watchdog"
  xic Motor_Run
  xic Eye_Blocked
  ton T_Jam preset: 6 accum: 8 unit: s

What you write.

• state: lists the tags that are true. A bare tag is true, and Tag = 0 is false.
• rung opens a rung, and branch opens parallel legs (OR).
• Instructions come in two forms, an ASCII-art form and a keyword form, and you can mix them line by line. The keyword forms are xic Tag (normally open contact), xio Tag (normally closed contact), ote Tag (output coil), set Tag (latch), reset Tag (unlatch), the timers ton, tof and tp with preset: and accum:, and the counters ctu and ctd. The same contacts and coils in ASCII-art form look like this:

--| |--Start_PB      # normally open contact, same as: xic Start_PB
--|/|--Jam           # normally closed contact, same as: xio Jam
--( )--Motor         # output coil, same as: ote Motor
--(S)--Alarm         # latch, same as: set Alarm
--(R)--Alarm         # unlatch, same as: reset Alarm

A whole rung can be written on one line: --| |--Start_PB----|/|--Jam----( )--Motor.

What it computes: one scan from top to bottom, exactly as a controller would run it, with energised rails, contacts and coils highlighted. Timers and counters resolve their done bits from the declared accumulated value. Time does not advance during a single scan.

What it flags: a duplicate destination (a tag written by more than one output), outputs never energised in the declared state, tags read but never written, and rungs with no output.

GRAFCET / SFC

Sequential function charts checked against the IEC rules. Reference: GRAFCET / SFC.

title "Bottling line — filler cycle"

step 1 "Idle" initial
  action N "Conveyor stopped"
step 2 "Index bottle"
  N "Conveyor forward"
  S "Gate solenoid"
step 3 "Fill"
  N "Fill valve open"
  L 8s "Nitrogen purge"
step 4 "Cap"

transition t1 : "start . bottle_present"
transition t2 : "bottle_at_filler"
transition t3 : "level_high + timeout"
transition t4 : "cap_done"

1 -> t1 -> 2 -> t2 -> 3 -> t3 -> 4
4 -> t4 -> 1

What you write. step declares a numbered step, marked initial or final where appropriate. Action lines go under a step, with the IEC qualifiers N, S, R, D, L, P and C, a time for D and L, and an optional if condition. transition gives a receptivity, where . means AND, + means OR and /x means NOT. Link lines chain steps and transitions with ->. A comma list opens or closes a branch: one step to several transitions is an alternative (OR) branch, and one transition to several steps is a simultaneous (AND) branch.

What it checks: that steps and transitions alternate on every link, that there is exactly one initial step per sequence, that every step is reachable from the initial step, that there are no dead ends except steps marked final, that every AND branch is closed by a convergence of the same width, that transitions have a receptivity, and that step numbers are not duplicated. Every offending link is named and drawn in the warning colour.

Planning and product

Gantt & critical path

Project schedules computed from durations, dependencies and a working calendar. Reference: Gantt & critical path.

title "Platform launch"
start 2026-03-02
calendar mon-fri
holiday 2026-04-03 "Good Friday"
today 2026-04-15
deadline 2026-06-30 "Contract date"

resource alice "Alice Chen"
resource bob   "Bob Ortiz"

section "Discovery"
  task disc  "Discovery workshops" 5d
  task spec  "Write the specification" 8d after disc
section "Build"
  task api   "Service API" 15d after spec assign alice
  task ui    "Web client"  12d after spec assign bob
  task join  "Integration"  6d after api, ui
  milestone beta "Beta release" after join

What you write. Tasks have a duration and after dependencies. All four relationships are supported, with lag or lead, for example after ss:spec +2d. You can also declare resources with an optional capacity, assignments such as assign alice 50%, holidays, a today date, deadlines, baselines and progress. Every date written in the document is treated as a claim to check, never as a position for a bar, and you cannot mark a task critical by hand. view network draws the same schedule as a precedence network instead of bars.

What it computes and flags: the forward and backward pass, the critical path, total and free float drawn as whiskers on each bar, and these findings:

For a simpler finish-to-start network in whole days, the PERT / CPM network engine draws early and late start and finish and the slack in every node. See PERT / CPM network.

User story map

Jeff Patton-style story maps with the first-release gaps computed. Reference: User story map.

title "Peer-to-peer marketplace — MVP"
persona "Casual seller clearing out a spare room"
goal "List an item in three minutes and get paid"

release "R1 — Walking skeleton"
release "R2 — Trust and safety"

activity "Discover"
  task "Search listings"
    R1: "Keyword search" (3)
    R2: "Filter by category" (5)
  task "Browse a listing"
    R1: "Listing page with photos" (3)
activity "Transact"
  task "Pay"
    R1: "Card checkout" (8)
    later: "Stored wallet balance" (13)

What it computes:

• Per release: the story count, the estimated and unestimated split, total and cumulative points, and the activities each release touches and misses.
• Per activity: the task count, story count and points, broken down by release.
• First-release gaps: the activities with no story in the first release. They are drawn as dashed gap markers across those columns and named in the summary.
• Walking skeleton: true only when the first release touches every activity on the backbone.
• Smallest full slice: the cheapest release that does span the backbone.
• Heaviest release: the release carrying the most points.

Estimates are written (3), [5], (8 pts) or 13 points, and (?) marks a story as deliberately unestimated. later, backlog, someday, future and icebox all mean a band sorted last.

Customer journey map

Journey maps with the emotion curve and its headline computed. Reference: Customer journey map.

title "Switching broadband provider"
persona "Priya Shah"
  goal: Faster broadband with no gap in service

stage "Discover"
  emotion: -1 Uncertain
  pain: Availability checker demands an email address first
  opportunity: Postcode-only availability check
stage "Order"
  emotion: 1 Relieved
stage "Install"
  emotion: -2 Furious
  pain: Engineer missed the slot

What you write. persona opens a persona card (role:, age:, goal:, needs:, frustrations:, quote:, context:). phase groups stages under a band. stage opens a column, and the rows under it are goal, actions, touchpoints, thoughts, emotion, pains, opportunities, owners, metrics and time, each with common aliases. Items on one line are separated by | or ;. emotion is a score from −2 to +2, optionally followed by a word, or a bare word such as frustrated or delighted.

What it computes: the moment of truth (the lowest-scored stage, with ties named), the peak, the pain points per stage, the sharpest drop between stages and the average score. It flags every stage that carries a pain point with no opportunity against it, and reports unread lines, unknown row keys (with the nearest real key suggested), off-scale emotions, stages with no score (the curve is dashed across them), duplicate and empty stages. The example's headline reads "3 stages from “Discover” to “Install”; moment of truth at “Install” (−2); 2 pain points and 1 opportunity."

Decision matrix (weighted / Pugh)

Weighted scoring and Pugh concept selection with the sensitivity answered. Reference: Decision matrix.

title "ERP platform selection"
scale 1-5
options "Tier-1 suite" | "Cloud mid-market" | "Open-source ERP"

"Functional fit"   weight 50 : 5 4 3
"Reporting"        weight 20 : 4 5 3
"5-year cost" weight 30 unit "£k" lower must <= 1,500 : 1,650 980 620

What you write. options lists the columns. Each criterion row is a quoted label, its attributes and a colon followed by one score per option. The attributes are weight, lower (lower is better), raw or unit (the cells are measurements and are rescaled onto the score scale), range (fixed anchors for that rescaling) and must (a knock-out threshold). group "Name" weight 40% gives two-level weighting. Writing +, ++, S, - or -- against a datum (baseline "Name") turns the same notation into a Pugh matrix with Σ+, ΣS, Σ− and a net score.

What it computes: normalised weights, every weighted total, the ranking and the winner, options excluded by a must-have whatever their total, and the sensitivity: the smallest single-weight change and the smallest single-score change that would change the winner. In the example, "Tier-1 suite is excluded — it fails a must-have", and the verdict reads "Cloud mid-market ranks first at 4.08 of 5 (81.6%), 0.48 ahead of Open-source ERP."

Roadmap

Product and programme roadmaps whose dependency arrows are checked against their dates. Reference: Roadmap.

title "Payments platform — 2027 roadmap"
axis quarters 2027-Q1 .. 2027-Q4
today 2027-05-12

milestone pci "PCI DSS 4.0 assessment" 2027-03-31 done

lane "Checkout"
  item oneclick "One-click checkout" Q1 .. Q2 done
  item wallets "Apple Pay and Google Pay" Q2 .. Q3 in progress 40% after oneclick
  milestone "Wallets GA" 2027-09-30 after wallets

What you write. axis sets the scale (months, quarters, halves, years, or buckets such as Now, Next and Later) and its range. today sets the status date, read from the document, never from the clock. lane opens a lane, with an optional color:. item [id] "Title" <when> [status] [NN%] [after a, b] [owner: X] places work, and milestone places a moment, globally before the first lane or inside a lane. Times can be dates, months, quarters, halves, years or bucket names, and ranges join two of them with ... The four statuses are planned, in progress, done and at risk, each with its own symbol as well as a colour.

What it computes and flags: every dependency is checked. A prerequisite still running when its dependent starts is drawn red and named with the overlap; in the example, "“Apple Pay and Google Pay” starts 1 Apr 2027, but “One-click checkout”, which it follows, runs until 30 Jun 2027 — 91 days of overlap." Loops and unknown prerequisites are errors. With a status date it reports anything overdue and anything marked done or in progress before it was due to start, and it names the longest dependency chain.

Event storming

An event-storming board with the domain-model gaps computed. Reference: Event storming.

title "Order fulfilment"

context "Ordering"
  actor Customer
  aggregate Order
  command "Place order" by Customer on Order
  event "Order placed" from "Place order"
  readmodel "Basket summary"
  external "Payment gateway"
  hotspot "What if the card is authorised twice?"
  policy "When order placed, reserve stock" then "Reserve stock"

context "Warehouse"
  aggregate Reservation
  command "Reserve stock" by "Fulfilment service" on Reservation
  event "Stock reserved" from "Reserve stock"

Stickies use the canonical colours: orange events, blue commands, yellow actors, purple policies, pink external systems, green read models, lilac aggregates and red hotspots. Each context is a swimlane.

What it checks: events no command produces, commands that produce no event, commands with no aggregate, aggregates with no events, policies with a missing trigger or command, hotspots per context, every cross-context flow (an event in one context that wakes a policy issuing a command in another), and event coverage. A policy written in the usual way, "When X, Y", is wired from its own sentence.

Business model canvas

The Business Model Canvas and the Lean Canvas from one syntax, with an evidence audit. Reference: Business model canvas.

title "Clinic booking app"
layout bmc
currency GBP

partners: "Practice management vendors" !, "Insurers" ?
activities: "App development" !, "Clinic onboarding"
resources: "Booking engine" !
value: "Book any clinic in under a minute" !
relationships: "Self-serve onboarding" ?
channels: "Clinic referrals" !, "Search" ?
segments: "Independent clinics, 2-20 staff" ?
costs: "Hosting 2k/mo" !, "Salaries 45k/mo" !
revenue: "Clinic plan 49/mo x 600" ?, "Per-booking fee 0.50"

What you write. The nine blocks open with their names, and both vocabularies are always accepted: problem: on a business model canvas lands in Key partners, and partners: on a lean canvas lands in Problem. layout bmc or layout lean chooses the grid. Without it, the layout is inferred from the words you used. A trailing ! marks a validated claim and a trailing ? an unvalidated assumption. A note with neither is unmarked. Declaring an empty block (advantage: with nothing after it) records that you looked and found nothing.

What it computes: the split of validated, assumed and unmarked notes, the blocks that are still empty, and monthly totals for costs and revenue. Figures are normalised to a monthly amount: 4k/mo is 4,000 a month, 780k/yr is 65,000, and 19/mo x 1200 is 22,800. A unit price with no quantity, such as 29/seat/mo, is deliberately not added in, and is counted in an "unpriced" footnote.

Diagram Intelligence

Diagram Intelligence works on the figure you already have, in any of a wide range of engines. It reads the diagram's structure and reports metrics and findings beside it. For process-shaped diagrams, it also runs the process.

Opening it

Click Diagram Intelligence on the tool rail, press ⇧⌘X (Ctrl+Shift+X), or choose Diagram Intelligence under Go to in the command palette. It opens in the right-hand drawer, titled Diagram Intelligence. Close it with its × ("Close (Esc)").

The analysis follows your typing and updates when you pause. With nothing to say for the current engine, it reads: "No structural insights yet for this engine — try Mermaid, D2, Graphviz, DBML, ERD, Structurizr, Wardley, Petri Nets, or Chess. Or just keep building, and insights will appear as the diagram grows."

What the panel shows

• A summary line naming what was read, for example "DOT graph" or "C4 architecture workspace".
• Metrics, as tiles. Hover over a tile for an explanation of how it was worked out.
• Insights, each shown as a card whose colour and icon give its severity. The cards carry no severity word, so read them by colour and icon:

What it reads, engine by engine

On a model whose arrows mean "refers to" rather than "flows to", such as an ER diagram, a C4 model or a network, the wording changes accordingly. For example, "not referenced by anything" replaces "entry point", and a cycle reads as a two-way relationship, not as a loop to fix.

The flow arithmetic for process diagrams

When a Mermaid flowchart, a Graphviz or D2 graph, a PlantUML diagram, a Structurizr model or a Cytoscape network looks like a process, Diagram Intelligence runs it through the same deterministic simulator that animates processes in Weave. It then adds:

It also adds insights such as "Work waits at Review", with the average and peak queue, or "Nothing queues" when every step keeps up. These are never marked as issues, because a bottleneck is a fact about your process, not a mistake in your drawing.

A graph counts as a process when it has at least three nodes, at least one entry (nothing points at it), at least one exit (it points at nothing), and enough edges to be more than a bare tree. Ontologies, ER diagrams and mind maps usually fail these tests, and then no lead time is reported, because one would be meaningless.

Give the steps durations to get real numbers. Without them, every step counts as one unit of time and the bottleneck shows where the graph converges rather than where the time goes. The panel says so: "Timings assumed — this reads the SHAPE, not the clock". Write the duration in the label and the numbers become measurements:

flowchart LR
  A[Order received] --> B[Review 2d]
  B --> C{Approved?}
  C -->|yes| D[Build 3h]
  C -->|no| B
  D --> E[QA 45m] --> F[Shipped]

Durations are read from labels such as Review (2d), Bake 45m, QA [3h], Cool 90 s or the compound Cure 1h 30m:

A bare number with no unit is not read as a duration, so "Station 3" stays a label. Weeks and months are deliberately not read, because 2m would be ambiguous. Results are shown in the largest unit that keeps the shortest step readable. A node with two or more outgoing edges is treated as a decision that splits work equally between its branches, and loops such as rework are allowed. Any limit the simulation reached is reported as a Simulation note. If only some steps have durations, the panel tells you how many are missing.

Fix with the flowss Studio Agent, and Explain this diagram

• Fix with the flowss Studio Agent appears on red and amber insights. The button reads Fixing… while it works. It asks the flowss Studio Agent to repair that specific finding. A fix that would break a diagram that currently works is refused, and the message names the check that stopped it. Otherwise a message tells you what happened, for example "Applied the flowss Studio Agent's fix — …", or "Applied — the flowss Studio Agent also switched to …" when the answer changed engine. If the flowss Studio Agent decides the diagram is already right, you see "Checked — the flowss Studio Agent agrees the diagram is right as drawn." and that insight is set aside until you next edit the source. If the diagram changed while the fix was running, you see "The diagram changed while the fix was running — run it again." and nothing is applied.
• Explain this diagram, at the bottom of the panel, gives a plain-language description of what the diagram shows. It reads Explaining… while it works and is disabled while the source is empty. For Mermaid flowcharts and DBML schemas the description is written by flowss itself, with no AI and no cost. For other engines it asks AI for three to six short bullet points, including any structural insights that are not obvious. It never changes your diagram, and the description clears when you edit the source.

Fix with the flowss Studio Agent always needs AI on your plan and uses one AI call. Explain this diagram needs AI only for engines flowss cannot describe itself. If AI is not available, you see "Add an AI key in Settings to use AI fixes." or "Daily AI limit reached.", and other failures read "Couldn't reach the model." or the service's own message. See AI points and limits.

Discovering a process from an event log

If you have a log of what actually happened, rather than a drawing of what should happen, open Data → Chart (⌘D) and paste or drop it. When the rows have a case column, an activity column and a timestamp column, the panel offers Discover process. It shows the discovered model in words with its most common variants, lets you filter rare handoffs with a Noise filter, and opens the result in the BPMN studio or saves it as a .bpmn file. Every step and message is described in Data, timeline, TikZ and the diagram tools.

Simulation in Weave and BPMN

The Studio computes the arithmetic. Two other studios let you watch it happen:

• Weave runs the same deterministic simulator on its canvas and animates the work moving through your board, with utilisation, queues and lead time. See Weave and The Flow layer.
• BPMN lints, auto-fixes and simulates real BPMN 2.0 processes with token flow, cycle times and bottlenecks. See BPMN.

To carry a Studio diagram into either studio, use Send to another studio… from the ⋮ menu or ⌘K. See Moving work between studios.

The readiness chip

The checks each flow-systems engine runs, and the findings Diagram Intelligence reports, also feed the readiness chip in the Studio's status panel. Open it from the status mark beside the document title, or press ⇧⌘M. The chip places your figure on a five-step scale:

So a fault tree with a cyclic gate, or a GRAFCET chart whose steps do not alternate, cannot read as Sound, however tidy it looks. See The Studio editor for how to use the chip's suggested next steps.

Tips

• Start from a template. Every engine on this page has templates. Open its reference page at /docs/engines/ followed by its id, or search the Studio's template library, and edit real numbers into a working example rather than starting blank.
• Write the facts, not the totals. If you find yourself wanting to type a total, a limit or a probability, that is the number the engine computes. Type the inputs instead.
• Annotate durations in ordinary flowcharts. Adding (2d) or 45m to the step labels of an existing Mermaid flowchart turns Diagram Intelligence's flow arithmetic from a statement about shape into a measurement.
• Mark waiting stages. In a CFD, * on waiting stages is what makes flow efficiency possible. In a value stream map, wait and inventory lines carry the non-value-added time.
• Use a second scenario. The Spaghetti diagram's scenario and the Pareto chart's compare turn one figure into a before-and-after argument, with the difference computed.
• Read the notes strip before you present. Each engine says what it assumed or could not read. A note such as "likelihood assumed 0.1" is the line a reviewer will ask about.
• Name the analysis in the version history. Before changing inputs for a what-if, name the current version in the Diagram timeline so you can compare the two later.

Limits and known constraints

• The Studio does not animate. It computes results and draws them into the figure. Animated token flow is in Weave and BPMN.
• Flow arithmetic has a scope. Diagram Intelligence runs it only for Mermaid flowcharts and state diagrams, Graphviz, D2, PlantUML, Structurizr and Cytoscape, and only when the graph looks like a process. Its simulation uses 16 arrivals at one-unit intervals, so it suits comparing shapes and finding constraints, not capacity planning. Use the Queueing network engine for steady-state capacity questions.
• Unannotated steps count as one unit. On a diagram with no durations, every step takes one unit of time.
• Engines have their own model limits. Each works within the limits of its model. The Queueing network analyses up to 14 stations. Reliability block diagrams assume constant failure rates (an exponential life), so they do not substitute for a wear-out analysis. Bowtie effectiveness is capped at 0.99. Ladder logic solves a single scan and does not advance timers.
• Large documents are cut short. When a document exceeds an engine's size limits, the engine says so and withholds its verdict rather than judging part of the document.
• AI actions need AI. Fix with the flowss Studio Agent needs AI on your plan, and so does Explain this diagram on engines other than Mermaid flowcharts and DBML. Everything else on this page is computed without AI and works on every plan.

Troubleshooting

Related pages

• Choosing an engine
• Process, operations and quality engines
• The full engine catalogue
• Data, timeline, TikZ and the diagram tools
• The Studio editor
• BPMN and Weave
• The Flow layer
• Use cases by role
• AI points and limits