The Autonomy Ladder: Software That Asks First
Most software asks for everything once, at the worst possible moment. You install an app, a wall of permissions appears while you are trying to get to the thing you came for, and you tap Allow because the alternative is not using the app at all. The bargain is take-it-or-leave-it, made before you have any idea what the software will actually do with what you just handed over.
Priostack is built on the opposite bargain. An app declares the most it could ever do. A person grants some slice of that, action class by action class, and can move the dial afterward. The two numbers are kept separate on purpose, and the software is only ever allowed to operate at the lower of them. We call the scale the autonomy ladder, and the rule that binds it to consent is deliberately boring: effective autonomy is the lower of what an app allows and what a user grants.
This piece walks the five rungs, the min rule, the side-effect classes a person sees before granting anything, and the one place we refuse to let the dial go all the way up no matter what an app asks for. It is an engineering post, but the shape of it is an ethical stance: software that asks first, and gets out of the way.
Contents
- 1. The install-time bargain we all lost
- 2. Five rungs: Suggest to Continuous
- 3. Two dials, and the lower one wins
- 4. Side effects you see before you grant
- 5. The cap: money and account security stop at Confirm
- 6. Why the ladder is enforceable: models, not code
- 7. Autonomy where nobody is watching: Skopin
- 8. Software that wants you gone
1. The install-time bargain we all lost
The permission prompt at install time is a category error. It asks you to consent to a capability - "access your contacts", "send notifications", "make payments" - at the exact moment you know the least about how it will be used. There is no purpose attached, no sense of how often, no way to say yes to the first modest use and no to the tenth aggressive one. And once granted, the grant is effectively forever; almost nobody goes back to revoke.
The deeper problem is that install-time permission conflates two different questions. One is what is this software capable of? - a fact about the software. The other is how much of that am I comfortable letting it do? - a decision by a person. Bundling them means the capable app and the cautious user have nowhere to meet in the middle. You either accept the whole surface or you walk away.
Priostack splits those questions apart and keeps them apart for the life of the app. The declaration is the app's; the grant is yours; neither can quietly become the other.
2. Five rungs: Suggest to Continuous
Autonomy is not a switch, it is a ladder with five rungs. Each rung is a precise statement about who does the acting and when a human is in the loop.
- Suggest (0) - the app proposes, and does nothing else. It can surface an option, draft a recommendation, point at what looks worth your attention. Every action after the suggestion is yours.
- Prepare (1) - the app drafts the thing in full - the message, the order, the filing - and you send it. The work is done for you; the commitment is still yours to make.
- Confirm (2) - the app asks before each action and acts only on your yes. This is the rung of "do it, but check with me every time."
- Delegated (3) - the app acts within limits you set and tells you after. You are not in the loop for each action; you are in the loop by exception and by the after-the-fact record.
- Continuous (4) - the app runs on its own against its declared purpose, and you can stop it. This is the rung for the monitor that watches a line, the router that keeps a feed flowing - work you do not want to babysit.
The rungs are ordered by how far the software gets from a human hand on each action. Nothing about the higher rungs is more "advanced" or more desirable; a shopping app that lives at Confirm is not lesser than one that reaches Continuous. The rung is a description of a relationship, not a score.
3. Two dials, and the lower one wins
Here is the mechanism that makes the ladder more than a label. There are two dials, not one.
The first is the allowed dial - the highest rung an app declares it will ever operate at, published up front. A well-built app declares the most it could ever do, honestly, so that a person is deciding against the real ceiling rather than a comfortable understatement. The second is the granted dial - the rung you, the person, are willing to hand it, which you can raise or lower whenever you like.
Effective autonomy is the lower of the two. Always.
effective = min(allowed, granted)
app allows: Suggest ─ Prepare ─ Confirm ─[Delegated]─ Continuous
you grant: Suggest ─ Prepare ─[Confirm]─ Delegated ─ Continuous
│
effective ───────────────────────[Confirm] (the lower rung wins)
The consequences are quietly powerful. An app that declares Continuous cannot run continuously for a user who only granted Confirm - it drops to asking every time. A cautious user is never overridden by an ambitious app. And an ambitious user cannot push an app past what it declared it was built to do - if the app tops out at Delegated, granting Continuous changes nothing. Neither side can climb over the other. The floor is set by whoever is more conservative, which is exactly the property you want in a trust relationship.
Because grants live outside install time, they can carry a purpose and an expiry. You are not deciding "forever" in the abstract; you are deciding "this much, for this reason, until then," and the ceiling is always in view.
4. Side effects you see before you grant
A rung tells you how autonomously the software acts. It does not tell you what kind of dent the action leaves in the world. A Continuous app that only ever reads is very different from a Confirm app that can move money. So every capability also declares the class of side effect it can produce, and you see that class before you grant anything.
| Side-effect class | What it means |
|---|---|
| read_only | Observes and reports. Changes nothing. |
| reversible_local | Changes something on the device that you can undo. |
| external_communication | Sends something outward - a message, a request - that leaves the device. |
| financial_commitment | Spends, orders, or otherwise commits money. |
| account_security | Touches credentials, access, or the security of an account. |
| high_stakes | Consequences that are hard or impossible to walk back. |
This is the honesty layer. Two apps can both ask for Delegated and be worlds apart: one is delegated to tidy your local drafts (reversible_local), the other is delegated to send messages on your behalf (external_communication). Naming the side effect at grant time means the rung is never abstract. You are agreeing to a specific kind of consequence at a specific level of independence, and you saw both before you said yes.
5. The cap: money and account security stop at Confirm
There is one place the ladder does not go all the way up. Any capability whose side effect is financial_commitment or account_security is capped at Confirm - no matter what rung the app declares, and no matter what rung the user tries to grant.
That means spending money and changing the security of an account can never be Delegated and can never be Continuous. The software may line the whole thing up, fill in every field, get you to the last step - but the commitment itself waits for a human yes, every single time. The min rule already lets a cautious user hold an app back. This cap is different: it holds everyone back, including the user who would happily grant more, because these two classes of action are where a mistake is least recoverable and a runaway agent does the most damage.
You can read the whole cap as a single sentence: the more autonomy you climb, the more the software can do without you - except with your money and your accounts, where it always stops to ask.
6. Why the ladder is enforceable: models, not code
A ladder made of good intentions is worth nothing if the software can step around it. What makes these limits real on Priostack is that a third-party app is not a bag of code you have to trust. It is a bundle of models, and the same engine - Qubit - runs those models everywhere.
An app ships its structure as ArchiMate, what it does as BPMN (executed as Petri nets), its longer-running cases as CMMN, its decisions as DMN, its routes out to other systems as Camel, and its views as IFML. Qubit runs those directly. Because behaviour is expressed as a model the engine interprets - rather than arbitrary code doing whatever it likes - the engine is the choke point where the autonomy rung and the side-effect cap are enforced, at the moment of the action.
Anything a model genuinely cannot express - opening the camera, holding a key, placing a phone call - is provided by the surrounding app as a native feature. Those are not granted at install and left open. Each is granted with a stated purpose and an expiry, and checked at the moment it is invoked, not once at setup. An expired or out-of-purpose native feature simply does not fire.
An app is: ArchiMate ─ BPMN ─ CMMN ─ DMN ─ Camel ─ IFML (models Qubit runs)
│
enforced here: rung + side-effect cap
│
Beyond models: native features (camera, keys, a call)
granted with a purpose + expiry, checked at invocation
This is why the min rule and the Confirm cap are not advisory. They are enforced by the single engine that stands between every model and every real-world effect, on every surface the app runs on.
7. Autonomy where nobody is watching: Skopin
The autonomy ladder matters most where a human is not present to catch a mistake - out at the edge, on a device in the field. Skopin, Priostack's Linux edge OS, runs an app's models and policies on that device, receives deployments over its own protocol, and reports the device's real state back. In an ArchiMate model, a technology-layer Node can be a real device running Skopin, not a drawing of one.
On a control device, Skopin runs a fast, repeating scan cycle - on the order of 120 ms. Sensor conditions become read-only guards in the model. And because behaviour is Petri-net semantics, unsafe interlock states are made structurally unreachable rather than checked at runtime. That is a stronger guarantee than a runtime "if unsafe, stop": the dangerous state has no path to it in the model at all. Safety by construction.
Put the ladder and the edge together and the shape is clear. A Continuous rung is exactly what you want for a device that watches a line on its own - but the money and account-security cap still holds, the side-effect class the operator granted still holds, and the interlocks that would be dangerous are not merely forbidden, they are unreachable. The reference hardware for this, Reflex, is a small Linux board with the radios to reach real sensors and actuators. The family framing is worth keeping in mind: Priostack orchestrates, Skopin executes at the edge, Reflex anchors it in the physical world - and the autonomy a person granted travels intact from the phone to the field.
8. Software that wants you gone
Step back from the mechanism and the ethic is straightforward. Most consumer software is built to want your evening - to maximise the time you spend inside it. The autonomy ladder is built for software that wants you gone: it works out what deserves your attention, asks before it acts, and gets out of the way.
Every piece of the design pushes in that direction. Declaring the ceiling up front respects that you are the one deciding. The min rule means your caution is never overridden. Side-effect classes mean you are never surprised by the kind of consequence you agreed to. The Confirm cap means the two most dangerous powers always pause for you. And the honest limit underneath all of it - "it only knows what you tell it" - is a promise about the floor, not just the ceiling. The software is not quietly learning more about you to earn a higher rung. It operates on what you gave it, at the level you granted, and stops when you say stop.
Conclusion
The autonomy ladder is a small idea with a lot of weight resting on it. Five named rungs, from Suggest to Continuous. Two dials that stay separate, with the lower one always winning. A set of side-effect classes you see before you agree. And one firm cap that keeps money and account security at Confirm for everyone. None of it depends on trusting the app's good behaviour, because the engine that runs the app's models is the same engine that enforces the limits - on the phone, in the browser, and on a Skopin device in the field.
It is not the most permissive way to build software. It is not meant to be. It is a way to build software that a person can hand real work to without handing over the keys - software that asks first, tells you what it did, and stops when you want it to. That is the whole point, and we are comfortable calling the cap a virtue rather than a limitation.