Purpose Chains: Making Intent Executable
Most organisations already know why they want to change. The reasons live on a slide: a driver, an ambition, a strategy, a list of initiatives. The slide is honest about intent and completely disconnected from anything that runs. Somewhere downstream a team translates it into tickets, the tickets into code, and by the time the software exists nobody can point at a line of it and say which sentence on the slide it serves.
A purpose chain is the attempt to close that gap without flattening it. Instead of intent on one artefact and behaviour on another, you model a single chain that runs from the reason an organisation is moving all the way down to the thing that actually executes - and you make the lower end genuinely executable, not a diagram of executable things. This piece is about how that chain is shaped in Priostack, why an executable chain is worth more than a well-drawn one, and why a constraint compiled into structure beats a rule everyone is asked to remember.
The vocabulary is deliberately borrowed from ArchiMate 4.0's motivation and strategy layers, because those layers already name the links most tools leave implicit. The difference is what happens at the bottom of the chain.
Contents
1. The realisation chain
The chain has five links, and each one realises the one above it. The word matters: realisation is a specific relationship, not a loose association. A lower element exists in order to make a higher element real.
Driver why the organisation is moving at all
│ realised by
Goal the measurable end-state it wants
│ realised by
Outcome a concrete result that counts as progress
│ realised by
Course of Action the approach chosen to get there
│ realised by
Capability the ability to actually do it - and runRead top to bottom it is a translation: a Driver such as "field incidents cost too much to resolve" becomes a Goal ("cut mean resolution time"), which becomes an Outcome ("technicians arrive with the right part"), which becomes a Course of Action ("dispatch from live device state instead of a call queue"), which becomes a Capability - the ability to sense a device, decide a dispatch, and act on it.
Read bottom to top it is an accountability trace. Point at any running Capability and you can walk back up and answer "why does this exist" with a Driver, not a shrug. That upward walk is the part a slide can never give you, because a slide has no edge connecting the initiative box to the software that shipped.
2. What a Capability actually declares
A Capability is where intent stops being abstract, so it is the link that has to carry the most honest information. In Priostack a Capability declares, up front, what class of side effect it can have on the world. A user - or an operator granting it to a fleet - sees that class before anything is granted, not after something has already happened.
The side-effect classes are deliberately blunt:
- read_only - it observes and reports, changes nothing.
- reversible_local - it changes something on the device that can be undone.
- external_communication - it sends something out: a message, a call, a request to another system.
- financial_commitment - it can spend or commit money.
- account_security - it can touch credentials, access, or identity.
- high_stakes - it can do something that is hard or impossible to walk back.
The point of naming the side effect on the Capability itself is that intent and consequence travel together down the chain. A Course of Action that sounds harmless ("notify the customer") inherits a very specific truth once you look at the Capability realising it: this is external_communication, it leaves the building, and it should be treated accordingly. The slide version hides that; the chain forces it into view.
3. Models, not code, at the bottom
The surprising part, for anyone used to "and then the engineers build it", is that a third-party Priostack app ships a bundle of models, not a binary of code. A Capability is realised by:
- ArchiMate 4.0 for structure - what the parts are and how they relate.
- BPMN 2.0 for what it does, run natively as Petri nets rather than interpreted as a flowchart.
- CMMN 1.1 for cases - work that is guided rather than fully pre-scripted.
- DMN 1.3 for decisions - the rules pulled out of the process so they can be read and changed on their own.
- Camel YAML for integrations - the routes that carry data to and from other systems, built on Enterprise Integration Patterns.
- IFML for views - what a person sees and touches.
The single engine underneath, Qubit, runs BPMN, DMN and CMMN natively. That is what lets the bottom of the purpose chain be executable directly: the Course of Action is not compiled into some other language and lost, it is the running behaviour. When a model changes, the behaviour changes, because they are the same object.
Not everything intent needs can be said in a model, and it is important to be plain about that. A camera, a set of keys, the act of placing a phone call - a model cannot express these. So when a Capability needs one, the surrounding app provides it as a permissioned native feature, granted with a stated purpose and an expiry, and enforced at the moment it is invoked rather than waved through at install time. The chain stays honest at its edge: the modelled part is modelled, the physical part is a named, expiring grant, and nothing pretends to be the other.
4. A constraint compiled to a guard
The strongest argument for an executable chain shows up where a constraint meets the physical world. Consider an edge device - a controller in the field, running Skopin, Priostack's Linux edge OS. Skopin runs the app's models and policies on the device itself, receives its deployments over its own protocol, and reports the device's real state back. In an ArchiMate model, a technology-layer Node is not a stand-in for that device; it can be the real device running Skopin.
On a control device Skopin runs a fast, repeating scan cycle - on the order of 120 milliseconds. Sensor readings enter that cycle as read-only guards. Now the important move: an interlock like "the heater may never energise while the tank is empty" is not written as a rule a process step checks and a technician remembers. It is expressed in the structure of the Petri net so that the unsafe combination has no reachable state at all.
Rule-as-reminder Constraint-as-structure
───────────────── ───────────────────────
step: energise heater net has no marking where
if tank_empty: abort (heater=on ∧ tank=empty)
can ever be reached
checked at runtime, the transition simply
one forgotten path = a burn cannot fire - by constructionThis is the difference between safety checked and safety by construction. A checked rule is only as good as the completeness of the checking: miss one path, one race, one operator override, and the bad state is reachable. A structural guard is a property of the net's semantics - the transition that would enter the unsafe state has no firing, so no code path, forgotten or otherwise, can reach it. The constraint from the top of the chain has become geometry at the bottom.
Reflex, the reference edge hardware, is where such a Node anchors in the physical world: a small Linux board with Wi-Fi, 4G, eSIM, microSD, IEEE 802.15.4 and expansion for Z-Wave, XBee and LoRa. The family framing is worth keeping: Priostack orchestrates, Skopin executes at the edge, Reflex anchors it in the physical world. The purpose chain runs across all three without changing meaning.
5. The same chain on every surface
Because Qubit is the one engine under the app, the API and the edge, the same model means the same thing everywhere it runs. The identical app runs as a native mobile app, where an Android or iOS renderer draws the IFML views; as a PWA in the browser, where a JavaScript renderer draws the same views; and on edge devices via Skopin.
The split that keeps this honest is between view state and durable state:
- Interactive view state - what a screen is showing, a half-filled form - is local to the device and works offline.
- Durable process, decision and case state - the canonical record of where the work actually is - lives on the engine.
So the Course of Action does not fork into a mobile version and a server version that slowly disagree. There is one net, one set of decisions, one case model. A technician's phone in a basement with no signal can carry the view; the engine remains the single source of truth for the process itself. The purpose chain is not re-implemented per surface, which is the usual place intent quietly gets lost.
6. Where the chain meets a person
An executable Capability could, in principle, just act. The autonomy model is the governor that decides how much of that a Capability is allowed to do without a human in the loop, expressed as a ladder:
| Level | Behaviour |
|---|---|
| Suggest (0) | proposes only; you do everything |
| Prepare (1) | drafts the action; you send it |
| Confirm (2) | asks before each action |
| Delegated (3) | acts within limits, tells you after |
| Continuous (4) | runs on its own; you can stop it |
Two rules make this safe to reason about. First, effective autonomy is the lower of what an app declares it can do and what a user actually grants. An app cannot promote itself past the ceiling a person set. Second, any action whose Capability is classed financial_commitment or account_security is capped at Confirm, no matter what the app declares - the ability to spend your money or touch your access always stops to ask.
Notice how this reads back up the chain. The side-effect class declared on the Capability in section 2 is exactly what the autonomy governor keys on. Intent, consequence and permission are the same thread pulled taut, not three policies maintained in three places that have to be kept in agreement by hand.
7. Honest limits
A chain like this is worth having only if you are clear about what it does not do.
- It does not make the strategy correct. If the Driver is wrong or the Goal is badly chosen, the chain will faithfully execute a bad idea. Realisation guarantees traceability, not wisdom.
- The models still have to be right. A Petri net that omits a hazard makes nothing unreachable. Structural safety is only as complete as the states you actually modelled.
- Recall by similarity is not comprehension. Geometric memory, the context store that lets a Capability recall past runs by how close their execution was rather than by a key, today matches deterministic projections of execution state. It does not match semantic paraphrase - two runs that meant the same thing in different words are not yet neighbours.
- Native features are trust boundaries, not magic. A camera or a call is a permissioned grant with a purpose and an expiry, enforced at invocation. That is stronger than an install-time checkbox, and it is still a grant a person has to reason about.
None of these are reasons to keep intent on a slide. They are the reasons to keep the chain legible: when the models are the system, a wrong assumption is something you can read, point at, and change, instead of something buried in a build.
Conclusion
A purpose chain is a small idea with a demanding requirement. The idea is that Driver, Goal, Outcome, Course of Action and Capability are connected by realisation, so every running thing traces back to a reason and every reason traces down to something that runs. The demanding part is making the bottom of that chain genuinely executable - models the engine runs natively, not diagrams of code that lives elsewhere.
When you meet that requirement, three things stop being aspirations and become properties. Intent is traceable, because the chain has real edges. Consequence is visible, because the Capability declares its side-effect class before it is granted. And the most important constraints are enforced by structure - a transition that cannot fire beats a rule everyone is asked to remember, every time. That last one is the whole argument in miniature: a slide asks people to be careful; an executable purpose chain makes the careless state unreachable.