ActionSpecs Protocol Specification

Version: 1.0-draft

Author: Adekka Canada Inc., Toronto, Canada

Publisher: Adekka Canada Inc.

Status: Draft for publication

License: This specification is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). Anyone may implement this protocol. Attribution to Adekka Canada Inc. is required when reproducing or adapting this document.

Copyright: © 2026 Adekka Canada Inc. Licensed under CC BY 4.0.

Abstract

ActionSpecs is a protocol for governing consequential operations performed by or through automated systems. It defines a nine-stage lifecycle under which every governed operation is declared in a machine-readable form (an ActionSpec), evaluated against versioned machine-readable policy, issued an explicit verdict before execution, and bound to a cryptographically linked pair of evidentiary records: one proving what was authorized, one proving what occurred.

The protocol rests on a single invariant:

A consequential operation must not occur without a policy verdict, and no verdict or outcome may exist without a receipt.

ActionSpecs is domain-agnostic. It applies wherever automated operations require authorization, enforcement, and evidence: autonomous AI-agent actions, multi-sensor data fusion, financial transaction execution, infrastructure control, and other regulated or high-consequence domains. Domain bindings are defined in application profiles (Section 11).

1. Motivation

Automated systems increasingly perform operations whose consequences are significant: moving money, merging classified data, actuating physical systems, executing decisions at machine speed. Existing authorization mechanisms answer only the question "may this occur?": they issue a decision and retain no binding between that decision and what subsequently executed. The gap between what was authorized and what actually occurred is therefore invisible, and that gap is precisely where compliance failures, security compromises, and liability disputes live.

ActionSpecs closes that gap structurally. It treats authorization not as a point-in-time answer but as a lifecycle: declaration, validation, verdict, constrained execution, verification, and evidence. The result is a system in which every governed operation carries a complete, tamper-evident, independently verifiable account of its authorization and its outcome.

2. Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHOULD, and MAY in this document are to be interpreted as described in RFC 2119.

• Action: a consequential operation subject to governance.
• ActionSpec: the machine-readable declaration of a proposed Action (Section 5).
• Principal: the identified entity (human, service, agent, or pipeline stage) requesting an Action.
• Policy Bundle: a versioned, signed set of machine-readable policy documents (Section 7).
• Verdict: the explicit decision issued for an ActionSpec (Section 6).
• PDP (Policy Decision Point): the component that evaluates ActionSpecs against active policy and issues Verdicts.
• Enforcement Executor: the component that applies verdict constraints by performing required transformations itself, rather than instructing the governed workload to do so.
• PROA (Proof of Authorization): the evidentiary record issued at verdict time (Section 8.1).
• PROOD (Proof of Operation and Delivery): the evidentiary record issued after execution (Section 8.2).
• Receipt Ledger: the append-only, hash-linked store of PROAs and PROODs (Section 8.3).
• Governed Workload: the system performing the Action (e.g., an AI agent, a fusion engine). The Governed Workload is outside the trust boundary.

3. Architectural Principles

1. Governance is the substrate. The authorization layer is not a feature of the workload; the workload runs on top of the authorization layer. No pathway to execution exists that bypasses the PDP.
2. The workload is untrusted. Enforcement never depends on the governed workload's cooperation. Constraints are applied by the Enforcement Executor before the workload receives data or effects.
3. Explicit outcomes only. Every ActionSpec receives an explicit Verdict or an explicit refusal. There is no silent-failure or best-effort path.
4. Evidence by construction. Receipts are generated as an inseparable part of the decision and execution flow, not as an optional logging layer.
5. Deterministic decisions and explanations. Verdict evaluation and rationale generation are deterministic. Probabilistic components (including language models) MUST NOT appear in the decision or explanation path. AI components MAY operate in advisory roles (anomaly flagging, classification suggestion); their outputs are inputs to policy, never decisions.
6. Governance of the governor. Changes to policy are themselves governed Actions: proposed as ActionSpecs, verdicted, and receipted.
7. Proportionate response. A single anomalous object or failed verification affects only that object (deny/segregate). System-wide restrictive states are entered only on policy-defined compromise patterns, so the governance layer cannot be weaponized as a denial-of-service vector.

4. The Nine-Stage Lifecycle

Every governed Action proceeds through the following stages. Stages 1-5 are the authorization path; stages 6-9 are the accountability path.

5. The ActionSpec

An ActionSpec is a structured document declaring a proposed Action. It MUST contain:

• action_id, a globally unique identifier, generated at Specification and carried through every subsequent record.
• principal, the authenticated identity of the requester.
• operation, the operation type, drawn from a profile-defined vocabulary.
• inputs, references to input objects, each with integrity digests and any confidentiality labels or bindings.
• proposed_output, the declared output characteristics (including any proposed output labels, destinations, or effects).
• context, execution context: node, environment, mission/tenancy identifiers, timestamp.
• policy_scope, the policy domain(s) under which evaluation is requested.

Illustrative structure (JSON shown; the protocol is serialization-agnostic):

{
  "action_id": "01J9ZK3W7Q4R8V2N6P0XA5HD3M",
  "principal": { "id": "pipeline-stage-7", "type": "service", "auth": "..." },
  "operation": "correlate",
  "inputs": [
    { "ref": "obj:sar:0142", "digest": "sha256:...", "label": { "..." : "..." }, "binding": "..." },
    { "ref": "obj:rf:0967",  "digest": "sha256:...", "label": { "..." : "..." }, "binding": "..." }
  ],
  "proposed_output": { "label": { "...": "..." }, "destination": "cop-feed-2" },
  "context": { "node": "edge-04", "env": "offline", "ts": "2026-07-07T14:00:00Z" },
  "policy_scope": ["fusion-compliance"]
}

6. Verdicts

The PDP issues exactly one of six verdict types for every evaluated ActionSpec:

Every verdict MUST carry a deterministic, human-readable rationale identifying the policy clause that fired, the triggering condition, and any constraint applied. Rationales are generated by mapping the fired policy predicate to template text; no probabilistic generation is permitted in the rationale path. Rationales MUST additionally be emitted in machine-readable form (the fired policy clause identifier, triggering condition, and policy bundle version as structured fields alongside the rendered text) so downstream systems can consume verdict reasoning programmatically.

7. The Policy Model

• Policy-as-code. Policies are machine-readable documents: constraint predicates, decision rules, escalation routes, and disposition logic. They are data, not software; a rule change is a document change, never a code release.
• Versioned and signed. Every Policy Bundle carries a version identifier and a digital signature. Every Verdict and PROA records the exact bundle version under which it was decided.
• Hot reload. Bundle activation is an atomic swap. No restart is required and no enforcement gap occurs during transition. In-flight ActionSpecs complete under the version they were verdicted against, preserving audit coherence.
• Compiled evaluation. Implementations SHOULD compile policy bundles at load time into optimized decision structures such that evaluation is lookup-dominated. Implementations MAY cache verdicts on repeated (input-class × label × operation × principal) tuples where policy semantics permit.
• Governed policy change. A proposed policy change is an ActionSpec (default route: escalate to a designated policy authority). The change, its approval, and its activation are receipted. The audit chain therefore covers the evolution of the rules themselves.
• Ordered constraint domains. Where a profile defines ordered sensitivity structures (e.g., classification lattices), policy evaluation MUST use the profile's formal ordering. Content transformations that legitimately change an object's true sensitivity are permissible under allow-with-constraints; lowering a label to satisfy an operation is prohibited. The data changes to satisfy the label; the label is never lowered to satisfy the operation.

8. The Evidentiary Chain

8.1 PROA: Proof of Authorization

(Informally: the authorization receipt.)

Issued at Stage 4, at verdict time. The PROA MUST record: the full ActionSpec (or its digest), the verdict and any constraints, the deterministic rationale, the exact policy bundle version, the deciding principal (PDP instance or human authority), and a timestamp. The PROA proves what was authorized.

8.2 PROOD: Proof of Operation and Delivery

(Informally: the execution receipt.)

Issued at Stage 8, after execution and verification. The PROOD MUST record: the action_id linking it to its PROA, digests of actual inputs consumed and outputs produced, output labels or effects as delivered, enforcement transformations actually applied, execution context and timing, and the verification result (conformant / divergent, with divergence detail). The PROOD proves what occurred.

8.3 The Receipt Ledger

PROAs and PROODs are committed to an append-only ledger in which each record is hash-linked to its predecessors. Structurally, the ledger forms a directed acyclic graph of the governed data/action lifecycle: any output object is a node whose edges trace back through receipted operations to original inputs.

Properties the ledger MUST provide:

1. Tamper evidence. Retroactive fabrication or modification of any record breaks the hash links detectably.
2. Lineage query. Any governed output can be traced through every operation to its origins.
3. Self-verifying export. An evidence bundle (receipts + policy versions + hash proofs) can be exported and independently verified by a party with no access to, and no trust in, the live system or its operator.

The divergence between PROA and PROOD is a first-class, inspectable artifact. Implementations MUST surface PROA/PROOD divergence as a policy-relevant event.

The ledger is an append-only, hash-linked record store; no distributed consensus or blockchain infrastructure is required or implied. Evidence-bundle exports SHOULD be compatible with external transparency infrastructures (e.g., IETF SCITT-style transparency logs), so that receipts can additionally be anchored to, and verified against, logs outside the operating organization's control.

8.4 Latency posture

The synchronous hot path carries only verdict evaluation and PROA issuance. PROOD persistence and ledger commitment MAY be asynchronous, provided ordering and linkage guarantees are preserved. Evidentiary completeness must not tax operational latency.

9. Override Governance

Human override of a verdict is permitted and is itself a governed Action:

• An override is expressed as an ActionSpec requiring an authenticated identity and a stated justification.
• The override receives its own verdict (per policy: typically allow with mandatory receipting, or escalate to higher authority) and its own PROA/PROOD pair.
• The original verdict, the override, and the justification are permanently linked in the ledger.

Override is always possible; anonymous or unrecorded override is architecturally impossible. Accountability is achieved by construction, not by procedure.

10. Security Considerations

• Integrity of inputs. Where inputs carry confidentiality labels or bindings, verification occurs at every hand-off (Stage 3 and Stage 5). A failed verification verdicts that object deny/segregate.
• Proportionality. Per Principle 7, single-object failures MUST NOT trigger system-wide restriction. Emergency-restrict thresholds are policy-defined and receipted when crossed.
• Signature primitives. Policy bundle signatures and label bindings SHOULD use asymmetric digital signatures, providing non-repudiable, multi-party-verifiable provenance. Symmetric MACs are NOT RECOMMENDED for cross-party evidence.
• Trust boundary. The Governed Workload, including any AI models within it, is outside the trust boundary. Compromise of the workload cannot forge receipts, alter policy, or cause unauthorized operations to be recorded as authorized.
• Ledger custody. Because export bundles are self-verifying, long-term evidentiary value survives even if the operating organization or its infrastructure is not trusted at review time.

11. Application Profiles

The core protocol is domain-agnostic. An application profile binds it to a domain by defining: the operation vocabulary, input object types and label schemas, the constraint-domain ordering (if any), disposition mappings, and escalation authorities. Profiles anticipated by the author include:

• Agent Action Authorization: governing actions proposed by autonomous AI agents (tool calls, transactions, communications, system changes).
• Sensor Fusion Compliance: governing multi-sensor, multi-domain data fusion operations, with confidentiality labels per NATO STANAG 4774, cryptographic binding per STANAG 4778, a classification lattice as the constraint-domain ordering, and disposition mapping {permit → allow; restrict/downgrade → allow-with-constraints; segregate → deny-with-quarantine}.

Profile specifications are published separately from this core document.

12. Conformance

An implementation is conformant with this specification if:

1. No governed operation can execute without a Verdict (Principle 1, Stage 4).
2. All six verdict types are supported with the semantics of Section 6.
3. Every verdict yields a PROA and every executed operation yields a linked PROOD (Section 8).
4. The ledger provides tamper evidence, lineage query, and self-verifying export (Section 8.3).
5. Verdict and rationale paths are deterministic (Principle 5).
6. Policy is versioned, signed, hot-reloadable, and its changes are themselves governed (Section 7).
7. Override conforms to Section 9.
8. Response proportionality conforms to Principle 7.

Conformance test criteria derivable from this specification will be published as a companion document.

ActionSpecs Protocol Specification v1.0-draft. Adekka Canada Inc., Toronto, Canada.

Contact: info@adekka.com