The binding protocol between host systems and process runtimes.
UAPF-IP is an open protocol that lets any host system — a SaaS application, an enterprise backend, an IoT gateway, an AI agent runtime — interoperate with any conforming process execution engine without writing custom integration code per pair.
It does for process execution what the Language Server Protocol did for language tooling and what the Model Context Protocol does for AI agent tools: it dissolves an N×M integration problem into a 1×N + 1×M problem against a single specification.
UAPF-IP is part of the broader UAPF (Unified Algorithmic Process Format) ecosystem. UAPF specifies what a process is — a portable BPMN+DMN+CMMN package with manifest, resources, and metadata. UAPF-IP specifies how a process runs against a host — capability registration, callback routing, event emission, audit.
Every workflow engine on the market — Camunda, Temporal, Zeebe, Flowable, Airflow, AWS Step Functions, Argo, n8n, and the proprietary engines inside Salesforce, ServiceNow, Pega, Appian, and SAP — has invented its own integration API. Each has its own task-worker pattern, its own callback shape, its own auth model, its own event format. An enterprise that adopts one of them writes a custom adapter layer between their existing systems and that engine. When they switch engines, the adapter layer is thrown away and rewritten.
The same problem in language tooling was solved in 2016 by the Language Server Protocol. Before LSP, N editors needed N×M custom integrations with M language compilers. After LSP, each editor implements one client; each language ships one server; everything composes.
UAPF-IP is the same move for process execution.
The core abstraction is capabilities.
A host system declares what capabilities it offers — read these data, assign these tasks, fetch these documents, invoke these AI models, emit these events. The declarations are versioned, schema-validated, and bound to standard reserved namespaces (task.*, data.*, document.*, ai.*, event.*) or to user-defined namespaces (com.acme.warehouse.*).
A process declares what capabilities it needs to run.
The runtime matches them at process start. If the host doesn't offer what the process needs, the process refuses to start — fail-fast at the boundary, never deep in execution.
During execution, the runtime invokes host capabilities through callbacks; the host invokes process operations through the SDK. Both directions are signed (DID-VC) and logged (CloudEvents-shaped audit records).
┌──────────────────────────┐ ┌──────────────────────────┐
│ Host System │ │ Process Runtime │
│ (SaaS / app / agent) │ ◀────▶ │ (engine + UAPF package) │
│ │ │ │
│ declares capabilities │ │ declares needs │
│ ↓ │ │ ↓ │
│ task.assign@1 │ │ requires task.assign@1+ │
│ data.read@1 │ │ requires data.read@1+ │
│ ai.classify@1 │ │ requires ai.classify@1+ │
└──────────────────────────┘ └──────────────────────────┘
│ │
└──────── UAPF-IP binding ───────────┘
(REST | MCP | gRPC | queue)
UAPF-IP is in the same tier as LSP, MCP, OPA, and CloudEvents — protocols that abstract a specific N×M problem into a single specification.
| Protocol | Decouples | Year introduced |
|---|---|---|
| LSP | Editors × language services | 2016 |
| OPA / Rego | Applications × policy engines | 2016 |
| CloudEvents | Event producers × consumers | 2018 |
| MCP | AI agents × tools | 2024 |
| UAPF-IP | Host systems × process runtimes | 2026 (draft) |
It is complementary, not competitive, with these:
- MCP exposes AI tools to agents; UAPF-IP exposes process runtimes to hosts. A UAPF capability can be fulfilled by an MCP server (MCP is one of the supported bindings).
- OPA decides policy; UAPF-IP runs process. An OPA decision can be invoked through a
policy.evaluatecapability inside a UAPF process. - CloudEvents shapes events; UAPF-IP emits events in CloudEvents format.
- BPMN/DMN/CMMN (OMG) specify what a process model looks like; UAPF-IP specifies how it executes against a host. UAPF packages contain BPMN/DMN/CMMN as their workflow notation.
It is not:
- A workflow engine. Any conforming engine — Camunda, Temporal, Zeebe, Flowable, or new implementations — can implement UAPF-IP on its host-facing side.
- A process modeling language. UAPF (the format) handles that.
- An AI orchestration framework. LangGraph, CrewAI, AutoGen and similar can consume UAPF processes through the protocol.
The v0.1 worked example is SRE incident response — a pager fires, a process kicks off, it reads from monitoring systems, drafts an initial triage with an AI capability, assigns work to an on-call engineer, sends notifications, invokes a remediation runbook, and records everything for post-incident review. Familiar to every engineer reading this cold, naturally federated across multiple SaaS APIs, exercises all three v0.1 conformance profiles.
See examples/sre-incident-response/.
Additional non-normative examples covering insurance claims, hospital discharge, manufacturing quality control, and bank loan origination land in examples/ over the v0.1 cycle.
| Project | Language | Role | Status |
|---|---|---|---|
uapf-engine |
TypeScript | Reference runtime | v0.1 in progress |
uapf-typescript |
TypeScript | Host SDK | v0.1 in progress |
uapf-mcp |
TypeScript | MCP binding adapter | v0.1 complete |
uapf-python |
Python | Host SDK | v0.2 planned |
uapf-go |
Go | Host SDK | v1.0 planned |
Reference host adapters land in UAPFormat/uapf-host-adapters for Salesforce, Jira, GitHub, a generic Postgres-backed application skeleton, and one document management system exemplar.
v0.1 — current draft. Capability specification for the five reserved namespaces (task.*, data.*, document.*, ai.*, event.*). Session lifecycle. CloudEvents-shaped audit. REST+JSON normative binding plus MCP informative binding. Three conformance profiles: Synchronous Decision, Orchestrated Process, Federated Multi-Runtime. One fully-worked example (SRE incident response). Conformance criteria.
v0.2. Additional reserved namespaces (notify.*, identity.*, time.*, process.*). gRPC binding. Queue binding (NATS, Kafka shapes). Long-running session profile. Two additional fully-worked examples.
v1.0. Stable specification. Three reference implementations across three languages. At least five production adopters across at least three industries. Standards-body track decided.
Three audiences:
Building a host system? Implement five callback endpoints and you're a UAPF host. Start with bindings/rest/host-checklist.md.
Building a process runtime? Implement the runtime side of the REST binding plus capability matchmaking. Start with bindings/rest/runtime-checklist.md.
Authoring a process? Use any BPMN/DMN/CMMN tool, package per the UAPF specification, declare your capability needs in the manifest. Start with examples/sre-incident-response/.
UAPF-IP is developed in the open under the UAPFormat GitHub organization. Issues, pull requests, and proposals are welcome. Substantial design changes go through a public RFC process under rfcs/.
The protocol's eventual standards-body affiliation is intentionally undecided at v0.1. Candidates include OMG (where the existing BPMN/DMN/CMMN ownership sits), CNCF (cloud-native framing), and W3C (web-standards framing). The choice will be made once v0.1 has stabilised with non-author adopters in production.
MIT. The protocol itself is unencumbered; reference implementations and adapters are MIT-licensed.
UAPF-IP grew out of practical work on AI-driven process automation in regulated environments and from validation against real adopters spanning case management, regulatory compliance, healthcare, manufacturing, and software operations. Early validation runs under Latvia's national AI regulatory sandbox programme — a controlled environment that allows the protocol to be exercised against high-risk AI use cases under regulator supervision. This validation work informs the specification but does not constrain it: UAPF-IP is designed as protocol-layer infrastructure for global enterprise IT, not as jurisdiction-specific tooling.