ARP Standard
Versioned contracts for bounded, auditable capability execution
ARP Standard v1 defines the node-centric HTTP+JSON contracts for bounded execution: run entrypoints, run authority, executors, registry, selection, and policy decisions.
What the Standard gives you
Normative contracts
OpenAPI + JSON Schema define strict request/response shapes and required endpoints for conformance.
Clear execution boundaries
Clear service responsibilities so you can swap implementations without changing the integration surface.
Portability without lock-in
Any compliant client can talk to any compliant component, enabling multiple implementations and deployment choices.
Execution boundaries
Clear service responsibilities (you can swap implementations without changing the integration surface):
- Run Gateway (client entrypoint)
- Run Coordinator (run authority + enforcement points)
- Atomic Executor (execute atomic NodeRuns)
- Composite Executor (execute composite NodeRuns)
- Node Registry (capability catalog)
- Selection (bounded candidate sets)
- PDP (policy decisions; optional)
What the Standard does not specify
To stay interoperable and implementation-agnostic, the Standard intentionally does not define:
- Planner algorithms or prompting strategies.
- Deployment defaults (ports, storage engines, hosting topology).
- CLIs, UIs, or operational dashboards.
- Provider-specific integrations.
It standardizes the seams: contracts, artifacts, and enforcement points.
Conformance: how “portable” becomes real
“Conformant” means:
- Required endpoints exist.
- Payloads validate against the published schemas.
Conformance is what allows:
- Multiple implementations of the same component.
- Safe upgrades across versions.
- Confidence that integrations don’t require bespoke glue.