Priostack · Engineering Blog · 21 August 2026 · 9 min read

Reflex and Skopin: Closing the Loop to the Physical World

Deep diveSkopinEngineering

Most modeling tools stop at the drawing. You lay out an ArchiMate node, you attach a BPMN process to it, and the diagram is where the story ends. The model describes a world it cannot touch. Somebody still has to write the firmware, wire the sensor, poll the state, and reconcile what the device is actually doing against what the picture said it would do. That reconciliation gap - between the model and the world - is where most automation projects quietly rot.

Priostack's answer is not a better diagram. It is a loop that closes: orchestration decides what should happen, a runtime carries that decision out to a physical device, the device acts, and the device's real state comes back into the same architecture the decision was made from. Three names show up in that sentence - Priostack, Skopin, Reflex - and the point of this article is that they are not three products you buy separately. They are one system seen at three distances.

This is a technical piece about how the loop is built, why a hardware node that reports its own state is the load-bearing idea, and where the honest limits sit today.

1. The gap between the model and the world

An architecture model is a set of claims. It claims a pump exists, that a process governs it, that a decision table says when it runs, that a case handles the exceptions. The trouble is that the model and the machinery are usually authored, deployed, and observed by completely different toolchains. The model lives in a design tool. The machinery runs whatever was flashed onto a controller months ago. Between them sits a translation step performed by hand, and every hand translation is a place where the two versions drift apart.

When they drift, the diagram becomes decoration. People stop trusting it because it no longer matches the plant, and once nobody trusts the model, the model stops constraining anything. The failure is not that the picture was wrong on day one. It is that nothing kept the picture and the world tied together after day one.

Closing the loop means the same model that describes the device is the thing that runs on the device, and the device's real state is what the model reads back. No translation step to drift through.

2. One system at three distances

The cleanest way to hold the three names in your head is a single sentence: Priostack orchestrates, Skopin executes at the edge, and Reflex anchors it in the physical world. That is not a marketing slogan stretched over three SKUs. It is one control loop drawn at three distances from the metal.

   PRIOSTACK  (the architecture, the decision)
        |  deploys models + policies
        v
     SKOPIN  (the runtime, in the field)
        |  drives I/O, reads sensors
        v
     REFLEX  (the hardware, in the world)
        |  acts on / measures the physical thing
        v
   [ real device state ]
        |
        +----> reported back up into the same architecture

What travels down that path is not compiled code for a specific board. It is a bundle of models - ArchiMate for structure, BPMN for what the device does (executed as Petri nets), CMMN for the cases, DMN for the decisions, Camel routes for integration out to other systems, and IFML for any local views. Under all of them is one engine, Qubit, which runs BPMN, DMN and CMMN natively. Because the engine is the same in the cloud, in the app, and on the edge device, the same model means the same thing everywhere it lands. There is no "and now port it to the controller" phase, because there is nothing to port.

Why models and not code. A model is inspectable, comparable, and versionable as a single artifact. When the thing you deploy is the same thing you drew, the diagram cannot go stale relative to the device - they are the same object. Anything a model genuinely cannot express is provided as a permissioned native feature, not smuggled in as opaque code.

3. Reflex: anchoring in the physical world

Reflex is the reference edge hardware - the board the rest of the system is designed against so that "runs at the edge" has a concrete meaning rather than an aspirational one. It is a small Linux board built to sit where the physical thing is, not in a rack:

The reason a reference board matters is honesty. When the hardware is pinned down, the claims about timing, offline behaviour and radio reach are testable on a real object instead of averaged over a hypothetical fleet. Reflex is what keeps the edge story from being a diagram of an edge story.

4. Skopin: the runtime in the field

Skopin is Priostack's Linux edge operating system - the runtime that turns a board like Reflex from a Linux computer into a node in your architecture. It does three specific jobs:

Skopin is what makes a technology-layer Node in an ArchiMate model able to be a real device rather than represent one. The box on the canvas and the board on the wall are two views of the same node, kept in step by the runtime.

5. Safety by construction

On a control device - something driving an actuator where a wrong state can damage equipment or hurt someone - Skopin runs a fast, repeating scan cycle, on the order of every 120 milliseconds. Each pass reads the sensors, evaluates the process net, and drives the outputs. That much is ordinary for a control loop. What is not ordinary is where the safety comes from.

Sensor conditions become read-only guards on the process. Because the device's behaviour is a Petri net and not a pile of imperative branches, an unsafe interlock state can be made structurally unreachable - there is no sequence of transitions that arrives at it - rather than merely checked for at runtime and rejected. The difference is the difference between a fence and a sign that says please do not fall.

Checked vs. unreachable. A runtime check says "if we ever reach the bad state, refuse it." Safety by construction says "the bad state is not a reachable marking of this net, so we never arrive there to refuse it." The first depends on every check being present and correct. The second is a property of the model's semantics, verifiable before the device ever ships.
  every ~120 ms:
    read sensors  ->  guards (read-only conditions)
                          |
                    process net (Petri semantics)
                          |
              only SAFE transitions are firable
                          |
                    drive outputs
   unsafe interlock markings: not reachable -> never entered

This is the payoff of running the model itself rather than a translation of it. Reasoning about reachability is a statement about the net that is executing, not about a separate document that hopefully still describes it.

6. The node that reports its own state

The single idea that closes the loop is this: a connected node reports its own state back into the architecture it was deployed from. A diagram that only describes a device is a claim you have to go verify by hand. A device that continuously tells the model what it is actually doing turns the diagram into an observation.

That changes what an architecture model is. It stops being a design-time artifact you consult and starts being a live surface - the node on the canvas carries the device's real reported state, so the gap that opens between design and reality in a hand-integrated system never has room to form. When the field state and the model disagree, that disagreement is visible in the same place the decision was made, not discovered three weeks later during an incident review.

The return leg also feeds the history store. Because Priostack keeps a geometric memory - a context store where a step's position is derived from execution state, so the distance between two paths is meaningful - the stream of reported device state is recallable by similarity rather than only by key. You can ask what past situations most resemble the one a device is in now, instead of only what happened at a specific timestamp. (Its honest limit, covered below, is worth stating plainly.)

7. One model, every surface, offline

The same app - the same bundle of models - runs as a native mobile app whose renderer draws the IFML views, as a PWA in the browser through a JavaScript renderer, and on edge devices through Skopin. This matters for the loop because a field technician's phone, the ops team's browser dashboard, and the controller on the wall are all rendering the same underlying model.

The split that makes this work is between two kinds of state:

So a Reflex board can keep running its scan cycle and buffering state with the uplink down, and settle up with the canonical record when the link comes back - the same offline-tolerant behaviour a phone gets, for the same reason, out of the same design.

8. Honest limits

None of this is magic, and pretending otherwise would undermine the point.

The one thing to keep true. The value of the loop is that the model and the device stay tied together. Every shortcut that reintroduces a hand-translation step - a bit of firmware written outside the model, a state the device knows but never reports - reopens the gap the whole system exists to close.

Conclusion

Reflex, Skopin and Priostack are one control loop drawn at three distances. Priostack decides in terms of an architecture. Skopin carries that architecture - as running models, not ported code - out to where the work happens and runs it there, fast enough to control real equipment and structured so that unsafe states are unreachable rather than merely rejected. Reflex is the physical anchor that makes "the edge" a real board with real radios instead of a diagram. And the return leg - a node reporting its own state back into the model - is what keeps the picture and the world from drifting apart.

The ambition is narrow and worth being precise about: not to describe the physical world more elaborately, but to keep the description and the world attached to each other after the diagram is finished. That is the whole of it, and it is enough.

Related reading · Geometric memory for how reported state becomes recallable-by-similarity context, ArchiMate layers for how a technology-layer node becomes a live device, and Developers to build against the same engine that runs at the edge.

Priostack Engineering

Technical deep-dives on process automation, workflow engines, and the systems behind Priostack.