Skopin: An Edge OS That Runs Your Architecture
In most architecture practices there is a quiet lie built into the drawing. You put a Node on the technology layer of an ArchiMate model - a controller in a pump room, a kiosk in a clinic, a box on a factory line - and you name it, and you draw arrows to it. Then, separately, someone writes the firmware. The diagram describes intent; the device runs something else. Over time the two drift, and the model becomes a picture of what the system was supposed to be rather than what it is.
Skopin is Priostack's answer to that drift. It is a Linux edge OS whose job is narrow and specific: take the models you already drew, run them on a real device out in the field, and report the device's actual state back. A technology-layer Node in an ArchiMate model is not a label for something a programmer will build later. It can be the device - the same model, executing.
This piece is about how that works: what Skopin receives, what it runs, what it sends home, and where the honest limits are. The short version of the family it belongs to is: Priostack orchestrates, Skopin executes at the edge, Reflex anchors it in the physical world.
Contents
- 1. From a Node in the diagram to a device in the field
- 2. Models, not code - what actually ships
- 3. The deploy, run, report loop
- 4. One engine, so the model means one thing
- 5. Safety by construction on a control device
- 6. Offline by default, canonical on the engine
- 7. Reflex, and why the hardware matters
- 8. Honest limits
1. From a Node in the diagram to a device in the field
ArchiMate 4.0 gives you a technology layer for a reason: it is where the abstractions finally touch metal. A Node is a computational resource - a device, a server, a piece of infrastructure. In a normal toolchain the Node is documentation. In Priostack, a Node can be assigned a real, provisioned device that is running Skopin, and the relationship between the two stops being descriptive and becomes operational.
When that binding exists, three things change. The device receives the behaviour attached to that part of the model, not a hand-translation of it. The device's real status - online, degraded, what it last ran, what its sensors read - flows back and colours the model. And a change to the model becomes a change to the device, through a deployment, rather than through a separate release process nobody can see from the architecture view.
2. Models, not code - what actually ships
A Priostack app is a bundle of models, not a binary. That is true for a consumer super app and it is true for what lands on an edge device. What Skopin receives is that same kind of bundle, scoped to the device:
- ArchiMate for structure - what this device is, and how it sits in the larger architecture.
- BPMN 2.0 for what it does - processes that Qubit runs as Petri nets.
- DMN 1.3 for the decisions it makes - a threshold crossed, a state classified, a route chosen.
- CMMN 1.1 for cases that are not a fixed sequence - a maintenance episode, an alarm that a human works through.
- Camel routes for integration - how the device talks to a message bus, an upstream service, another controller.
- IFML for any local view - the small screen or panel a technician actually looks at.
Alongside the models come the policies: the capabilities this device is allowed to exercise, and the autonomy it is granted. Anything a model genuinely cannot express - reading a sensor bus, actuating a relay, holding a key, placing a call - is not smuggled in as hidden code. It is 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.
3. The deploy, run, report loop
Skopin's operational life is a loop with three moves. Priostack pushes a deployment to the device over Skopin's own protocol. Skopin runs the bundle locally, on the device, without needing to phone home for each step. And Skopin reports the device's real state back - not a heartbeat that only says "alive", but the actual condition: which processes are live, what the guards read, what ran and what it did.
PRIOSTACK (orchestrates)
|
| 1. deploy -> models + policies, scoped to this device
v
SKOPIN on the device (executes)
| runs BPMN/DMN/CMMN locally, offline-capable
| sensor reads become read-only guards
|
| 3. report -> real device state, not a heartbeat
^
|
REFLEX / field hardware (anchors)
radios, sensors, actuators, the physical world
The loop is deliberately boring, and boring is the property you want in the field. Because the models run locally, a device keeps doing its job when the link to Priostack is slow, intermittent, or gone. The report is what keeps the central picture honest: the model in the architecture view reflects the device, because the device is the thing telling it what is true.
4. One engine, so the model means one thing
The reason a Node can just be a device is that there is a single engine underneath everything. Qubit runs BPMN, DMN and CMMN natively - the same engine sits under the consumer app, under the API, and under Skopin at the edge. A process is not "compiled to firmware" for the device and "interpreted" in the cloud. It is executed by the same runtime in both places, so the same model means the same thing on every surface.
This is what makes the surfaces coherent rather than three re-implementations that happen to share a diagram. The same app can render as a native mobile app, as a PWA in the browser, and run on an edge device via Skopin, and the durable behaviour is identical because it is the same executable model, not three copies maintained by three teams that slowly disagree.
5. Safety by construction on a control device
On a device that controls something physical, "run the model" has to mean more than "eventually get around to it". Skopin runs a control device on a fast, repeating scan cycle - on the order of 120 ms - so the device is continuously evaluating its situation rather than reacting whenever a message happens to arrive.
Inside that cycle, sensor conditions become read-only guards. A guard cannot decide to actuate; it can only permit or forbid a transition based on what a sensor actually reads. And here the Petri-net semantics do real work: an unsafe interlock state is not something the code checks for and then refuses. It is made structurally unreachable. If two conditions must never hold at once, the net is built so that the marking representing "both at once" has no path to it. There is no runtime branch to forget, because the dangerous state is not in the reachable graph at all.
6. Offline by default, canonical on the engine
There is a clean split in where state lives, and it is worth being precise about. Interactive view state - what a local IFML panel is showing, what a technician has half-filled-in - is local to the device and works offline. Durable process, decision and case state is canonical on the engine. The device is free to keep running its loop with no connection; when the link returns, the report reconciles the device's real state with the central record.
That division is why the deploy, run, report loop tolerates bad networks instead of being defeated by them. The device does not need permission-per-step from the centre to keep operating, and the centre does not have to guess what the device did while it was dark - the device tells it, and the canonical state is updated from the truth on the ground rather than from an assumption.
7. Reflex, and why the hardware matters
Skopin is an OS, and an OS needs a body. Reflex is the reference edge hardware: a small Linux board with Wi-Fi, 4G, an eSIM, a microSD slot, IEEE 802.15.4, and expansion for Z-Wave, XBee and LoRa. It is deliberately unglamorous - the interesting part is not the board, it is that the board's radios reach the sensors and actuators that a technology-layer Node is ultimately about.
Reflex is a reference, not a requirement; Skopin is a Linux edge OS and the point is the software contract, not one specific board. But having a known-good anchor matters, because it closes the last gap in the family:
- Priostack orchestrates - it holds the models, pushes deployments, keeps the canonical state.
- Skopin executes at the edge - it runs the models locally on a fast scan cycle and reports real state.
- Reflex anchors it in the physical world - the radios and pins where a model finally touches a sensor or a relay.
8. Honest limits
A few things Skopin does not claim to be, said out loud:
- It does not turn firmware into magic. Native features - the camera, the keys, the actuation - are still real, permissioned capabilities with purposes and expiries, and they carry the real-world risk that any actuation carries.
- Safety by construction covers the modelled states. It is genuinely strong against forgotten runtime checks and genuinely silent about hazards you never expressed in a model.
- Money and account-security actions are capped at Confirm no matter what an app declares. A device that runs on its own for its ordinary work still has to stop and ask before it spends or changes a security posture - the autonomy ladder is not waived because the thing is at the edge.
- The report is only as honest as the sensors. Skopin faithfully relays what the device reads; it cannot relay what the device cannot sense.
Conclusion
The idea underneath Skopin is small and, once you see it, hard to unsee: a technology-layer Node does not have to be a promise about a device that someone will build. It can be the device. The same models that describe the architecture are the models Qubit executes, and Skopin is the OS that carries them the last mile - onto a board in a pump room, running a 120 ms loop, holding the dangerous states out of reach, and telling the centre the truth about what is actually happening.
Priostack orchestrates, Skopin executes at the edge, Reflex anchors it in the physical world. The value is not that any one of those is clever on its own. It is that the drift between the drawing and the device stops - because there is only one model, and it runs everywhere.