The Node Contract: From a Diagram to a Device in the Field
Architecture diagrams promise things they rarely keep. Someone draws a box on the technology layer, labels it "field gateway" or "pump controller", and the room nods. Then a different person builds the real thing by hand, in a different quarter, and from that day the diagram and the world drift apart. The picture says one thing; the site says another. Most of the interesting operational failures live in that gap.
This article is about closing it. In Priostack, a technology-layer Node in an ArchiMate 4.0 model can be a real device out in the field running Skopin - not a picture of a device, not a placeholder that documentation hopes matches reality, but the same object seen from a distance. We call the relationship between the box and the machine a Node Contract.
The idea is small and the consequences are large. If a Node and a device are the same thing, then the diagram cannot lie, because it is showing you the device. This piece walks through what that contract actually obliges - identity, models, and reported state - and is honest about where the guarantee stops.
Contents
1. From a box to a machine
On the ArchiMate technology layer, a Node represents a computational resource - a server, a gateway, a controller. In most tools it is documentation: a shape with a name, connected to other shapes, describing an intent that some human is expected to realise later. The shape has no idea whether the thing it describes exists, is powered on, or is doing its job.
Priostack treats a Node as a live handle. When you attach a model bundle to a Node and deploy it, the box stops being a description and becomes a reference to a specific machine. The same engine - Qubit - that runs the app in the cloud and the API behind it also runs on that machine, so the BPMN, DMN and CMMN in the bundle mean exactly what they mean everywhere else. There is no re-implementation step where meaning can slip.
2. The three obligations of a Node Contract
A contract has parties and obligations. The Node Contract has three, and they run in both directions - the device owes Priostack, and Priostack owes the device.
- Identity. The device is a specific someone, not a role that anything could fill. It can prove it is itself, and deployments are addressed to that identity.
- Models. The device receives exactly the models the Node references - the structure, processes, cases, decisions, routes and views in the bundle - and runs them under the same policies as every other surface.
- Reported state. The device tells Priostack what is actually true about it: which processes are live, which guards are holding, whether it is even reachable. The Node's status is measured, never asserted.
Miss any one and the box goes back to being a wish. A device with models but no identity is anonymous and cannot be trusted with a deployment. A device with identity but no reported state is a black box you have merely named. The contract is the conjunction.
3. A device with its own identity
Identity is where most "device management" stories quietly cheat. A shared token in a config file, copied onto a hundred units, is not identity - it is a password that a hundred machines happen to know. If any one of them is compromised, you cannot tell which, and you cannot address one without addressing all.
In Priostack a device gets its own identity when it is enrolled. It is intrinsic to that unit - not a string you can paste onto the next one off the shelf. Two devices built from the same reference hardware, flashed from the same image, are still two distinct identities the moment they enrol. The Node in the diagram describes a role - "tank controller for line 3" - and that role is filled by one identifiable device. When you deploy, the models go to that identity and no other.
We are deliberately not describing the cryptographic mechanics here; those are the engine's business. What matters at the level of the contract is the behaviour: a device can prove it is itself, that proof is not transferable, and everything sent to it is sent to it alone.
4. Enrollment: a diagram becomes a device
The lifecycle from box to running machine is short and has no manual middle. You attach a model bundle to a Node, and you deploy. Skopin - Priostack's Linux edge OS - receives that deployment over its own protocol, on the device's identity, and brings the models and policies up. From then on the device runs the app's models locally and reports back.
ArchiMate model (cloud) Device in the field
───────────────────────── ────────────────────
[ Node: "tank ctrl 3" ]
│ attach bundle
▼
( ArchiMate · BPMN · DMN
CMMN · Camel · IFML )
│ deploy ──────────────► Skopin enrols on its own identity
│ receives models + policies
▼
runs locally, offline-capable
│
◄──────── reported state ───────┘ (what is actually true)
[ Node status = measured ]Two properties of this loop are worth naming. First, interactive view state - what a screen is showing right now - is local to the device and works offline; the durable process, decision and case state is canonical on the engine, so a device can keep operating through a network gap and reconcile when it returns. Second, the same bundle that drives this Node also drives the app as a native mobile renderer and as a PWA in a browser. One model, three surfaces, one meaning.
5. Skopin at the edge: models, not scripts
What actually runs on the device is the app's models and policies, executed by Qubit, not a pile of bespoke firmware scripts. That distinction is the whole point. A third-party Priostack app ships a bundle of models - ArchiMate for structure, BPMN for what it does (run as Petri nets), CMMN for cases, DMN for decisions, Camel YAML for routes out, IFML for views. Anything a model genuinely cannot express, the app provides as a permissioned native feature - a camera, a set of keys, placing a call - granted with a stated purpose and an expiry, and enforced when it is invoked rather than waved through at install time.
On a control device, Skopin runs a fast, repeating scan cycle - on the order of 120 ms. Sensor conditions enter the model as read-only guards. Here is the part that changes how you think about field safety: unsafe interlock states are made structurally unreachable, rather than checked for at runtime. That is a property of Petri-net semantics - if a marking cannot be reached, no timing bug, no dropped check, and no race can produce it. Safety by construction, not safety by vigilance.
6. State that flows back
A diagram that only flows outward - from intent to the world - is the one that drifts. The Node Contract's third obligation is the return path: the device reports its real state, and the Node reflects it. The colour on the box is not what someone hoped when they drew it; it is what the machine last said about itself.
This is the same honesty boundary that runs through the rest of Priostack: measure, do not assert. A Node is not "green" because a person marked it green in a review. It is green because a device with a known identity reported a live, healthy set of processes, and amber or dark when it reported trouble or said nothing at all. The architecture model becomes a window onto the estate rather than a monument to a past decision.
Because reported state is durable on the engine while view state stays on the device, you get both a truthful long record of what the fleet did and a responsive local experience that survives a bad connection. The two are not in tension; they are two stores with two different jobs.
7. What a fleet is, at the concept level
A fleet, in Priostack terms, is not a spreadsheet of IP addresses and it is not a folder of certificates. A fleet is the set of Node Contracts currently being honoured. Many devices fill many roles - across one model or several - each keeping its own identity, each running the models it was deployed, each reporting back.
That definition makes fleet operations fall out naturally rather than needing a separate management product bolted on the side:
- Targeting is addressing a set of identities - "these forty controllers", not "everything that answers".
- A rollout is re-deploying a model bundle to that set; each device enrols the new models under the same policy machinery it always used.
- Aggregate state is the union of what the members report - a real view of the estate, drawn from measured facts, not a claimed inventory.
Because Reflex - the reference edge hardware - is a small Linux board with Wi-Fi, 4G, eSIM, microSD, IEEE 802.15.4 and expansion for Z-Wave, XBee and LoRa, a "device" in a fleet is often itself a hub for a cluster of sensors and radios in one location. The family framing is worth holding onto here: Priostack orchestrates, Skopin executes at the edge, Reflex anchors it in the physical world.
8. Honest limits
The Node Contract is a strong idea, and it is not magic. Naming its edges is part of keeping it trustworthy.
- Reported state is only as good as the sensors and the link. An offline device reports last-known, not present truth. Priostack marks the difference - a stale report reads as stale, not as fact - but no orchestration layer can measure what a disconnected board is doing this second.
- Safety by construction covers what the model expresses. If a hazard was never modelled as a guard, Petri-net reachability cannot forbid a state it was never told about. The technique removes whole classes of timing and race failures; it does not remove the need to model the hazard.
- Models do not express everything. The escape hatch is native features, and each one is a real grant with a purpose and an expiry, checked at invocation. That is the honest cost of the gap between what a diagram can say and what a device can do.
- The contract makes drift visible; it does not make hardware reliable. Boards still fail, radios still drop, power still cuts. What changes is that you find out from the model, quickly, per identity - not from a customer.
Conclusion
The distance between an architecture diagram and a device in the field is usually filled with hope and hand-work. The Node Contract removes the middle: a box on the technology layer is a specific machine with its own identity, it receives exactly the models it is meant to run, and it reports back what is actually true so the diagram can never quietly lie. Skopin runs those models at the edge with the same Qubit engine as everywhere else, keeping meaning constant across the mobile app, the browser and the board on the wall - and making unsafe states structurally unreachable rather than merely watched for. A fleet, then, is just the set of those contracts you are keeping right now. The honest limits are real, and stated out loud, which is exactly what lets the guarantee be worth something.