TwiggyModellerSign in

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_arrears

Process 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 as x_….
  • 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.