This directory carries the v0.1 specification documents for Ardur's protocol layer, MCEP (Mission-Controlled Execution Protocol). v0.1 is a pre-release series — the specs describe the intended protocol shape; the public code that implements them is being curated in phases per docs/public-import-plan.md.
The MCEP acronym was expanded as "Mission-bound Cryptographic Evidence Protocol" in earlier learn-MCEP teaching material; the formal v0.1 specs use "Mission-Controlled Execution Protocol" and that is the canonical expansion going forward. Articles and other public prose follow the spec form.
Public-surface import caveat. The migrated specs were authored in a private context and may reference implementation source paths (e.g. vibap-prototype/vibap/passport.py), private session artifacts (e.g. docs/session-2026-04-XX/...), or internal review trails that have not yet landed in this public repo. Treat such references as pointers to future work — the underlying code lands alongside the Phase 1 import per the public import plan. Contributors cannot verify those referenced artifacts from the public tree today. Same caveat as the decisions index.
Runtime implementation caveat. The v0.1 specs define intended protocol semantics for mission-declared lineage_budgets, but the current public runtime does not yet compile or verify those mission-level declarations. Today, delegation budget reservations use the file-backed FileLineageBudgetLedger, while non-empty mission-level lineage_budgets fail closed at compile/issue time instead of being silently accepted.
| Spec | Status | Notes |
|---|---|---|
| Conformance Profiles | migrated | Public-import annotated |
| Delegation Grant (DG) Profile of AAT | migrated | Public-import annotated |
| Verifier Contract | migrated | Public-import annotated |
| Mission Declaration (MD) | migrated | Public-import annotated; clean-break protocol rename applied (application/ardur.md+jwt, https://ardur.dev/...) |
| Execution Receipt (ER) | migrated | Public-import annotated; clean-break rename applied (application/ardur.er+jwt) |
| Execution Receipt EAT/CWT Profile | migrated | Public-import annotated; clean-break rename applied |
| IDM Extension Profile | migrated | Public-import annotated; clean-break rename applied (application/ardur.idm+jwt) |
| Revocation Model | migrated | Public-import annotated; clean-break rename applied |
| Mission Declaration schema | migrated | JSON Schema; $id rebased to ardur.dev |
| Execution Receipt schema | migrated | JSON Schema; $id rebased to ardur.dev |
| Host adoption/governance source-semantic vectors | starter vectors | No-key Codex, Claude Code, Gemini CLI, OpenAI Agents SDK, and ToolHive source-semantic rows; explicitly not live-host proof. |
The v0.1 specs originally embedded a legacy product/project name in their JWT media types (application/<legacy>.er+jwt) and $id URIs (https://<legacy>.io/...). The rename decision: clean break, no dual-type support. New canonical identifiers in this public series:
| Identifier kind | Old | New |
|---|---|---|
| Mission Declaration JWT type | application/<legacy>.md+jwt |
application/ardur.md+jwt |
| Execution Receipt JWT type | application/<legacy>.er+jwt |
application/ardur.er+jwt |
| IDM Extension JWT type | application/<legacy>.idm+jwt |
application/ardur.idm+jwt |
Schema $id URI base |
https://<legacy>.io/spec/... |
https://ardur.dev/spec/... |
The clean-break rationale: there are no v0.1 receipts, passports, or attestations in third-party hands — all empirical artifacts under this series stay private (the paper, internal benchmarks). Backward-compat dual-type would have added implementation complexity for zero observed callers. If receipts in the wild appear later, a v0.2 with dual-type support is the right answer at that point.
- Mission Declaration (MD) — the signed scope envelope the agent starts with
- Delegation Grant (DG) Profile — how child agents get strictly narrower authority
- Execution Receipt (ER) — the signed per-tool-call decision record
- Execution Receipt EAT/CWT Profile — RFC 9711 binding for ER carriage
- Verifier Contract — what a conforming verifier must do
- Conformance Profiles — tiered conformance matrix (Delegation-Core, MIC-State, MIC-Evidence, IDM Extension)
- Revocation Model — layered revocation across delegation, session, credential, and transparency-log layers
- IDM Extension Profile — Intent-Declaration-Manifest experimental profile
- AAT (Attenuating Authorization Tokens) — IETF OAuth WG draft; MCEP's Delegation Grant is an AAT profile.
- EAT (Entity Attestation Token, RFC 9711) — used by the ER EAT/CWT profile to carry Execution Receipts.
- SPIFFE — workload identity substrate; MCEP binds mission credentials to SVIDs.
- Biscuit — first-party-attenuation credential format; the DG profile's narrowing semantics rely on Biscuit's append-only block model (see ADR-017).
These are real artifacts, not codenames. Their names stay in the specs as technical lineage.
- Versioning: v0.1 is the pre-release. The next revision (v0.2 or later) lands after the protocol-level rename decision + one round of adversarial review against the migrated public specs.
- Normative language: MUST / SHOULD / MAY usage follows RFC 2119 / RFC 8174.
- Updates: specs don't mutate in place; a material change opens a new version file and leaves the prior version immutable for citation stability.