/problem
Superapps absorb how a business runs
Platforms and vendor AI agents take on more than tasks. Over time they hold three things a business needs back if it ever wants to leave. Regulators in the EU, Australia and Singapore increasingly expect regulated firms to manage that concentration and keep a workable exit plan.
Process logic
The steps, thresholds and exceptions end up configured inside the vendor's product, in a format only that product can read.
Context
What the business has learned about its customers and cases accumulates in the vendor's systems and doesn't come home.
Authority
The vendor's permission model decides what may happen and who approves it. Leaving means redesigning who is allowed to act.
/how
Own the nouns, rent the verbs
A process calls a capability, never a vendor. Vendors, internal systems and human teams fulfil capabilities through standard contracts, so adding or replacing one is configuration rather than a rebuild.
Seven archetypes
Domains are numerous; interaction shapes are few. Every capability is one of seven, which fixes what its responses must carry.
checkextractgeneratetransactretrievenotifyhuman_taskOne envelope
Every call carries the same fields: trace and idempotency keys, leased input, evidence, confidence, cost, the action's reversibility class and the reason for the route.
Two-stage routing
Hard rules first and never traded off: an unapproved supplier or the wrong data region is excluded before anyone is scored. Scores only choose among the survivors, and low confidence escalates to a human team.
A context lease
A supplier receives only the fields its contract declares, for that one call. Everything else stays in the business's own event log.
One authority gate
Every action passes one checkpoint that asks how hard it would be to undo, using the R0–R4 classes from our Reversibility Classes project. Unknown capabilities fail closed.
A reference runtime
A minimal control plane shows it working: router, authority gate, context lease, event log and conformance checks, with simulated suppliers. Its event log exports to OCEL 2.0 for process-mining tools.
/scorecard
How dependent is each critical process?
Start by measuring, before adopting anything. The Exit-Readiness Scorecard rates each critical process on seven measures, and rates it by its weakest one, because an exit fails at its weakest point.
- Where the rules live: in your own specifications, or in the supplier's product
- Whether learned context can leave with you
- Whose permission model governs actions
- Supplier-only dependencies nobody else can provide
- Contract exit terms, including notice periods
- Time to swap: contracting, onboarding and cutover, estimated or proven
- A fallback supplier that exists today
Across critical processes it shows the share each supplier serves and flags any above your concentration limit. Every answer carries an evidence level, and each measure shows its weakest:
Try it in your browser
Rate one critical process
- Download the form (
opcp-exit-readiness-form-0.3.0.html) from the 0.3.0 release and open it in any browser. It works offline, and nothing you type leaves your device. - Answer the three triage questions. Only critical processes need the full set of 22. Each question says who is best placed to answer it and what evidence would support the answer.
- Download your answers and turn them into a one-page report, or a two-page readout for the sponsor's decision meeting.
# Python 3.10+, from the downloaded OPCP folder
pip install .
opcp scorecard run answers.json -o report.html
opcp scorecard readout answers.json -o readout.html
Want to see the output first? The release also has an example report and readout for a hypothetical bank. No network calls, no telemetry; each report is a single HTML file.
The 22 questions cite 74 clause-level references across 15 sources, including DORA and its technical standards, the EU Data Act, EBA, APRA CPS 230, MAS, the PRA and NIST. Already filing a DORA register of information? opcp scorecard export suggests register values with the reasoning for each, for your review. Running it across several processes? The repo has a six-week pilot plan.
/swap-drill · new in 0.3
Swaps are proven, not promised
A candidate supplier runs in shadow beside the incumbent, on the same contract and the business's own regression cases. The drill passes only if every gate holds. A passed drill is what turns a time-to-swap from an estimate into a proven figure, with a date on it.
Process unchanged
The business's process definition is the same before and after.
Context lease unchanged
The candidate receives no field the incumbent didn't.
Authority unchanged
The same actions need the same approvals.
Contract conformance
The candidate passes the capability contract's conformance checks.
Regression cases pass
Business-owned cases, not the supplier's own demo set.
No exception downgraded
A case the business expects to fail or refer must not quietly pass.
/status
Where it stands
A draft for comment. The specification, schemas and tools will change based on feedback, and we'd rather hear what's wrong now.
- Specification
Archetypes, envelope, contracts, routing, authority gate, context lease, scorecard and conformance, with JSON Schemas and five example contracts.
draft for comment - Exit-Readiness Scorecard
Offline form, 22-question bank with evidence levels, one-page report, sponsor readout and DORA register suggestions.
working - Swap drill
Normative specification, schema, and a deterministic evaluator that reports pass or fail, gate by gate.
working - Reference runtime
A minimal control plane with simulated suppliers, to show the ideas working together. Not for production.
demonstration - Package on PyPI
Install from the release or the source folder for now.
not yet - A pilot with a regulated firm
Running the scorecard and a swap drill on real critical processes.
still needed
What we are not claiming
- A report is a self-assessment against a published method, not a certification.
- References show which obligations a question relates to, not compliance with them. Check each locator against the official text before relying on it.
- Nothing here is legal or regulatory advice.
What comes next
- Pilot the scorecard with a regulated firm.
- Run a first swap drill on a real capability, so a time-to-swap is proven.
- Bring in maintainers from other organisations, so no single one employs more than half of them.
- Decide, before 1.0, whether the specification moves to a licence designed for specifications.
/open
Built so it can't become the next lock-in
A framework against concentration risk would be hollow if it could become one. Its openness is designed to be hard to reverse.
- Apache 2.0 throughoutThe specification, schemas, catalogue and code, with a patent licence from each contributor.
- No contributor licence agreementContributions come under the DCO and contributors keep their copyright, so no single party can relicense the project.
- Specification before implementationOur runtime is one implementation. Conformance is defined by public tests any other implementation can pass.
- A path to a neutral foundationThe specification, code and name go to a neutral foundation once maintainers from three organisations are active. Governance.
Get involved
Rate one process with us
Operations, risk, legal and procurement expertise is as useful as code. We are looking for:
- a regulated firm willing to pilot the scorecard on a few critical processes;
- reviewers who will tell us where a question or a reference is wrong;
- suppliers willing to run a swap drill against a published contract.