Privacy by Structure, Not by Policy
Most software asks you to trust a promise. The privacy policy says the company will not misuse what it collects, the settings screen has a row of toggles, and somewhere behind all of it a server already holds a copy of everything you did. Privacy, in that world, is a setting - a configuration you have to find, understand, and believe. The data was gathered first; the restraint is added on top, in prose, after the fact.
We wanted a different starting point for Priostack. Not a better promise, but a shape: an architecture where the private thing is never collected in the first place, because there is nowhere for it to go. If the interactive state of what you are doing lives on your device and never leaves it, no policy is needed to protect it. It is protected by the fact that it is not there to protect. That is what we mean by privacy by structure.
This piece is about the specific structure - what actually stays local, what becomes durable and why, and the mechanisms that keep the boundary honest. It is not a manifesto. It names the real limits too.
Contents
- 1. The surveillance default, and its cost
- 2. Two kinds of state
- 3. "It only knows what you tell it"
- 4. The same app, three surfaces, one boundary
- 5. Native features: purpose and expiry, enforced at use
- 6. Autonomy and side effects as visible structure
- 7. Skopin: state that stays in the field
- 8. Honest limits
1. The surveillance default, and its cost
The dominant pattern for a decade has been: collect everything, decide later. Instrument every screen, stream the events to a server, keep them indefinitely because storage is cheap and someone might want to analyse it. Privacy then becomes damage control - a policy document, a consent banner, a set of toggles that default to "on" and that you are gently discouraged from finding.
The problem is not only that people distrust the toggles. It is that the toggle is the wrong layer. A setting is a runtime request to a system that already has your data and already has the code to use it. You are asking the fox to keep the door shut. Even when the intent is entirely good, the capability remains: the data is centralised, the pipeline exists, and one change of policy - or one breach - flips the switch. Privacy expressed as configuration is privacy that can be reconfigured.
2. Two kinds of state
The reason a structural boundary is even possible is that not all state is the same. In a Priostack app there are two clearly different kinds, and they want to live in different places.
Interactive state is the moment-to-moment texture of using the app: which view you are on, what you have typed but not submitted, the half-filled form, the item you are hovering, the scroll position, the draft. This is enormous in volume, deeply personal in aggregate, and almost entirely uninteresting to anyone but you. It is also inherently local - it describes your device's screen right now.
Durable state is the small set of facts that a process genuinely needs to be true across time and across devices: a decision that was made, a case that is open, a step in a workflow that has completed. This is what has to survive you closing the app, and what has to be consistent if you pick up on a different device.
Conventional apps blur these together and ship both to the server, because the server is where the code runs. Priostack can keep them apart because the app is not code in the usual sense - it is a bundle of models, and the engine that runs those models draws a hard line between the two kinds of state.
INTERACTIVE STATE DURABLE STATE
(local to the device) (canonical on the engine)
┌──────────────────────┐ ┌──────────────────────┐
│ current view (IFML) │ │ process token (BPMN) │
│ unsent input, drafts │ ──▷ │ decision result (DMN)│
│ scroll / hover / UI │ only │ case milestone (CMMN)│
│ works offline │ when a │ the minimum to be │
│ never uploaded │ step │ correct across time │
└──────────────────────┘ commits └──────────────────────┘3. "It only knows what you tell it"
A third-party Priostack app is a set of models, not a program: ArchiMate for structure, BPMN for what it does (run natively as Petri nets), CMMN for cases, DMN for decisions, Camel routes for integrations that reach outside, IFML for the views you see. Qubit, the single engine underneath, runs those models directly. The same model means the same thing on every surface because the same engine interprets it everywhere.
That structure is what makes the privacy boundary real rather than aspirational. The IFML views and their interactive state are rendered and held on the device. The durable spine - the process tokens, the decisions, the case milestones - is canonical on the engine, and it only ever receives what a modelled step commits. There is no ambient telemetry stream, because there is no place in the model for one. An app cannot quietly collect what it did not declare a step to collect. "It only knows what you tell it" is not a slogan about good intentions; it is a description of what the engine will and will not accept.
This also disciplines the app authors, not just protects the user. To send something outward, an app has to model a Camel route that does it - a visible, reviewable integration - and to record something durably, it has to model the step that records it. Data minimisation stops being a virtue you hope the developer practised and becomes a consequence of having to draw the pipe before anything can flow through it.
4. The same app, three surfaces, one boundary
The same Priostack app runs as a native mobile app, where the Android or iOS renderer draws the IFML views; as a PWA in a browser, where a JavaScript renderer draws the same views; and on edge devices via Skopin. It is the same models in all three cases - only the renderer differs.
Crucially, the boundary is identical across all three. Interactive view state is local to the device and works offline; the durable process, decision, and case state is canonical on the engine. Whether you are on a phone with no signal, a laptop browser, or a board out in a field, the draft you are typing and the screen you are on are yours and stay put. What travels is the small durable fact, and only when a step commits it.
5. Native features: purpose and expiry, enforced at use
Models cannot express everything. A camera capture, a cryptographic key, placing a phone call - these are things no BPMN or DMN diagram can contain. So the surrounding "super app" provides them as native features, and this is exactly where a lot of apps leak, because the usual pattern is to grant a broad permission once, at install, and never revisit it.
Priostack grants a native feature with a purpose and an expiry, and enforces it at invocation time, not at install time. The distinction matters. Install-time permission is a blanket: you said yes once, in the abstract, and the app may use the camera forever for reasons you will never see. Invocation-time enforcement means the grant is checked at the moment of use, against the stated purpose, and it lapses when it expires. A permission that has a reason attached and a clock on it is a much smaller thing to give away than a permanent, purposeless one.
6. Autonomy and side effects as visible structure
Privacy is not only about data at rest. It is also about what the software is allowed to do on your behalf without asking. Priostack makes that a structured, visible thing rather than a buried preference.
Every capability an app declares carries a side-effect class, and you see it before you grant anything: read_only, reversible_local, external_communication, financial_commitment, account_security, or high_stakes. The class tells you the shape of the consequence in advance - whether an action merely looks at something, changes something you can undo locally, talks to the outside world, or spends money.
On top of that sits the autonomy ladder, which governs how far the software may go on its own:
| Level | Name | Behaviour |
|---|---|---|
| 0 | Suggest | Proposes only; does nothing itself |
| 1 | Prepare | Drafts the action; you send it |
| 2 | Confirm | Asks before each action |
| 3 | Delegated | Acts within limits, tells you after |
| 4 | Continuous | Runs on its own; you can stop it |
Two rules make this a structural guarantee rather than a preference. First, effective autonomy is the lower of what an app allows and what you grant - an app cannot claim more freedom than you gave it, and you cannot accidentally be pushed past what the app itself declared. Second, money and account-security actions are capped at Confirm no matter what an app declares. There is no configuration, and no app manifest, that lets a financial or account-security action run without asking you first. That ceiling is in the structure, not in a policy you have to trust.
7. Skopin: state that stays in the field
The same structure extends to the edge, and this is where it gets physical. Skopin is Priostack's Linux edge OS. It runs an app's models and policies on a device out in the field, receives deployments from Priostack over its own protocol, and reports the device's real state back. A technology-layer Node in an ArchiMate model can be an actual device running Skopin - the diagram and the hardware are the same object.
On a control device, Skopin runs a fast, repeating scan cycle - on the order of 120 ms. Sensor conditions become read-only guards, and unsafe interlock states are made structurally unreachable rather than checked at runtime. That is a Petri-net property: safety by construction, not safety by a runtime if that someone might get wrong. The reference hardware, Reflex, anchors this in the physical world - a small Linux board with Wi-Fi, 4G, eSIM, and radios for 802.15.4, Z-Wave, XBee, and LoRa.
For privacy, the point is that the sensor stream and the interactive control state live where the work happens. The field device holds its own condition; what returns to the centre is the device's reported state, the durable spine again, not a raw firehose of everything the sensors ever saw. The family framing captures it: Priostack orchestrates, Skopin executes at the edge, Reflex anchors it in the physical world. The data with the most volume and the least need to travel - the moment-to-moment sensor readings - is exactly the data that stays local.
8. Honest limits
Structure is a strong guarantee, but it is not magic, and it would be dishonest to imply otherwise.
- Durable state is still real state. The process tokens, decisions, and case milestones that become canonical on the engine are, by design, a record. They are minimal, and they are only what a modelled step commits - but they exist, and a durable record is not the same as no record. Privacy by structure shrinks the collected surface; it does not reduce it to nothing.
- Integrations reach outward on purpose. A Camel route exists precisely to talk to the outside world - a bank, a messaging provider, another system. Once data crosses that boundary it is governed by whatever is on the other side, not by Priostack. The structure makes the crossing visible and modelled; it cannot follow the data after it leaves.
- Geometric memory matches projections, not meaning. The context and history store recalls by similarity of execution state rather than by key, which is useful, but today it matches deterministic projections of values, not semantic paraphrase. It is a real capability with a real ceiling, and we would rather say so than overstate it.
- Native features are a trust surface. Purpose and expiry make the camera or the keys a bounded grant rather than a blanket one, but a granted native feature is still a granted capability. The mechanism narrows the blast radius; it does not remove the fact that you are trusting the app for the duration of the grant.
None of these undo the central claim. They mark where it stops.
Conclusion
Privacy as a policy is a promise about the future made by a system that has already collected your data. Privacy as structure is a property of where state is allowed to exist. Priostack chooses the second wherever it can: interactive state stays on the device and works offline, durable state is the minimum a process needs to be correct, native features are granted with a purpose and a clock and checked at the moment of use, and money and account-security actions cannot be automated past the point of asking you - not because a policy forbids it, but because the structure has no slot for it.
The consumer ethic behind all of this is simple to state and hard to live up to: software that works out what deserves your attention, asks before it acts, and then gets out of the way. Software that wants you gone, not software that wants your evening. "It only knows what you tell it" is the engineering version of that promise - and the reason it is more than a promise is that there is nowhere else for the rest to go.