The Super App: How Many Apps Become One Priostack
Most phones are a drawer of strangers. Each app knows one corner of your life, guards it, and refuses to talk to the others. To get one thing done you become the integration layer - copying a number out of here, pasting it in there, remembering which app owns which fact. The "super app" is usually pitched as the cure: pile every service into a single vendor's walled garden. That trades a drawer of strangers for one landlord.
Priostack takes the other road. It is not one giant app that swallows the others. It is a substrate on which many independently published apps compose into a single experience for one person - without any of them having to know about each other, and without you having to hand-wire them together. The unit that makes this work is not the app. It is the capability.
This piece is about the actual mechanism: how a goal recruits whatever app can serve it, at exactly the autonomy you allowed, and why the consent model - not an API - is the glue. It is also honest about the seam between what ships today and where this is heading.
Contents
1. The trap of one app per goal
Think about a mundane goal: "renew my daughter's health card before it lapses." That touches an identity record, a clinic's booking, a reminder, maybe a payment, maybe a document you photograph. In the drawer-of-strangers model that is four or five apps and you are the courier between them. Nobody built the goal. They built the corners.
The reason it stays this way is that apps are shipped as opaque code. Code cannot be inspected, recombined, or reasoned about by anything outside itself. So the only integration surface is you, the human, retyping facts across a gap the software refuses to close. A super app that "solves" this by owning all the corners has not removed the gap - it has just moved the wall to its own perimeter.
Priostack's claim is narrower and, we think, more honest: if apps described what they can do in a form the engine understands, a goal could recruit them the way a workflow recruits a service - by capability, on demand, with your permission - instead of you carrying data between silos by hand.
2. Capabilities: the unit of recruitment
A capability is a declared, named thing an app can do, described well enough that the platform - and you - can decide whether to use it, without reading its internals. "Book a clinic appointment." "Look up a card's expiry." "Send a reminder." Each capability declares what it needs, what it touches, and how far it is allowed to act on its own.
Because capabilities are declared rather than buried in code, a goal does not need to name an app. It needs to name what it wants done. The platform then matches the goal to whatever published capability can serve it. That is the inversion at the heart of the super app:
OLD: you → pick app → learn its UI → do the step → carry result out
NEW: goal → matched to a capability → runs at your granted autonomy
↘ result stays in the goal, not a siloTwo apps from two vendors that never heard of each other can serve the same goal, one step apart, because both speak in capabilities the engine can read. The person sees a single flow. The apps stay independent. Nobody built a private integration; the capability contract is the integration.
3. What a Priostack app actually ships
This only works because a third-party Priostack app is not a bundle of code. It is a bundle of models - open, inspectable, standards-based descriptions that the single engine underneath, Qubit, runs natively:
- ArchiMate 4.0 - the structure: what the app is made of, which parts sit in which layer, which Nodes are real devices.
- BPMN 2.0 - what it does, step by step. Qubit runs these as Petri nets, so a process has real execution semantics, not just a drawing.
- CMMN 1.1 - the cases: the less-linear work where a human judges what happens next.
- DMN 1.3 - the decisions, factored out of the process so a rule can change without rewriting the flow.
- Camel YAML - the integrations and routes out to the rest of the world.
- IFML - the views: what a person sees and touches.
Because the app is models, the platform can read it. It can see that a BPMN task needs a decision, that a decision needs an input, that an input is a capability another app offers. It can compose. Opaque code forecloses all of that; a model invites it. This is the same property that lets Qubit mean the same thing on every surface - the model is the program, so there is one source of truth for behaviour, and the engine executes it rather than re-implementing it three times.
4. The consent model is the glue
If a goal can silently recruit any app that fits, you have rebuilt the surveillance super app with extra steps. So the glue is not the matching engine. The glue is consent - specifically, an autonomy ladder that governs how far anything is allowed to act on your behalf.
| Level | Name | What it may do |
|---|---|---|
| 0 | Suggest | Proposes only. Nothing happens until you do it. |
| 1 | Prepare | Drafts the action. You send it. |
| 2 | Confirm | Acts, but asks before each action. |
| 3 | Delegated | Acts within set limits, then tells you after. |
| 4 | Continuous | Runs on its own. You can stop it at any time. |
Two numbers meet at every capability. An app declares the highest autonomy it is designed to operate at. You grant an autonomy for it. The effective autonomy is the lower of the two. An app cannot promote itself past your grant, and you cannot push an app past what it was built to do safely. Neither side wins by default; the cautious side wins.
This is what makes recruitment safe. A goal can reach for any capability that fits, but each one arrives clamped to the autonomy you actually allowed - so "many apps become one" never means "many apps get one blanket permission."
5. Side effects a user sees before granting
Autonomy answers "how far." It does not answer "touching what." So every capability also declares its side-effect class, and you see that class before you grant anything:
- read_only - looks, changes nothing.
- reversible_local - changes something on your device that you can undo.
- external_communication - sends something out to someone else.
- financial_commitment - spends or commits money.
- account_security - touches credentials, keys, or access.
- high_stakes - consequences that are hard to walk back.
The point is that consent is informed by construction. You are not agreeing to a name; you are agreeing to a declared behaviour. "This capability sends a message to your clinic" reads very differently from "this capability commits a payment," and the ladder's money cap keys off exactly these classes. A person granting Delegated to a read-only lookup is making a smaller decision than granting it to something that spends - and the interface can say so, because the app told the truth about itself in a form the platform can enforce.
6. One app, three surfaces, one meaning
Because the app is models and Qubit is a single engine, the same app runs in three places without being rewritten:
one app (models)
/ | \
native mobile PWA Skopin edge
IFML views IFML views runs models + policies
drawn natively in JS out in the field
\ | /
Qubit: BPMN / DMN / CMMN run natively
same model → same meaning everywhereOn a phone, a native renderer draws the IFML views. In a browser, a JavaScript renderer draws the same views as a PWA. On a device in the field, Skopin - Priostack's Linux edge OS - runs the app's models and policies locally, receives deployments from Priostack, and reports the device's real state back. A Node in the app's ArchiMate technology layer can be a real device running Skopin, not a picture of one.
The division of state is deliberate. Interactive view state - what you have half-typed, what is scrolled where - is local to the device and works offline. The durable truth - where a process is, what a case decided - is canonical on the engine. So the super app does not fall apart when the network does; the view keeps working, and the shared reality reconciles when it can.
7. Where models stop: native features
Models are expressive, but they cannot express everything. A model cannot open a camera, hold a private key, or place a call. When a goal needs one of those, the surrounding super app provides it as a native feature - and this is where the discipline matters most.
A native feature is not granted at install time as a blanket permission. It is granted with a purpose and an expiry, and it is enforced at the moment of invocation, not once at setup. "Use the camera to photograph this one document, for the next ten minutes" is a different grant from "camera access, forever." The model-driven part of the app stays inspectable; the native part stays fenced, scoped, and time-boxed. That boundary is how the super app reaches into hardware without becoming the thing that owns your hardware.
8. What is shipped, and where this is heading
It would be easy to describe this as finished. It is not, and the honest seam matters.
Shipped: the engine that runs BPMN, DMN and CMMN natively on every surface; apps published as models rather than code; the autonomy ladder with its lower-of-two rule and the hard money and account-security cap; declared side-effect classes shown before a grant; native features scoped by purpose and expiry; Skopin running app models at the edge and reporting real state back.
Where it is heading: richer recruitment - a goal reaching across more capabilities from more independent publishers with less prompting - depends on how those capabilities describe themselves, and that vocabulary is still growing. It also leans on geometric memory, the context store that recalls prior runs by similarity rather than by key, so a goal can find "the last time we did something like this." That store is real and useful today, but with an honest limit worth stating plainly: it matches deterministic projections of execution state, not semantic paraphrase. It can find a path close to this one; it cannot yet understand that two differently-worded intentions mean the same thing. Recruitment gets better as that gap closes, and we would rather name the gap than paper over it.
Conclusion
"Many apps become one" is not a bundling trick and not a walled garden. It is a consequence of three decisions: ship apps as models the engine can read, make the capability - not the app - the unit a goal recruits, and put an inspectable consent model between the goal and every action it might take. The matching is the easy part. The autonomy ladder, the side-effect classes, the money cap, and the purpose-and-expiry fence on native features are the parts that make it something you would trust with your daughter's health card. Independence for the publishers, one coherent experience for the person, and a consent boundary neither side can quietly cross - that is the super app worth building.