PML: the process modelling language
Every model in Twiggy Modeller is plain text in PML. The app draws it, the AI reads and writes it, and you can read, diff and keep it like code. This page is the reference.
Why a text language
A diagram file is thousands of shapes and coordinates. A PML model is a few hundred words: what exists (declarations) and how work connects (flow lines). Layout is automatic, so the same text always draws the same, readable diagram. That makes models small enough for an AI to read and change exactly, easy to compare between versions, and portable: a package of PML files imports back whole, and flows export to BPMN 2.0.
Process maps
A process map (@landscape) is what the organisation does: enterprise processes at the top and process areas inside them, nested by one tab per level. An area with areas inside it is shown as a process chain; an area with nothing inside it is one process, and ref= names the flow that models it. a -- b connects two areas side by side. Areas carry only owner and description.
@landscape "Twiggy Bank" status=draft
area acquire_customers "Acquire customers"
area originate_loans "Originate loans"
owner Head of SME Lending
area submit_application "Submit a loan application" ref=submit-sme-loan-application
area decide_loan "Decide on the SME loan" ref=decide-sme-loan
area collect_and_recover "Collect and recover"
area collect_payments "Collect payments" ref=collect-loan-repayments
area manage_arrears "Manage arrears" ref=manage-arrears
submit_application -- decide_loan
collect_payments -- manage_arrearsProcess flows
A process flow (@process) starts with a header: its level (L3 a process, L4 a sub-process), name, id=, parent= and status=. Right under it, the scope card: purpose, owner, customer, and any kpi and sla for the process as a whole. Everything else (triggers, outcomes, roles, systems, risks) is read from the flow, so it can never disagree with it.
@process L3 "Manage arrears" id=manage-arrears parent=twiggy-bank status=draft
purpose "Help customers in arrears catch up, fairly."
owner Head of Collections
customer "Borrowers who miss a repayment"
kpi Arrears cured within 30 days
event repayment_missed "Repayment missed" inbound from=collect-loan-repayments.repayment_missed
event hardship_agreed "Hardship plan agreed"
event referred_to_recoveries "Referred to recoveries"
actor collections "Collections" role=collections
task(user) contact_customer "Contact customer about arrears"
app crm
requirement req_hardship_contact
risk r_unfair_treatment
control c_hardship_review
sla Within 2 business days
task(user) agree_hardship_plan? "Agree hardship plan"
rule hardship_policy
exception "Customer in hospital" instead="A team leader agrees a 30-day pause by phone" knows="Collections team leader"
(repayment_missed) --> contact_customer
case can_pay "Can the customer catch up?" after contact_customer:
yes* "With a plan" --> agree_hardship_plan --> (hardship_agreed)
no --> (referred_to_recoveries)Events and hand-offs
event id "Label" declares a start or end; which it is follows from the flow. A hand-off is an event marked inbound or outbound, linked to the event it meets in another process with from= or to= process.event. Hand-offs are how one process leads to the next across the map, in process chains, in presentations and in the procedure guide.
Lanes and steps
actor id "Label" [role=…]is a lane: who does the work. Steps are indented under their lane.task(user|service|manual) id "Label": work done by a person with a system, by a system, or by hand. Name it as work done: a verb and an object.subprocess id "Label" ref=process-id: a step detailed in a flow of its own, one level down.
Decisions
case id "Question?" after step:with indented arms (yes* --> …,no --> …,else): exactly one path.*marks the usual one.split id "Label":: all paths, in parallel.split id "Question?" any:: every path whose condition holds.join id --> …: continues once the paths that started are done.
Flow lines and messages
a --> b --> (done) is the order of work; events are written in brackets. (event) ~~> lane is a message: a notification, not a hand-over of the work. Lines may carry a label in quotes.
Step properties
Indented under a step, one per line:
description "…"what it is;how "1. …\n2. …"how it's done, the instructions the procedure guide and presentation mode show;note "…".app,rule,risk,control,requirement: an id from a register, repeatable.kpi,sla,owner; your workspace's own properties asx_….exception "the case" instead="what is done" knows="who knows how" [could_go]: a case the usual way doesn't fit, and the workaround (see modelling real-world complexity).
Registers: systems, risks, controls, rules
Shared items live once, in registers, and steps refer to them by id, so one risk or system is used everywhere and changed in one place. In the app they are managed as registers with fields, hierarchy (categories of risks, for example), relations and history; in text they read as a library:
@library "Bank shared assets" id=bank-assets
app_registry {
crm "CRM" "Customer records, contact history and cases."
}
risk_register {
r_unfair_treatment "Unfair treatment" rating=high "A customer in hardship isn't treated fairly."
}
control_library {
c_hardship_review "Hardship plan review" "A team leader reviews every hardship plan before it is agreed."
}
rule_library {
hardship_policy "Hardship plans" "Up to 3 months of reduced repayments for a temporary drop in income."
}
requirement_register {
req_hardship_contact "Arrears contact" "Contact a customer in arrears within 2 business days."
}Unconfirmed (?)
A ? after an id (task(user) agree_hardship_plan? "…", or a whole lane, actor people_team?) marks something inferred and not yet confirmed by the people who do the work. The AI marks what it assumes; the sign-off page lists every ? for the expert to confirm or correct.
Try it
Open the free demo and explore the models. In your own workspace, Download a folder or the whole workspace as a package to get every model as a .pml file; admins can also turn on the source view (Administration › Properties › Model text) to edit PML beside the diagram. The modelling guide explains how to model top down; Compare shows how Twiggy relates to BPMN tools.