Process, operations and quality engines

This is the syntax and behaviour reference for the Studio engines that model how work, material, risk and control logic move through a real operation. It covers lean and flow (value stream maps, cumulative flow, queueing networks, spaghetti diagrams, swimlanes, Kanban boards and service blueprints), quality and improvement (SIPOC, control charts, Pareto charts, fishbones and design structure matrices), risk, safety and reliability (fault trees, bowties, reliability block diagrams and attack trees), and automation and process engineering (ladder logic, GRAFCET and P&ID). Most of these engines do more than draw. A value stream map works out its own lead time, a control chart computes its own limits, a fault tree computes its own top-event probability, and a ladder diagram is solved for one scan. For each engine you will find the statements it reads, every keyword and alias, the defaults it assumes, what it computes, what it flags, its size limits and the templates you can start from. For a guided tour of the analysis with worked examples, read Flow-systems analysis in Studio alongside this page.

At a glance

Every engine on this page is part of the Studio's engine library and works on every plan, including Free, with no cap on how much you draw. (Free keeps three saved figures per studio; see Plans and what they include.) They all render inside flowss itself, with no outside service, so they work offline, your source never leaves flowss to be drawn, and the render API can draw them on a server. Every computation and every check on this page runs without AI. Only the optional AI features around them (Photo → Engine, AI conversion, Ask the flowss Studio Agent… edits and the flowss Studio Agent) need AI on your plan: your own key from Starter, hosted AI points from Plus. See AI points and limits.

Opening these engines

You can open any engine on this page in four ways.

1. From the engine library. Click Engines & templates at the top of the Studio's tool rail, or click the engine name at the top of the code sheet. On the Engines tab, open the group named in the table above (Flow systems, Risk & reliability, Quality & control, Flow & UML or Research & analysis) and click the engine's row.
2. By searching. The library's search box ("Search engines — name, or what you're drawing…") matches names and ids, what you are drawing and the tool you are replacing. Try takt, control chart, fault tree, Minitab, BowTieXP or PLC.
3. From a link. /studio?engine=valuestream opens the Studio with that engine selected, and /studio?template=<template id> opens one template. Every engine's reference page at /docs/engines/ followed by its id has an Open in button and sample templates.
4. From a template. Press / in the Studio to open the library on the Templates tab with its search box ready, or browse the template gallery.

Warning: Clicking an engine row replaces the current figure's source with that engine's starter template. It does not convert your diagram. ⌘Z brings the previous source back. To keep your current figure, start a New figure (⌥⌘N) first and pick the engine there. See Choosing an engine.

If you have a photograph of a whiteboard value stream map, a printed ladder diagram, a hand-drawn fault tree or a control chart taped to a machine, Photo → Engine (⋮ → Import, Plus and above) can read it into the matching engine. See Importing and converting.

What these engines have in common

Writing the source

All of these engines read plain text, one statement per line. They are forgiving by design: a half-typed line never blanks the canvas. Lines the engine cannot read are skipped and, in every engine on this page, reported rather than dropped in silence.

Tip: In the engines that only accept whole-line comments, a trailing // note after a statement becomes part of that statement. Put comments on a line of their own.

Units and numbers

The quantitative engines read units the way you would say them.

Defaults are stated, never hidden

Where an engine assumes a value you did not write, it says so on the figure. For example, a fault tree prints its mission time as "8760 h (default)" when you gave none, a bowtie lists every assumed likelihood, severity and effectiveness in its findings, and a queueing network notes when it is sizing servers against the default 85% target.

How findings are graded

Each engine's own checks report findings at one of five levels. This page uses the same five words in each engine's findings table.

Every engine on this page has its checks wired into the readiness reading in the Document status popover beside the document title (click the status glyph, or press ⇧⌘M). Errors and warnings count against the figure and gaps are recorded as things that could not be checked, so a fault tree with a cyclic gate or a GRAFCET chart whose steps do not alternate cannot read as finished, however tidy it looks. See The Studio editor.

Note: A low flow efficiency, a step over takt, an out-of-control chart, a large walking distance or a single point of failure is never reported as a defect. These are the results the figure exists to show. The checks are mostly about whether the engine read your document completely and whether its statements agree with each other. A few design problems are raised on purpose: a queueing station at or above 100% utilisation has no steady state, so no queue length or waiting time exists for it, and the engine reports that as an Error rather than print numbers that are not answers; a queueing station over its target, a bowtie path with fewer than two barriers or a barrier that changes nothing, and RBD redundancy that buys almost nothing are Warnings.

When a document is too big

Swimlane, Pareto and GRAFCET read lines of up to 2,000 characters, as do Petri nets, the causal DAG and the quadrant matrix. A longer line is not read, and the figure says so by line number, for example "Line 4 was not read — it is 2,431 characters long, and this engine reads lines of up to 2,000 — split it into shorter lines".

Each engine caps the size of what it analyses, listed in Limits at a glance. When a cap is reached the engine keeps drawing what it read, says how much it did not read, and withholds any verdict that would be a claim about the whole: a value stream shows "Flow efficiency (withheld)", a fault tree shows "Top event probability (withheld)", a queueing network names no bottleneck, and sums such as lead time are shown with "≥" because they are floors. If the cut fell before anything drawable, the figure says "…is empty because the document was not read to the end" rather than showing an empty-document hint.

Where results appear

Results are part of the figure: a strip of metric tiles, a findings or notes strip, and marks on the drawing itself (a red step, a bottleneck badge, a highlighted cut set). Exports carry them, so a reviewer sees what you saw. Exports are covered in Exporting your work.

Lean and flow

Value stream map

A lean value stream map whose totals are derived from its steps, so the picture and its numbers cannot drift apart.

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

Statements

Information-flow endpoints are supplier, customer, control or a process name (matched without regard to case, and by prefix). The arrow is dashed when the line contains electronic, edi, digital, system or automatic, and solid otherwise (manual and paper are accepted as documentation).

Data-box keys

Entries may be written key: value, key = value or key value. A key the engine does not model, such as wip: 40, is still shown as an extra row in the data box rather than dropped (up to six extra keys per box).

What it computes

Effective cycle time is cycle time ÷ uptime ÷ operators. Downtime stretches the interval between finished units and parallel operators divide it, so a four-doctor room with an 18-minute consultation is not flagged against a 4.5-minute takt. Without takt (no takt line, and not both demand and available), the takt tiles are simply left out, and a count-only inventory contributes nothing to lead time; the figure shows the raw count instead.

The drawing shows the supplier and customer band with the information arrows, the process boxes with data boxes beneath (up to ten rows each), inventory triangles between steps, and the sawtooth timeline ladder along the bottom, with waits on the upper steps and value-added time on the lower ones.

What it checks

Every line that matches no statement is an Error, because this engine has no catch-all: a mistyped delya 3600 would otherwise take its wait out of the lead time, demnd 400 would leave the map with no takt, and procss "Weld" ct 90 would remove a box and its cycle time from every sum. Up to six such lines are listed one by one, then "…and N further lines." When a size limit is reached, a Gap says so, sums are shown as floors ("Lead time (partial)" with "≥") and the ratios are withheld ("Flow efficiency (withheld)", "Constraint (withheld)").

Note: The document check currently reads only lines that start with a statement keyword. A step written as a bare Triage { ct: 6m } without the process keyword, and the continuation lines of a data box spread over several lines, are drawn and counted correctly on the map but are reported as lines not read in Document status. To keep the status clean, start every step with process and keep each data box on one line.

Templates: Hospital Blood Transfusion, Vaccine Fill-Finish Suite, Adult Passport Renewal, Emergency Department, Automotive Door Line, Deployment Pipeline, Mortgage Approval, Restaurant Kitchen Line, Warehouse Fulfilment, Motor Insurance Claims, Semiconductor Fab Module, Speciality Coffee Roastery and Postgraduate Admissions.

Flow metrics (CFD)

A cumulative flow diagram with the flow metrics derived from the same numbers.

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

Statements

A trailing * on a stage name, or (queue), (queued), (wait), (waiting) or (q), marks it as a waiting stage. Without at least one waiting stage, flow efficiency reads "n/a" with the caption "mark queue stages with *", rather than being guessed.

Data rows hold, for each stage, how many items had entered that stage by that date. Dates may use - or /. Rows need not be evenly spaced: the x axis is a real date axis and per-day rates use the actual elapsed days. Rows out of date order are sorted. A row label that is not a date is allowed when you use the pipe (for example Sprint 1 | 40, 12, 3); the chart then works in periods rather than days. Numbers may contain _ separators.

What it computes

A table beneath the chart has one row per stage, with the columns Stage, Type ("active", "waiting" or "done"), WIP (in your unit), Limit ("—" when none is declared) and Time (in days, or periods when rows are not dated). Time is the stage's residence time, its current WIP ÷ throughput; over the committed stages these add up to the cycle time. A WIP figure over its limit is shown in bold in the warning colour.

Warnings and notes

Up to six warnings and five notes are printed under the chart.

The chart needs at least two stages and one data row; until then it shows a syntax hint headed "Cumulative flow diagram".

What it checks

Templates: Software Delivery Team, Support Ticket Queue, Hiring Requisition Pipeline, Manufacturing Cell WIP, Video Content Pipeline, Hospital Bed Flow, Mortgage Application Flow, ML Experiment Queue, Newsroom Editorial Pipeline, Incident Backlog Burn-down, Council Planning Applications, Clinical Trial Site Activation and Vulnerability Remediation Queue.

Queueing network

An open queueing network that is solved, not merely drawn.

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

station Triage     { servers: 2; service: 8m }
station Assessment { servers: 4; service: 15m }
station Imaging    { servers: 3; service: 30m; capacity: 8 }
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

This network solves as M/M/2, M/M/4, M/M/3/8 and G/G/3, and the figure's verdict reads "Bottleneck: Triage at ρ = 80% on 2 servers — already inside the 85% target; the network is balanced." The network line reads "Offered 12/h · throughput 11.9/h · blocked 0.11/h (0.9%) · L 14.96 in system · W 75.5m end to end · 4 stations", because Imaging's eight places turn a few arrivals away. Change Assessment to servers: 3 and the verdict becomes "Unstable — Assessment is offered 3 erlangs across 3 servers (ρ = 100%), so its queue grows without bound. 4 servers (1 more) would hold ρ at or under 85%."

Statements

Station keys

Some keys are refused on purpose, kept as a label under the station, and reported as a coerced value so you know the number was not used:

Any other key, such as owner: or note:, is kept and shown under the station (up to six per station).

Rates are written 12/h, 0.2/s, 450/day, 42/min, 18/shift (an 8-hour shift) or 12 per hour. A bare number is per hour. Route probabilities are 0.35, 35%, p: 0.35 or @ 0.35, and default to 1. A trailing whole number other than 0 or 1 is read as part of the station name, so -> Bay 3 is a station called "Bay 3"; quote a name such as "Line 1" to keep its digit. exit, exits, out, output, sink, end, done, depart, departure, leave, leaves, external, world and none all mean "leaves the network" unless a station has that name. Any probability a station does not route away leaves the network, so -> exit lines are documentation. A station named only in a route or an arrivals line is created with one server and no service time, so a half-typed network still draws. A route or arrivals line may shorten a station's name to its start (-> Assess finds "Assessment") as long as only one station begins that way; a station declaration never matches by prefix.

Which model is used

The engine first solves the traffic equations for every station's arrival rate, feedback loops included, then solves each station, then the whole network. For finite-capacity stations, blocking and throughput are solved together until they agree.

What it shows

• Each station is drawn as a waiting-line comb feeding its server circles, laid out left to right in routing order. Outside arrivals enter from the left and exits leave to the right; forward skips arc over the row and feedback loops arc under it, every arrow carrying its probability. Circles are green under 70% utilisation, amber from 70% and red from 85%. The bottleneck carries a bottleneck badge, or saturated if it is unstable. Under each station: λ and ρ; Wq and Lq; W and L; the model (for example M/M/2) with either P(wait), the blocked share for a finite station, or "queue grows without bound"; and any extra keys you wrote.
• The results table lists, per station: Station, Model, c, K (when any station is finite), 1/μ, λ, λ eff (when any station is finite), a (offered load in erlangs), ρ, P(wait), P(block) (when any station is finite), Lq, Wq, L and W.
• The network line reads, for example, "Offered 12/h · throughput 12/h · L 4.31 in system · W 21.6m end to end · 4 stations", adding "blocked …" when a finite buffer turns arrivals away.
• The stability line under it reads "Stable — every station holds ρ below 1…", or explains why waiting times are left blank.
• The verdict is one sentence, coloured green, amber or red.

With no station at all, the figure shows the syntax hint "Describe the network — arrivals 12/h" instead of a verdict. With stations but no arrivals line, every utilisation is 0 and the verdict still names the first station as the bottleneck at "ρ = 0%"; read the No arrivals warning rather than the green sentence.

What it checks

Templates: Mass Vaccination Centre, Container Terminal Night Shift, Fleet Telemetry Ingest, Emergency Department, Contact Centre, Airport Security, High-Street Coffee Shop, Warehouse Picking, Checkout API Call Chain, Bank Branch Counter, Car Service Centre, Passport Office Counter and CI Build Farm.

Spaghetti diagram

A lean motion study in which the walking is measured.

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

Statements

Named colours are blue, red, green, amber, orange, yellow, purple, violet, indigo, teal, cyan, pink, magenta, lime, brown, grey, gray, slate and black. Otherwise colours are assigned in declaration order.

A scenario line written before anything else simply names the first layout (for example scenario "Current layout"); otherwise it is called "Before", and an unnamed second scenario is called "After". The second scenario inherits the first scenario's stations, zones and, if it declares none of its own, its paths, so you restate only what moved. A third scenario line does not get a panel of its own: its content joins the second, and the figure says so. The renderer shrinks the scale to fit, so a 200-metre warehouse and a 6-metre kitchen both come out legible.

What it computes

What it checks

Templates: Nurse Motion Study (Acute Ward), Warehouse Pick Round, Restaurant Kitchen Line, Machine Shop Cell Rebuild, Supermarket Shopper Trip, Office Coffee and Print Runs, Aircraft Turnaround (Stand 14), Hotel Housekeeping Round, Pathology Sample Handling and Construction Site Logistics.

Swimlane process

A cross-functional process diagram with one lane per role or team.

title "Bug triage"
lane "Customer"
lane "Support"
lane "Engineering"

node A "Open ticket"   in Customer   as stadium
node B "Triage"        in Support    as diamond
node C "Fix"           in Engineering
node D "Verify"        in Support
node E "Confirm"       in Customer   as stadium

A -> B
B -> C : "bug"
B -> A : "need info"
C -> D
D -> E

Columns are assigned automatically by longest path, so each handoff moves visibly to the right. Rework loops (an arrow back to an earlier step) are recognised first and drawn as loop-backs, so they never reverse the layout. Two steps in the same lane at the same stage are stacked in one cell. A step placed in a lane that was never declared gets a lane of its own rather than being merged into the first.

Step boxes and lane headings are measured and wrapped to fit. Up to three error and warning findings are printed on the figure (then "…and N more"), with notes for anything the renderer could not draw: labels shortened with an ellipsis (named by id), steps in undeclared lanes ("drawn in a lane of their own, not merged into the first"), and arrows that name an undeclared step ("not drawn"). A shortened label is also listed as an Info finding with its full wording; every check uses the full text. A line longer than 2,000 characters is not read. With nothing to draw, the figure shows "Add a lane and some nodes — lane "Customer", node A "Open" in Customer".

Templates (26) include Bug triage, Procurement, Hiring loop, Content publishing, Loan approval, Incident response, Employee onboarding, Refund request, Supplier onboarding, Enterprise sales cycle, Sepsis Six Pathway, Goods Receipt Price Dispute, Planning Objection Handling, Pharmacy Dispensing Standard Work and Emergency change (ECAB approval and back-out). For a process to the BPMN 2.0 standard with linting and token simulation, use the BPMN studio.

Kanban board

A board of columns and cards with WIP limits.

title "Sprint 47"
column "To do"
  card "Design login screen"   assignee "Eva"   priority high
  card "Wire up SSO"           assignee "Marco" priority medium tags "auth,sso"
column "In progress" wip 2
  card "Build API"             assignee "Sam"   priority urgent
column "Done"
  card "Spec & RFC"            assignee "Eva"

Each column header shows its card count, and its WIP limit when one is declared; the badge turns to the alarm colour when the count exceeds the limit. A card with no priority gets a neutral assignee chip, distinct from priority medium.

Column headers and card titles are measured and wrapped, and every declared tag is drawn as a chip. Lines the engine cannot read are listed in a notice band under the board ("N things in this source are not on the board above:"), up to six at a time, with the form it expected. This matters most for a mistyped column line: the cards under it are drawn in the column above, and the notice says so ("The 2 cards written after it are drawn in "To do", the column declared above it."). A card written before any column line is not on the board, and the notice says that too. With no column at all, the board shows "Add a column — column "To do" / card "Task"".

Templates (21) include Sprint board, Support queue, Hiring pipeline, Editorial calendar, Product launch, Bug board, DevOps board, Classroom projects, Research lab, Personal weekly board, Hospital Estates Maintenance, Investigations Desk, Clinical Trial Site Start-Up and Planned Substation Outage Board. To measure flow across a board over time, use Flow metrics (CFD).

Service Blueprint

A Lynn-Shostack service blueprint with five lanes and the three standard dividers.

title: Restaurant Order
subtitle: Sit-down dining experience

evidence:   Signage | Menu card | Plated food | Bill | Receipt
customer:   Arrives → Reads menu → Orders → Waits → Eats → Pays → Leaves
frontstage: Greet & seat | Present menu | Take order | Serve food | Bill | Farewell
backstage:  Reserve table | Check stock | Cook order | Plate up | Settle till
support:    POS | Inventory DB | Kitchen workflow | Accounting

Every line is key: value, with the colon required (so title: Restaurant Order, not title "…"), and keys are case-insensitive. Steps within a lane are separated by |, → or ->. The lanes are labelled Physical evidence, Customer journey, Frontstage actions, Backstage actions and Support processes. They are always drawn in that order, whatever order you write them in, and a lane you leave out draws as a thin empty track so the column grid stays aligned. When a lane has many steps the figure grows wider rather than squeezing the boxes. Only a # at the start of a line is a comment in this engine.

Templates: Restaurant order, E-commerce checkout, Telehealth visit, Bank account opening, SaaS trial to paid, Customer support ticket, Hotel check-in, Hospital discharge, Airline booking and Developer onboarding.

Quality and improvement

SIPOC

The Six Sigma define-phase scoping diagram, which also checks itself.

title "New patient registration"
scope "Referral received" -> "Confirmation sent to patient"
owner "Access services team"
metric "Referral-to-appointment days" target: 14 actual: 19 unit: days
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)
ctq output "Booked appointment": "Within 14 days of referral receipt"

Statements

Items on a column line are comma-separated; quote an item to keep a comma inside it. A - bulleted line beneath a column adds exactly one item, verbatim. A column opened twice accumulates. Process steps split on ->, →, | or ; when any is present, and on commas otherwise; leading numbering such as 1. or 2) is stripped because the engine numbers the steps itself. Requirements may be written before the column they refer to, and items are matched loosely (case, plurals and partial phrases). better: defaults to lower, because define-phase metrics are mostly times, backlogs and defect counts; write better: higher for yields and acceptance rates.

What it computes

The notes strip reports item counts per column and the number of steps; requirement gaps (each input and output with no stated requirement, named); requirement coverage; the scope check (whether the declared start matches step 1 and the declared end the last step, matched loosely so "Receive referral" and "Referral received" agree); and each metric's variance against target in the declared direction. The figure shows a header strip (title, scope, owner and metric tiles), five aligned columns, the process as a numbered chevron spine (wrapping at five steps a row) and requirement chips under their items.

What it checks

Templates: Blood Bank Unit Issue, Narrowbody Aircraft Turnaround, Clinical Coding to Invoice, Inpatient Discharge, Injection Moulding Cell, Sev-1 Incident Response, Accounts Payable Invoice to Pay, Cold Chain Vaccine Despatch, Undergraduate Enrolment, Offshore Turbine Service, Householder Planning Permission, Omnichannel Apparel Returns and Clinical Trial Site Activation.

Control chart (SPC)

Statistical process control charts whose centre line and limits are computed from your data, never typed in.

title "Fill volume — line 3"
chart xbar-r
unit ml
spec lsl: 495 usl: 505 target: 500
labels: 06:00, 07:00, 08:00
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

Three subgroups are enough to draw, but only just: this example reads "Out of control — 1 of 3 points flagged by rule 1." and carries a rule-window gap, because six of the eight rules need longer runs. A real study wants twenty or more subgroups.

Attribute charts take counts:

chart u
unit "infections per 1,000 catheter-days"
sample n: 1.18 defects: 3
sample n: 1.24 defects: 1
sample n: 0.97 defects: 4

Statements

The chart word is read with case, spaces and punctuation ignored, so xbar-r, XbarR and xbar r are the same; xbarrange and xbarsigma are also accepted. An unrecognised chart word is ignored and the type is inferred. With no chart line, counts give a p chart (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. A mismatched pairing corrects itself: chart i-mr with wide subgroups flattens them into individuals rather than refusing to draw. When subgroup sizes vary, the limits step per point. On the attribute charts (p, np, c and u) a lower limit never goes below zero. Variables charts use the published constants table for subgroups of 2 to 25.

What it computes

• Nelson rules. Each violation is marked on the point that completes the pattern and listed as, for example, "Rule 2 · X̄ at point 14 = 501.20 — 9 points in a row on one side of the centre line". Up to six are listed. Only rule 1 is applied to the range or sigma panel.
• Verdict. "In control — 24 points, no Nelson-rule violations." or "Out of control — 5 of 24 points flagged by rules 1, 2."
• Capability. With specification limits: Cp and Cpk from within-subgroup sigma, Pp and Ppk from overall sigma, and expected parts per million out of specification. Capability quoted for an out-of-control process adds "Quoted from an unstable process, so treat it as provisional."

What it checks

The chart needs at least two subgroups before limits can be estimated. Templates: I-MR (Tablet Press Weight, Stroke Door-to-Needle Time, API p95 Latency, Reactor Peak Exotherm), X̄-R (Bottle Fill Volume, API Assay Concentration, Paint Film Thickness), X̄-S (Moulded Boss Diameter), p (Call Abandon Rate), np (Invoice Error Count), c (Reflow Solder Defects, Body-in-White Weld Defects) and u (Central-Line Infections).

Pareto chart

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

title "Customer complaints — H1 2027 vs H2 2026"
unit complaints
period "H1 2027"
compare "H2 2026"
threshold 80%
other-below 2%
max-bars 12
note "Excludes wholesale accounts"

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

A data line is a label followed by one or two numbers: the charted period, then optionally the comparison period. A line that opens with a quoted label is always data, so quote a label when it would collide with a directive ("Note failures", "Top cover cracked") or ends in digits. Separators are flexible: Late delivery: 412, Late delivery = 412, Late delivery | 412 351 and Late delivery, 412, 351 all work, and a leading - or * bullet is stripped. Repeated labels are added together, so a tally typed off a check sheet works. Numbers accept 1,234 and 1_234; write the two periods separated by a space so 412 210 is never read as 412,210. A trailing % on a value is ignored. Zero, negative and unreadable values are dropped and reported. A line longer than 2,000 characters is not read, and the tally is then treated as incomplete.

What it computes: each category's share; the running cumulative percentage; the vital few (the leading categories up to and including the one whose bar crosses the threshold); the share they carry; and the Pareto ratio sentence, for example "3 of 11 categories (27%) account for 81.2% of 1,040 complaints". With a comparison period it draws ghost bars and a dashed curve accumulated 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. A single category is never folded on its own. The count axis is scaled to the tallest bar so every bar stays readable, while the cumulative curve keeps its own 0–100% axis.

What it checks: a row that could not be read, a value that is not a count, a comparison column that cannot be used (all Error); a zero value and rows discarded past a limit (Gap); labels merged because they repeat, and a directive misread as a data row (Warning). If a size limit is reached, no ratio sentence is written.

Templates: Rail Delay Minutes by Cause, Heat Pump Warranty Claims, Drug Round Interruptions, 30-Day Hospital Readmissions, Injection Moulding Defects, Mobile Crash Signatures, Card Chargeback Reasons, Parcel Network Late Deliveries, First-Year Student Withdrawals, Wind Farm Unplanned Downtime, Council Service Complaints, Retail Stock Loss, Clinical Trial Data Queries and Customer Revenue Concentration.

Fishbone (Ishikawa)

Root-cause diagrams with the problem at the head and categories alternating above and below the backbone.

title "OTIF review"
problem "Late delivery"
category "People"
  cause "Untrained staff"
  cause "Sick days"
category "Process"
  - Manual handoffs
  - No SLAs
category "Equipment"
  Forklift downtime

If no category line is written, four ribs are supplied: People, Process, Equipment and Materials. If no problem line is written, the head reads "Problem". Any other line written before the first category is not on the figure and is reported. The title and problem lines may come anywhere; if either is written twice, the last one is drawn. The canvas widens (by up to 800 px) to hold long causes; a cause or problem too long even for that is shortened with an ellipsis and written out in full in the notice band under the figure, which lists up to five at a time.

Templates include 6 Ms late delivery, Production bug, Low signup conversion, Manufacturing defect rate, Customer churn, Site outage, Slow hiring funnel, Pharmaceutical Batch Deviation, On-Time In-Full Miss, Day-of-Surgery Cancellations, Short-Notice Train Cancellations and Fraud Model Precision Drop. A fishbone pairs naturally with a Pareto chart of how often each cause occurs.

Design structure matrix

Dependency matrices with partitioning, for process sequencing, component coupling, team interfaces or design parameters.

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

Names are matched without regard to case, so "Body-in-white" and "body-in-white" merge, and the first spelling is the one drawn. A name used in a dependency but never declared is appended in order of first mention. Self-dependencies are dropped. Because any line without an arrow declares an element, a mistyped keyword line such as elemnts: Body, Chassis becomes one element with that whole text as its name; the check below catches it. The engine computes the cycles (groups that depend on each other), a partitioned order that pushes as many dependencies as possible below the diagonal, the iteration blocks that must be worked together, and the count of feedback marks before and after, for example "23 feedback marks reduced to 6 across 2 iteration blocks". The figure shows the declared and partitioned matrices side by side, with iteration blocks boxed and fan-in and fan-out counts on the right. It checks for a line whose first word is one letter away from a declaration keyword, such as elemnts: … or mod process, and so was not read as the declaration you meant (Warning); self-dependencies, which are dropped (Warning); and a size limit reached (Gap), in which case no sequencing verdict is given.

Templates: EV Vehicle Programme, Checkout Service Coupling, Hospital EHR Go-Live, Payments Team Topology, Goods-to-Person Retrofit, MSc Programme Validation, Offshore Wind Farm Delivery, Benefit Claim Service Redesign, Retail Recommender Platform, Pre-Training Parameter Coupling, Aircraft Cabin Retrofit, Payments Monolith Decomposition, Marketing Authorisation Dossier and an application landscape interface matrix.

Risk, safety and reliability

Fault tree (FTA)

Quantitative fault-tree analysis in IEC 61025 notation, computed exactly.

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
house maint "Train A out for maintenance" off

Statements

The keyword form also works without parentheses: OR a, b, c. A gate keeps its first 12 distinct inputs; the rest are counted and reported, and the tree is then treated as truncated. An unknown operator is computed and drawn as OR with a Warning, so the branch keeps drawing. XOR, NOT, NAND and NOR are also computed as OR, and are reported as an Error: they make the tree non-coherent, and the picture would then be defensible while the arithmetic under it describes a different tree.

Attributes may be written key=value or key: value, in any order.

What it computes

Each node's probability is printed beneath it. A gate used in two places is drawn once and referenced elsewhere by a transfer triangle. The panel's first line reads "Exact top-event probability … · rare-event sum ΣP(cut set) …", followed by how far the usual approximation overstates this tree. When a size limit cut part of the tree (including a gate with more than 12 inputs), the panel opens with "This tree was truncated — no top-event probability is stated.", the top tile reads "Top event probability (withheld)" with "—", and the cut-set and single-point tiles show "≥" and "(partial)".

When the tree cannot be analysed. In four cases nothing is computed, and the figure is replaced by an error card with the title, the reason and "Fix the structure and the tree redraws — nothing else was lost."

What it checks

Templates: Metro Signalling Loss, Vaccine Cold Chain Excursion, Offshore Turbine Unavailability, Reactor Decay Heat Removal, Triple Hydraulic Loss, Data Centre Power to IT Load, Piped Medical Oxygen, Total Loss of Vehicle Braking, Blowout Preventer on Demand, Wrong-Side Signalling Failure, AV Pedestrian Detection, Regional Cloud API Outage and Batch Reactor Overpressure.

Bowtie risk

Threats on the left, the top event at the knot, consequences on the right, and preventive and recovery barriers on every path, with residual risk computed.

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" pfd: 0.15
  barrier "Emergency response" 50%
}

Statements

Braces are optional: barrier attaches to the latest threat or consequence, escalation to the latest barrier and control to the latest escalation. ; and new lines both end a statement. A bare trailing number such as barrier "Deluge" 60% is the statement's natural quantity, but only when the line has no key: value pairs. Values accept 0.8, 80% or 80.

What it computes

Line weight shows each path's share of the risk, and barriers are coloured by effectiveness.

Defaults and caps. A threat with no likelihood is assumed 0.1, a consequence with no severity 3, and a barrier with no effectiveness 0.5. Each assumption is listed. Effectiveness is capped at 0.99, because a barrier that cannot fail does not exist.

When any part of the bowtie was not read (a statement the engine does not know, an orphaned statement, a size limit or an unclosed quotation mark), the Top event, Residual risk and Risk reduction tiles show "—" with "(withheld)", and Barriers is marked "(partial)" with "≥" counts. Otherwise the five tiles are Top event (with the inherent frequency beneath), Residual risk (with the inherent risk), Risk reduction (with the threat-side effect), Barriers (with the threat and consequence counts) and Dominant threat (with its share of the top event). A barrier criticality ranking (up to six) and up to seven findings are printed along the bottom. Templates: LPG Storage Loss of Containment, Wrong-Dose Medication on an Acute Ward, Runway Incursion, Dropped Object from a Drilling Derrick, Ransomware Encryption of Production Systems, Listeria in Chilled Ready Meals, Fall from Height on Steel Erection, Unauthorised Trading, Embankment Dam Overtopping, Customer Data Exfiltration from Cloud Storage, Unsafe LLM Response, Signal Passed at Danger, Ransomware on a Hospital Network and Undeclared Allergen in a Ready Meal.

Reliability block diagram

System reliability, MTTF and availability, computed from series, parallel, k-out-of-n and standby arrangements.

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 }
}

In this example only the grid states an mttr, so availability is computed with the other seven blocks counted as always available, and the figure reports that as an Availability partial gap. Give every block an mttr for a complete availability figure.

Blocks

block <id> ["Label"] key: value … (component, item and unit also work), with attributes in any order separated by spaces, commas or semicolons. The label falls back to the id. title "…" sets the title and mission 8760h (or mission time) the mission time; only the first of each is used. Durations take s, min, h (the default), d, w, mo or y, so 4000h, 18 months and 2.5 y all work.

Every form is converted to a constant failure rate, which assumes an exponential life (the standard RBD assumption).

Arrangements

Separators ;, , and new lines all delimit members. A name referenced but never declared becomes an assumed perfect block, drawn dashed. A file with blocks and no arrangement is treated as one long series.

What it computes

What it checks

Templates: Earth Observation Payload Chain, Potable Water Pumping Station, Radiotherapy Treatment Chain, Data-Centre Power Train, Fly-by-Wire Pitch Channel, Subsea Multiphase Boosting Station, GEO Ku-Band Payload, Hospital Medical Oxygen Supply, 25 kV Rail Traction Chain, Offshore Wind Turbine Drivetrain, Dual-Carrier WAN Path, Autonomous Vehicle Perception Chain, Municipal Water Treatment Works, and two availability models for cloud APIs.

Attack tree

Threat modelling with the attacker's cheapest path rolled up the tree.

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

Lines starting with # or // are comments, and keywords are case-insensitive. With no goal, the figure shows "Add a goal — goal G "Steal credentials"". Leaf cost, skill and detect appear as chips. Cost rolls up the tree: an AND adds its children's costs and an OR takes the cheapest, so the chip on the goal is the price of the cheapest way in. When a child has no cost, the chip says how many steps the number leaves out.

Diagram Intelligence adds the number of attack scenarios, the cheapest attack and defender choke points (steps present in every attack scenario). On a very large tree the scenario enumeration is cut short and Intelligence says the scenarios and choke points are approximate. Templates include Steal user credentials, Cloud account takeover, Data exfiltration, Ransomware, Account Takeover, Data-Centre Break-in, Web App Compromise, IoT Device Hijack, Card-Not-Present Fraud and Water Treatment Dosing Attack. For software threat models, see also Software and architecture engines.

Automation, control and process engineering

Ladder logic (PLC)

IEC 61131-3 ladder diagrams, solved for one scan exactly as a controller runs them.

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

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

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

rung "Jam alarm"
--| |--T_Jam----( )--Jam_Alarm

This program solves as three rungs over ten tags, all three true in the declared state, with no findings. Note the rung "Jam alarm" line: an instruction line written while a rung is open joins that rung, so without it the one-line rung would be drawn in series at the end of "Jam watchdog". A one-line rung stands on its own only when no rung block is open, for example at the top of the program.

Statements

Instructions

The contacts can also be drawn with pipes, which is how most ladder printouts look:

--| |--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

preset: also accepts pre:, pt: and sp:; accum: accepts acc:, et:, cv: and count:. Two bare numbers after the tag are read as preset then accumulated (ton T_Jam 6 8). A trailing s, ms or min is kept as the display unit. The tag always follows its symbol, and may be quoted when it contains spaces. A whole rung fits on one line: --| |--Start_PB----|/|--Jam----( )--Motor.

A timer or counter named T_Jam provides T_Jam.EN (or .CU and .CD), T_Jam.TT and T_Jam.DN, and T_Jam on its own means the done bit. A/B is read as A.B. Tag names are case-insensitive; the first spelling is the one drawn.

How it solves

Tags start from the declared state; everything else is false. Each rung is evaluated left to right: series is AND, parallel legs are OR, a normally closed contact inverts, and an output passes power through, so two coils in series both fire. ote writes every scan; a latch survives its own rung going false; when a set and a reset are both powered in one scan, the last executed wins. Timers and counters resolve their done bits from the declared accumulated value against the preset (IEC rules), and time does not advance during the scan. A coil written on an earlier rung is visible to a later one; to show a seal-in holding, declare the coil in state as it was at the end of the previous scan. Energised rails, contacts and coils are highlighted.

What it flags

When there are none, the strip says so: no duplicate destinations, no unwritten tags, every rung drives an output. Templates: Motor Start/Stop Seal-In, Signalled Junction Sequence, Conveyor Jam Watchdog, Tank Fill on Level Switches, Two-Hand Press Anti-Tie-Down, Roller Door Open/Close Interlock, Packaging Line Fill and Cap, Duplex Pump Duty Alternation, Lift Hall Call and Door Dwell, and Batch Mixer Charge and Soak.

GRAFCET / SFC

IEC 60848 GRAFCET and IEC 61131-3 sequential function charts, checked against the rules every hand-drawn chart breaks.

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"
  D 5s "Alarm horn" if level_low
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

Statements

In links, a step is 3, s3 or step 3; a transition is t3, tr3 or transition 3. Nodes referenced but not declared are created, so you can write the spine first. Receptivities pass IEC notation through: . is AND, + is OR and /x is NOT. A transition with no receptivity is drawn =1. A link line may be prefixed with or or alternative, or and, simultaneous or parallel; the engine checks that word against the structure. Links that run back up the chart are routed down the left rail with an arrowhead.

What it checks

Templates: CIP Sequence (10 000 L Fermenter), Rotary Bottling Filler, Lift Car Door Interlock, CNC Automatic Tool Change, Batch Reactor Heat-Hold-Cool, Car Park Entry Barrier, Robot Pick-and-Place Cell, Rollover Car Wash Gantry, Signalised T-Junction Stages, Commercial Dishwasher Cycle and Cleanroom Material Airlock.

P&ID (chemical engineering)

Process and instrumentation diagrams placed on a grid.

title "Continuous distillation"
eq tank      T1   "Feed tank"     at (1,1)
eq pump      P1   "Feed pump"     at (3,1)
eq column    COL1 "Distillation"  at (5,1)
eq exchanger E1   "Reboiler"      at (7,3)
eq tank      T2   "Bottoms"       at (5,4)
instrument TI 101 at (6,0.2)
instrument LC 201 at (6,1.8)
instrument PSHH 12-101 at (3,0.2)
line T1 P1 stream "feed"
line P1 COL1 stream "feed (pumped)"
line COL1 T2 stream "bottoms"
line COL1 E1 stream "reboil vapor"

This layout draws with no notices. Put the reboiler at (5,3), directly between the column and the bottoms tank, and the figure reports "The bottoms line is drawn through E1; it does not connect to it."; put a balloon on the column's own coordinates and it reports "Balloon TI 101 is drawn on top of COL1 — both are on the figure, one over the other."

Lines starting with # or // are comments. Equipment kinds are matched without regard to case. The notice band under the drawing lists, up to six at a time (then "…and N more."), anything the engine could not draw cleanly.

Templates: Water Treatment Plant, Brewhouse Wort Line, Food Waste Anaerobic Digester, Continuous distillation, CSTR with cooling and Shell-and-tube heat exchanger.

Related engines documented on other pages

The Studio library's Flow systems and Risk & reliability groups also hold engines that are documented in full elsewhere. In Flow systems: Data flow diagram and Event storming (Software and architecture engines); User story map, Business model canvas, Customer journey map, Decision matrix (weighted / Pugh), Gantt & critical path and Roadmap (Business, strategy and planning engines). In Risk & reliability: Decision tree and Risk matrix (Business, strategy and planning engines). Use the Risk matrix for a scored likelihood × impact register and heat map; use a bowtie or fault tree on this page when you need the barriers or the failure logic computed.

Two schedule engines sit closest to this family:

Choosing between close cousins

Limits at a glance

These limits apply per figure. Past a limit, the engine keeps what it read, says what it did not, and withholds whole-figure verdicts.

Every engine on this page also has a source-size budget in the Studio: 60,000 bytes (about 58.6 KB) of source, or 150,000 bytes (about 146.5 KB) for the control chart and the CFD, whose sources grow one row per observation. Past it the figure is not drawn and you see "Source is … — past the … safe-rendering budget for …", with three options: split the work into smaller figures, render it on the server with the render API, or trim the source. See Troubleshooting and FAQ.

Tips

• Start from a template. Every engine here has a set of real-world templates. Open one, then replace its numbers with yours: the structure is already right.
• Write the inputs, never the totals. If you find yourself wanting to type a total, a limit, a probability or a verdict, that is the number the engine computes. Type the facts it is computed from.
• Give units every time. Write 8m, 12/h and 4000h rather than bare numbers. The queueing network reports every unitless value, and in the value stream map a bare number is seconds.
• Mark the waiting. 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 the before-and-after forms. The spaghetti scenario and the Pareto compare column turn one figure into an argument with the difference computed, and the queueing target turns the verdict into a server count you can act on.
• State the takt. Without takt, or demand with available, a value stream map cannot say which step is over takt.
• Declare the previous scan. In ladder logic, a seal-in only holds if the coil is in state as it was at the end of the last scan.
• Mark the deliberate ends. In GRAFCET, mark terminal steps final so the dead-end check does not report them.
• State what the engine would otherwise assume. A queueing network with no target line, a fault tree with rates but no mission line, any RBD with no mission line, and a control chart shorter than 15 points with all eight rules on each carry a Gap in Document status, because a number was chosen for you. Write target 85%, mission 8760h or rules: 1,5 and the gap clears.
• Read the notes before you present. A note such as "1 threat likelihood assumed 0.1" on a bowtie, or "Timings assumed" in Diagram Intelligence, is the line a reviewer will ask about.
• Name a version before a what-if. Open the diagram timeline (Version history…, ⇧⌘H) to name the current version, then change the inputs. See Version history and undo.
• Keep one figure per engine you try. Picking a different engine replaces the figure's source with that engine's starter, so start a New figure (⌥⌘N) for each comparison and keep both.

Limits and known constraints

• The Studio computes; it does not animate. These engines draw their results into a static figure. Animated token flow is in Weave and the BPMN studio.
• The queueing network is a steady-state, open-network model. It treats arrivals as Poisson unless a station states a cva, solves long-run averages, and uses the Allen–Cunneen approximation whenever variability is stated on a multi-server station or on arrivals. A finite-capacity station is always solved as M/M/c/K, ignoring any cv. A station at exactly ρ = 100% counts as unstable. It does not model priorities, schedules that change over the day, or closed networks, and at most 14 stations are solved.
• Reliability block diagrams assume constant failure rates (an exponential life), so they do not substitute for a Weibull analysis of wear-out. Repair is used only for steady-state availability.
• Bowtie barriers are treated as independent. Common-cause failure is not modelled, and each consequence is credited the full top-event frequency. Both are reported when they matter.
• Fault trees must be coherent for cut sets to be meaningful. XOR, NOT, NAND and NOR are accepted but computed as OR and reported as errors. A tree with more than 64 distinct basic events is not analysed at all, and a very tangled tree that exhausts the exact method falls back to a labelled upper bound.
• Ladder logic solves one scan. Timers and counters do not advance; their state comes from the accum you declare.
• The CFD's cycle time is approximate, from Little's Law over the window, and assumes a reasonably stable system. The value stream map converts count-only inventories to time only when takt is known.
• P&ID is a drawing aid, not a process simulator. It has one generic valve symbol (gate, ball, check and control valves are not distinguished), lines are routed automatically between equipment, and you place items by grid coordinates.
• Swimlane, Kanban, Fishbone, Attack tree, P&ID and Service Blueprint accept comments only on lines of their own (and Service Blueprint only with #).
• Direct click-to-edit tools are limited here. Click a label on the figure to rename it (Enter saves, Esc cancels); the new text is written straight into your source. When the old label cannot be located in the source safely, the rename is handed to AI instead, and any other change goes through Ask the flowss Studio Agent… in the same popover. Both of those need AI on your plan. Everything else is edited in the code. See Data, timeline, TikZ and the diagram tools.

Troubleshooting

Empty-figure hints by engine

Fishbone, Service Blueprint and P&ID have no hint: an empty fishbone draws the four default ribs around a "Problem" head, an empty blueprint draws five empty lanes, and an empty P&ID draws an empty grid.

Related pages

• Flow-systems analysis in Studio
• Choosing an engine
• The full engine catalogue
• Business, strategy and planning engines
• Software and architecture engines
• Charts and data-visualisation engines
• The Studio editor
• Starting from a template
• Importing and converting
• BPMN and Weave
• The Flow layer
• Exporting your work
• Embedding and the render API
• Use cases by role