AAECP is the execution governance layer of the Ardyn platform. Every autonomous action flows through pre-execution authorization, independent post-execution verification, and autonomous closure — governed at every step by Forge authority, Axiom policy, and AEA evidence.
An autonomous agent requests an action. Forge confirms the agent holds valid authority. Axiom confirms organizational policy permits the action. The question remains: how does the action actually execute under durable governance — with pre-execution authorization, independent post-execution verification, and autonomous closure — such that human intervention is only required for genuine hard stops?
Autonomous execution without governance is automation. Execution with governance — where every action is authorized before it runs, verified after it completes, and merged or closed based on evidence — is governed autonomous execution. AAECP answers: how can an organization run autonomous systems at scale without losing control?
AAECP (Ardyn Autonomous Execution and Control Protocol) is the execution governance layer of the Ardyn platform. It provides the pipeline through which autonomous actions flow from authorization to verification to closure, governed at every step by Forge authority, Axiom policy, and AEA evidence.
Historical note: AAECP replaces PREMP (Policy-Governed Remediation and Execution Protocol), the historical program name that preceded it. PREMP was an early prototype that demonstrated the concept of policy-governed execution with human escalation. AAECP is the production evolution: a generalized execution protocol that integrates the full Ardyn stack — Forge identity and authority, Axiom policy evaluation, AEA evidence artifacts, and ATP trust profiles — into a single governed execution pipeline.
The core operating principle: human escalation is reserved for genuine hard stops. In PREMP, the default was to escalate to a human when anything unusual happened. In AAECP, the default is to execute autonomously under policy, and escalate only when policy explicitly demands it or when pre-execution authorization fails.
Deploy an agent, give it tools, and let it run. This approach offers speed but zero governance. When the agent makes a mistake, there is no record of why, no mechanism to stop it mid-flight, and no way to verify what happened. The organization has ceded control.
Every agent action requires a human to approve. This preserves control but eliminates the speed and scale benefits of autonomy. A claims-processing system that processes 500 claims per hour cannot have a human reviewing each one.
Systems like Zapier, Temporal, and Airflow orchestrate deterministic workflows — step A, then step B, then step C. They work for known processes with known inputs. They break when the agent must decide what to do based on novel conditions, or when governance requires evaluating trust evidence rather than following a static flow.
A set of static rules baked into the agent's code. These are fragile, hard to update, and invisible to auditors. They cannot reference the agent's trust profile, cannot adapt to changing risk conditions, and cannot produce evidence of their own operation.
AAECP provides governed execution that is policy-driven (not hardcoded), evidence-backed (not blind), autonomous by default (not human-bottlenecked), and traceable at every step.
AAECP defines a three-phase execution pipeline:
┌──────────────────────────────────────────────────────────────────┐ │ AAECP Pipeline │ │ │ │ Action Request │ │ │ │ │ ▼ │ │ ┌──────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Forge │───▶│ Axiom │───▶│ Bind │ │ │ │Authority │ │ Policy │ │ Action │ │ │ └──────────┘ └─────────┘ └────┬────┘ │ │ │ │ │ ALLOW │ ESCALATE / BLOCK │ │ │ ▼ │ │ │ ┌──────────┐ │ │ │ │ Human │ │ │ │ │ Review │ │ │ │ └────┬─────┘ │ │ ▼ │ │ │ ┌────────────┐ │ │ │ │ Execute │◄─┘ │ │ └─────┬──────┘ │ │ │ │ │ ▼ │ │ ┌──────────┐ ┌─────────┐ ┌─────────┐ │ │ │ Produce │───▶│ Verify │───▶│ Merge │ │ │ │AEA / DDC │ │ Content │ │ / Close │ │ │ └──────────┘ └─────────┘ └─────────┘ │ │ │ └──────────────────────────────────────────────────────────────────┘
An engineering organization operates autonomous agents that manage cloud infrastructure. Agent infra-04 is authorized to provision, modify, and deprovision compute resources under a governed execution policy.
1. Pre-execution authorization: Forge verifies infra-04 holds provision_compute authority grant — valid. Axiom evaluates policy: "allow provision_compute if hardware_tier >= transport_attested AND estimated_cost < 500" — agent's ATP shows 100% transport-attested execution, and the database instance costs $320. Result: ALLOW. Action bound to nonce 0xa3f2 and recorded as AEA aea_provision_auth.
2. Independent verification: The provisioned resource is captured as AEA aea_provision_result with tool name, parameters, resource ID, and timestamp. Content digest matches. Signature verifies. The executed action matches the authorized action — no discrepancy.
3. Autonomous closure: Task marked complete. Governance trace closed: aea_provision_auth → aea_provision_result. No human involvement. Full evidence recorded.
Contrast with PREMP: In the historical PREMP model, the same action would have routed to a human operator for confirmation before execution. PREMP treated every action as a remediation task requiring human oversight. AAECP treats governed actions as autonomous by default and escalates only when policy demands it.
1. Pre-execution: Axiom evaluates — cost exceeds $500 threshold. Result: ESCALATE.
2. Action routed to an infrastructure engineer with the full evidence package: agent identity, action details, cost breakdown, and current infrastructure state.
3. Engineer reviews and approves. Approval recorded as a governance AEA. Action proceeds through the same verification and closure pipeline.
AAECP calls Forge's authorize_transition. It does not define who has authority or how authority is structured. That is Forge's domain.
AAECP calls Axiom for policy evaluation. It does not define the policy rules themselves. That is Axiom's domain.
AAECP governs the execution — it does not provide the runtime, tooling, or compute environment where the agent runs.
AAECP refers to ATPs during pre-execution authorization. It does not produce or modify trust profiles. That is ATP's domain.
AAECP requires Forge and Axiom to be configured. It is the orchestration layer, not a standalone system.
| Direction | Layer | Role in AAECP |
|---|---|---|
| Upstream | Forge | Provides the authorize_transition interlock — must pass before any action proceeds. AAECP Phase 1 starts with Forge. |
| Upstream | Axiom | Evaluates policy and renders ALLOW / BLOCK / ESCALATE / DEFER. AAECP Phase 1 calls Axiom after Forge. |
| Upstream | ATP | Provides the agent's trust profile, which Axiom consumes during policy evaluation. |
| Downstream | AEA | Every action in AAECP produces an AEA — authorization AEAs, execution result AEAs, and human decision AEAs all flow into the evidence pipeline. |
| Downstream | ACTA | AAECP's governance traces feed into organizational cognition. |
| Lateral | Verification | AAECP Phase 2 uses the same verification primitives as the broader platform: content digest validation, signature verification, policy compliance checking. |
The authorization AEA records all inputs to the Forge and Axiom checks. A verifier can replay the authorization: was the authority grant valid? Did the policy evaluate correctly? Would the result be the same if re-evaluated with the same inputs?
The execution AEA and the authorization AEA are linked via previous_artifact_digest. A verifier can confirm that the action that executed is the action that was authorized.
An auditor can re-run the entire pipeline: take the action request, feed it through Forge and Axiom, compare the expected decision to the recorded decision, verify the execution AEA, and confirm the closure trace. The full pipeline is deterministic — same inputs produce the same outputs.
LIVE AAECP is LIVE as the production autonomous execution layer — implemented in Kylewilson04/forge @ c844406. The AAECP controller is running, the premp-authz bridge integrates Forge's pre-execution interlock, and all legacy PREMP operations are preserved via compatibility wrappers. PREMP is the historical program (48-task remediation, completed and immutable). AAECP is the current and future execution governance layer.
authorize_transition() implemented in ardyn-tool-authority (18 tests). Called by premp-authz bridge as first gate in AAECP pipeline. Checks identity, authority grants, policy digest, evidence, and attestation.
4 commands: prepare, authorize, consume, verify. Integrates Forge interlock + AEA adapter. Produces signed AEA envelopes on ALLOW. Single-use authorization tracking. CLAIM-LEDGER #11-13.
In-process in Core gateway.
FORGE-11 Phase 1. 96 tests, PR #21. Envelope signing and verification operational.
Spec defined. Not yet in live code. (See CLAIM-LEDGER: "Spec only, not in live code.")
AAECP is the running production controller. The premp-authz bridge implements the pre-execution authorization phase: action preparation → authorize (Forge interlock) → AEA envelope production → consume (single-use enforcement) → verify (offline verification). The full three-phase pipeline (authorization → verification → closure) is defined in architecture; Phase 1 (pre-execution authorization) is live, Phases 2-3 (independent verification, autonomous closure) are implemented in code but awaiting full production integration.
AAECP is one layer in the Ardyn trust plane. Each linked layer plays a specific role in the governed execution pipeline.