Declarative process model

What is a declarative process model?

A declarative process model describes a process through rules about what must, may, or must not happen, instead of drawing one fixed sequence of steps. Any way of working is allowed as long as it breaks none of the rules.

This fits flexible work where many orderings are valid but a few conditions always hold. A doctor treating a patient, a caseworker handling a file, or a support team resolving an unusual ticket rarely follow one script, yet some things are non-negotiable.

Declare is the best known language for this style. It was introduced by Maja Pesic and Wil van der Aalst in the mid-2000s, and it defines each rule as a temporal constraint over the activities in a process.

Rules instead of a fixed path

A procedural model, like a flowchart or a BPMN diagram, says which step can follow which. A declarative model says something looser, for example: if activity A happens, B must happen somewhere later.

The rules together fence in the allowed behaviour. Add more rules and fewer sequences stay valid. Leave a rule out and the model says nothing about that activity, which may be deliberate or simply a gap.

A handful of common rule types show how it works:

• Response. Every time A happens, B must happen somewhere after it. After "complaint received" there has to be a later "complaint answered", though not necessarily as the next step.

• Precedence. B may only happen if A happened earlier. "Pay invoice" requires that "approve invoice" came first.

• Coexistence. If either A or B happens, the other must happen too, in any order.

• Not co-existence. A and B may never appear in the same case. A pregnancy test and a patient recorded as male should not occur together.

One subtlety trips people up. A response rule counts as satisfied when its trigger never fires: if A never happens, the rule "A leads to B" is technically met. This is called vacuous satisfaction, and it means a rule can look fully respected simply because nobody ever started it.

Example: a hospital care pathway

A ward gives clinicians wide freedom in what order they do things, because every patient is different. A declarative model captures only the hard rules: after "start medication" there must later be "review", "surgery" requires a prior "consent", and "pregnancy test" cannot appear for a patient classified as male.

Every other clinically valid order is allowed. Drawing the same freedom as a procedural flowchart would need every possible route on one diagram, which quickly becomes unreadable. The constraints do not replace clinical judgement; they record the conditions that must hold whatever route the care takes.

Declarative versus procedural models

Petri nets and BPMN describe the paths a process may take, step by step. They are strong for stable, repeatable workflows where you want to spell out routing and orchestration.

Declarative models describe the edges of allowed behaviour and leave the middle open. They fit compliance rules, knowledge work, and processes where forcing one path would be wrong. Some teams use a hybrid: a procedural backbone for the predictable part, plus declarative rules for exceptions and obligations that must hold everywhere.

Beyond Declare, DCR graphs (Dynamic Condition Response graphs) are another declarative notation. They use a smaller, fixed set of relations, which makes them easier to learn and to execute directly, where Declare leans on the full generality of temporal logic.

Checking whether reality followed the rules

Because the rules are precise, you can take a real event log and test each case against each constraint. This is conformance checking: for every rule you can count how often it was triggered, how often it was met, and which cases broke it.

Report more than a single percentage. A response rule that is 100 percent respected means little if its trigger almost never fired. Show the number of activations and name the cases that actually violated a rule, so a high score cannot hide a rule nobody ever exercised.

What to watch out for with declarative models

Rules can clash. Several constraints together can make some behaviour impossible or restrict it in ways nobody intended. Use consistency checks where your tooling supports them.

Large rule sets get hard to read. Dozens of constraints on one diagram lose the plot. Group them by goal, drop redundant ones, and show example cases that pass and fail.

Discovered rules are not automatically good rules. Tools can mine constraints straight from a log, but a pattern that always held in the past may be a quirk of the data, not a policy you want to enforce. Let people who know the process decide which rules are real.