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

Models, Not Code: What a Priostack App Actually Is

Deep diveArchitectureEngineering

On most platforms, a third-party app is a binary. You upload a compiled artifact, a reviewer runs it in a sandbox, watches what it does, and tries to guess what it might do next. The thing you distribute is opaque by construction - a wall of machine instructions - and everything downstream, from review to permissions to portability, is a workaround for that opacity.

Priostack starts from a different submission unit. A Priostack app is not a binary. It is a bundle of models - a description of structure, behaviour, cases, decisions, integrations, and views, each written in a standard modelling language. The engine underneath, Qubit, reads those models directly and runs them. There is no compiled blob in the middle. What you submit is what runs, and it is legible the whole way down.

This is not a stylistic preference. It changes what review can catch, what a permission can promise, and how one app can run unmodified as a phone app, a browser app, and a program on a device in a field. This piece walks through what is actually in the bundle, what the declarative form buys you, and - just as important - the honest contract for everything a model cannot say.

1. The submission unit is a bundle of models

When a developer publishes to Priostack, they submit a set of model files, not source code and not a compiled artifact. The models describe the app completely enough that Qubit - the single engine that sits under the app, the API, and the edge - can execute them. Because the models are the app, there is nothing hidden behind them. A reviewer reads the same artifact the engine runs. A user granting a permission is reasoning about the same artifact too.

The practical consequence is that "what does this app do" has an answer that can be read, diffed, and reasoned about, rather than observed and hoped for. The rest of the platform - review, portability, the permission model - all leans on that one fact.

2. Six languages, one meaning

The bundle is not one big model. It is a small set of standard languages, each covering the part of an app it was built for. Priostack did not invent these notations - they are the ones enterprises already use to describe systems, and Qubit executes them natively rather than translating them into something else first.

  A Priostack app bundle
  ────────────────────────────────────────────
  ArchiMate 4.0  →  structure: what exists, how it relates
  BPMN 2.0       →  what it does: processes, run as Petri nets
  CMMN 1.1       →  cases: work that is not a fixed sequence
  DMN 1.3        →  decisions: the rules, as tables
  Camel YAML     →  integrations: routes out to other systems
  IFML           →  views: the screens the user actually sees
  ────────────────────────────────────────────
             one engine (Qubit) runs all six

• ArchiMate describes the structure - the actors, application components, and technology nodes, and how they relate. A technology-layer node in an ArchiMate model is not a diagram box; it can be a real device.
• BPMN describes what the app does as processes. Qubit runs BPMN as Petri nets, which is what gives the behaviour precise, checkable semantics rather than a flowchart that a runtime interprets loosely.
• CMMN covers case work - the parts of an app that are not a fixed sequence but a set of things that may happen, gated by conditions.
• DMN holds the decisions as tables, so the rules are data you can read, not branches buried in code.
• Camel YAML defines integration routes - how the app talks to other systems - following well-worn Enterprise Integration Patterns.
• IFML describes the views, the interaction surface the person actually touches.

Because Qubit runs each of these directly, the same model means the same thing wherever it runs. A BPMN process is not "compiled for mobile" and separately "compiled for the browser." There is one definition and one engine reading it.

3. What declarative form buys: review you can trust

The first thing a legible bundle buys is real review. When behaviour is declared rather than compiled, a reviewer is not watching a black box and generalising from a handful of runs. They are reading the actual decision tables, the actual process paths, the actual routes an app can take to reach the outside world.

That matters most for the things users worry about. A Camel route that sends data somewhere is visible as a route. A DMN table that decides who gets what is visible as a table. A BPMN process that moves money is visible as a process. None of these can hide in an instruction stream, because there is no instruction stream - the model is the artifact of record.

4. One app, every surface

The second thing the model bundle buys is portability that is real rather than a re-implementation. The same app runs in three places without being rewritten for any of them:

• As a native mobile app, where the Android or iOS renderer draws the IFML views.
• As a PWA in the browser, where a JavaScript renderer draws the same views.
• On edge devices via Skopin, Priostack's Linux edge OS, which runs the app's models and policies on a device out in the field.

This works because the surfaces differ only in how the views are drawn, not in what the app means. The durable state - the process a case is in, the decision that was made, the step a workflow has reached - is canonical on the engine. The interactive view state is local to the device, which is what lets the surface keep working offline. When the device reconnects, it is not the source of truth about the process; the engine is.

  Same app, three renderers, one canonical state
  ─────────────────────────────────────────────
  IFML views ─┬─ native renderer   (Android / iOS)
              ├─ JS renderer        (PWA in browser)
              └─ Skopin             (edge device)
                     │
   view state: local to device, works offline
   process / decision / case state: canonical on Qubit

The split is deliberate. You want the screen to stay responsive on a train with no signal, and you also never want two devices to disagree about whether a payment was authorised. Local views, canonical process state, is how you get both.

5. What models cannot say: the native-feature contract

Models describe a great deal, but not everything. A model cannot open a camera. It cannot hold a cryptographic key, place a phone call, or read a sensor. If the whole platform stopped at "declare it in a model," these apps could not touch the physical world at all - which would make them clean, portable, reviewable, and useless for a large class of real work.

So Priostack draws the line explicitly. Anything a model can express, the model expresses. Anything a model cannot express, the surrounding app - the "super app" - provides as a native feature, and each native feature is permissioned. It is granted with a stated purpose and an expiry, and the grant is enforced at the moment the feature is invoked, not once at install time and forgotten.

This keeps the legibility guarantee honest. The reviewable, portable core stays declarative. The parts that genuinely cannot be a model - the camera, the keys, the call - are named individually, scoped to a purpose, time-boxed, and checked in the moment. Nothing sneaks into the physical world through a gap in the model.

6. Side effects, autonomy, and the grant

Legibility is also what lets Priostack describe an app's effects in terms a person can actually decide about. Every capability an app declares carries a side-effect class, and the user sees that class before granting anything:

• read_only - it looks, it does not change anything.
• reversible_local - it changes something you can undo, on your own device.
• external_communication - it talks to the outside world.
• financial_commitment - it commits money.
• account_security - it touches the security of an account.
• high_stakes - the effect is serious and hard to walk back.

Layered on top of that is the autonomy ladder - how much an app is allowed to act on its own:

Two rules make this trustworthy rather than decorative. First, effective autonomy is the lower of what an app allows and what a user grants - an app asking for Continuous does not get it if you granted Confirm. Second, actions in the money and account-security classes are capped at Confirm no matter what an app declares. An app cannot delegate away your money or your account security, even if it wants to and even if you would let it. The ceiling is structural.

7. Safety by construction at the edge

The model-not-code idea pays off most sharply where mistakes are physical. On a control device, Skopin runs a fast, repeating scan cycle - on the order of 120 ms - reading the world and stepping the app's processes forward. Sensor conditions become read-only guards on the process. Here the Petri-net semantics of BPMN stop being an implementation detail and start being a safety property.

Because the process is a Petri net, unsafe interlock states can be made structurally unreachable - there is simply no sequence of transitions that reaches them - rather than being blocked by a runtime check that someone has to remember to write and that can be wrong. This is safety by construction: the bad state is not caught, it does not exist in the reachable graph in the first place. A guard you forgot to add is a bug; a state the model cannot reach is not.

The hardware side of this is the family framing Priostack uses: Priostack orchestrates, Skopin executes at the edge, Reflex anchors it in the physical world. Reflex is the reference edge board - a small Linux computer with Wi-Fi, 4G, an eSIM, microSD, IEEE 802.15.4, and expansion for Z-Wave, XBee, and LoRa. A technology-layer node in an ArchiMate model can be exactly that board, running Skopin, receiving deployments from Priostack over its own protocol and reporting the device's real state back. The model in the bundle and the metal in the field are the same node.

8. Honest limits

None of this is free, and it is worth naming where the edges are.

• Not everything wants to be a model. The native-feature contract exists precisely because a real class of work - camera, keys, calls, sensors - cannot be declared. Those parts are permissioned and time-boxed, but they are still native code behind a contract, not models. The guarantee is the contract, not the absence of code.
• Declarative is not automatically simpler. Six modelling languages is a real learning curve. The payoff is legibility and portability, not fewer concepts to hold in your head.
• The context store matches projections, not meaning. Priostack's geometric memory derives a step's position from execution state, so distance between paths is meaningful and you can recall by similarity rather than by key. But today it matches deterministic projections of values - it does not yet match semantic paraphrase. Two runs that mean the same thing in different words are not the same point.
• An app only knows what you tell it. That is the consumer ethic, and it is also a limit - the app cannot work out what deserves your attention from information you never gave it. That is the trade Priostack chooses on purpose: software that wants to get out of your way, not software that wants your evening.

Conclusion

The whole design turns on one decision: make the submission unit a bundle of models instead of a binary. Everything else follows from it. Review reads the artifact that runs. One app runs on a phone, in a browser, and on a board in a field, because the surfaces differ only in how the views are drawn. Permissions describe declared effects, and autonomy is capped where it matters. The parts that cannot be a model are named, scoped, and checked at the moment of use. And at the edge, unsafe states are made unreachable by the structure of the model rather than caught by a check you had to remember to write.

Models, not code, is not a slogan about elegance. It is the reason a stranger's app can be understood before it runs, carried across surfaces without rewriting, and trusted with something physical - and it is honest about the seam where the models stop and the native features, permissioned per use, begin.