For developers

One engine. Two ways to build on it.

Priostack is a product people use every day. This page is for the people who build on it. There are two ways to do that - pick the one that matches what you are making.

Priostack's app asks its users before it acts. We try to be just as plain with you. · Not here to build? Use the app →

Path A · for Priostack's users

Publish an app

Build something a Priostack user can find, grant, and trust - inside the app they already use.

Is this you? You are shipping an app or service for other people. Model-only bundles count too.

Declare a capability contract: what your app can do, and the most autonomy a user is ever allowed to grant it.
Autonomy runs from Suggest to Continuous. The user always grants no more than you allow, and anything touching money or account security is capped at Confirm.
Ship model-only apps - no backend, no code. The same bundle runs as a native mobile app, a PWA in the browser, and on edge devices via Skopin, Priostack's edge OS.
Priostack carries discovery, the consent prompts, and billing. You carry what your app does.

Publish an app How the contract works ↓

Path B · for yourself

Build on the API

Use Priostack's execution engine in your own project, in any language, over plain HTTP.

Is this you? You are building for yourself, your team, or a client. Your workspace, your key, your data.

Deploy processes, decisions and cases, then drive them with real endpoints. No SDK, no framework to adopt.
Evaluate a decision, start an instance, activate and complete jobs, open a case, read incidents - all over HTTP.
Built on standards you already know: BPMN 2.0, DMN 1.3, CMMN 1.1, ArchiMate 4.0.
Free sandbox: 100 credits a month, no card. It is a real quota, not a trial timer.

Get a sandbox key Read the docs

Which door is mine?

If you are still deciding, match your goal to a path.

"I want Priostack users to use my thing."

That is Publish an app.

"I have a project or a client to build for."

That is Build on the API.

"I only have models, no code."

Still Publish an app - ship the models on their own.

Doing both is normal. Publish an app for Priostack's users and use the API for your own work at the same time - one account, one key, both doors open.

Path A · Publish an app

You decide the ceiling. The user decides the rest.

An app declares the most autonomy it can ever be given. The user grants some amount up to that. What actually runs is the lower of the two - never more than a person chose.

Level 0

Suggest

Proposes. Never acts.

Level 1

Prepare

Drafts it. You send it.

Level 2 · cap

Confirm

Asks before each action.

Level 3

Delegated

Acts within limits, tells you after.

Level 4

Continuous

Runs on its own. You can stop it.

Anything touching money or account security is capped at Confirm, whatever an app declares. That ceiling is the platform's, not an app's to raise - the same protection that guards your own users guards everyone's.

Each capability names its side-effect

read_only reversible_local external_communication financial_commitment account_security high_stakes

The two in orange are the capped ones. A user sees the side-effect before they grant anything.

Publish an app See a worked example

Path A · one app, every surface

Write it once. It runs where the person is.

A Priostack app is models, not code - what it looks like, what it does, what it decides. Because it is models, the same app renders wherever it is opened. You do not build three clients.

A mobile app

On Android and iOS the views are drawn by a native renderer. It installs and opens like any other app, and it still works with no signal - what a person is looking at lives on the device.

A PWA in the browser

On the web the same views render in JavaScript, installable as a PWA. One bundle, one behaviour - no separate web build to keep in step.

An edge device, on Skopin

Out on the ground, models run on Skopin - Priostack's Linux edge OS. A device enrols with its own identity, receives its models and policies from Priostack, and reports its real state back. A technology Node in your model can be a real device in the field.

The interactive layer runs on the device, so a tap never waits for the network. The durable logic - processes, decisions and cases - runs on the engine, or on a Skopin edge node when it has to act in the physical world.

Path B · Build on the API

Deploy a model, then drive it over HTTP.

No cluster to run, no SDK to install. Point any HTTP client at the endpoints and go. Here is the whole shape of it.

# 1 · evaluate a decision table
POST /api/v1/decisions/{id}/evaluate

# 2 · deploy a process, decision or case model (multipart)
POST /api/v1/process-definitions

# 3 · start an instance, pass your variables
POST /api/v1/process-instances

# 4 · your worker does the real work, then completes the job
POST /api/v1/jobs/activate
POST /api/v1/jobs/{key}/complete

# 5 · open a case when a process is the wrong shape for the work
POST /api/v1/cases

Get a sandbox key Run the tutorial OpenAPI spec →

Two doors, one house

The same engine is under both

Whichever door you take, you are building on the same foundation. Neither path is the lesser product.

The Qubit engine

Runs your BPMN, DMN and CMMN models natively - the same runtime behind the app and the API.

Geometric memory

A context store that remembers the shape of what has happened, so behaviour can be compared against what is normal - not just the last event.

The same consent model

The autonomy ladder that protects app users is the same idea that keeps the API honest: nothing acts beyond what was granted.

Straight about the limits

What we don't do

Honesty is the differentiator, so here it is plainly.

No uncapped autonomy. Money and account-security actions stop at Confirm. There is no setting that lifts that.
No silent data access. On Path B, nothing leaves your workspace unless you send it. On Path A, a user sees each capability's side-effect before granting it.
No lock-in on your models. Your BPMN, DMN and CMMN are standard XML. They run here and they run anywhere compliant.
No invented guarantees. We do not promise you an audience, a payout, or a ranking. We give you the contract, the endpoints, and the consent model - the rest is your app.

Straight answers

Before you pick a door

Can I do both - publish an app and use the API?

Yes, and it is common. One account and one key cover both. Publish an app for Priostack's users, and use the API for your own or a client's project in parallel.

What exactly is a capability contract?

It is the declaration your app registers: each thing it can do, that action's side-effect class, and the highest autonomy level a user is ever allowed to grant it. Priostack enforces it - a user can grant less, never more.

Do I need to run a server to publish an app?

No. Model-only apps are welcome: ship BPMN, DMN, CMMN, ArchiMate, Camel or IFML with no backend of your own. If your app does need to run code, it can - but it is not required.

Why is autonomy capped at Confirm for money and accounts?

Because a person should be in the loop for anything that spends money or changes account security, no matter how much they trust an app. It is a platform rule, not an app setting - the same cap protects every user, including yours.

What happens when I run out of the free sandbox credits?

The sandbox is 100 credits a month with no card. It is a real monthly quota, not a countdown to a paywall - it refreshes each month. When you need more, pricing covers the paid tiers.

Which language do I use for the API?

Any language that can make an HTTP request. There is no SDK to adopt and no framework to buy into. The full surface is in the OpenAPI spec.

Pick a door

Nothing else to decide first.

For Priostack's users

Publish an app

Ship it to the people already using Priostack.

Publish an app

For yourself

Build on the API

Get a key and run the tutorial in minutes.

Get a sandbox key

Not building anything today?

Priostack is a product you can just use - it works out what deserves your attention, and asks before it acts.

Open the app →