3 min read

A First Model

This page walks through the smallest meaningful Primmel model line by line. By the end, you will recognize every construct that appears in larger real-world models.

You can follow along

The complete file is in the examples corpus: 01-minimal-model.prl. Open it in another tab.

The header

Every model begins with three things: a root, a version, and a metadata block.

root HelloWorld

version "v1.0.0-dev1"

metadata {
  title "Minimal Primmel model"
  schema "Primmel 0.1"
  edition "1"
  author "Primmel project"
  shortname "HelloWorld"
  namespace "HelloWorld"
}
Field Meaning
root HelloWorld Names the top-level canvas — the entry point of the model.
version "v1.0.0-dev1" Semantic version of the model itself.
metadata.schema The DSL schema identifier. "Primmel 0.1" is the current value.
metadata.namespace The model’s namespace. Used when other models import this model’s elements with the Namespace#ElementID pattern (see the implementation package).

Roles

Roles describe who does the work. A role has an ID and a human-readable name.

role Org {
  name "Organization"
}

role Greeter {
  name "Greeter"
}

Org is a conventional ID for the generic organization-wide role (matching real-world models). Greeter is a more specific role that we will assign to a process below.

Events

A process flow has a beginning and an end. Both are events:

start_event Start1 { }
end_event   End1   { }

A model with multiple canvas diagrams has multiple start_events — one per canvas. This is normal: each diagram needs its own entry point.

Processes

A process is a unit of work performed by a role:

process Greet {
  name "Greet the world"
  actor Greeter
}

The actor clause binds the process to a role. At evaluation time, this is how tooling determines whose responsibility the step is.

A real-world process usually also has:

  • modality SHALL / SHOULD / MAY — the compliance weight of the step.
  • validate_provision { ... } — the provisions this process must satisfy. See example 04.
  • reference_data_registry { ... } — data registries this process reads from.
  • output { ... } — data registries this process writes to.

The canvas

A canvas is a container that lays out a flow. The header named HelloWorld as the root; now we define it:

canvas Root {
  elements {
    Start1 { x 0  y 0 }
    Greet  { x 0  y 100 }
    End1   { x 0  y 200 }
  }
  process_flow {
    Edge1 { from Start1  to Greet }
    Edge2 { from Greet   to End1 }
  }
  data { }
}

A canvas has three blocks:

Block Purpose
elements { ... } The events, processes, gateways, and timers on this diagram, each with x/y coordinates for visual layout.
process_flow { ... } The directed edges between elements. Each Edge has a from and a to.
data { ... } The data registries visible on this diagram, with x/y coordinates.

The Root canvas is the top-level flow. A model with multiple canvases names them like pages (OrderFlow, QualityCheckFlow, SupplierReviewFlow) — see example 03 and the implementation package.

What this model lacks

The minimal model is correct Primmel, but it does not exercise:

  • Data — no class, enum, or data_registry. Added in example 02.
  • Compliance — no provision or reference. Added in example 04.
  • Branching — no exclusive_gateway. Added in example 03.
  • Mapping — no map_profile or .prm file. Added in the implementation package.

That is what the rest of the example corpus adds, one primitive at a time.

Next

Open the examples index and pick the next file in the reading order. Each example introduces one new primitive group, with the relevant lines highlighted and explained.