# Agent Interoperability Protocol (AIP) 1.0

**Status:** Versioned Protocol Specification
**Protocol version:** `1.0`
**Manifest version:** `aip-manifest/v1`
**Published:** 2026-07-14
**Encoding:** JSON with JSON Schema Draft 2020-12

## Abstract

Agent Interoperability Protocol (AIP) defines a transport-independent semantic
contract for discovering and invoking capabilities across agents, tools,
workflow systems, customer channels, and enterprise applications.

AIP provides a native envelope, participant manifest, typed capability
contracts, durable action and session lifecycles, streaming, cancellation,
human approval, transactional execution, compensation, remote delegation,
callbacks, operational query APIs, receipts, and audit records. Existing
protocols and products interoperate through compatibility profiles and
connectors; their data transfer objects do not become part of the native AIP
semantic core.

This document is normative for AIP 1.0. The versioned
[AIP JSON Schemas](schemas.md) are the normative machine-readable wire contract.

## 1. Conventions and Conformance

### 1.1 Requirement language

The key words **MUST**, **MUST NOT**, **REQUIRED**, **SHALL**, **SHALL NOT**,
**SHOULD**, **SHOULD NOT**, **RECOMMENDED**, **NOT RECOMMENDED**, **MAY**, and
**OPTIONAL** in this document are to be interpreted as described by BCP 14
([RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and
[RFC 8174](https://www.rfc-editor.org/rfc/rfc8174)) when, and only when, they
appear in all capitals.

### 1.2 Normative artifacts

An AIP 1.0 implementation MUST satisfy both:

1. the behavioral requirements in this document; and
2. the applicable JSON Schemas in `schemas/aip`.

Passing schema validation alone is insufficient because authorization,
cross-field invariants, state transitions, replay rules, and side-effect
ownership cannot all be expressed in JSON Schema.

A disagreement between this document and a versioned schema is a specification
defect. Implementations MUST NOT silently invent a third behavior. Conformance
reports MUST identify the artifact and rule used until the defect is resolved.

### 1.3 Implementation status

Protocol conformance and deployment qualification are different claims. A
conforming implementation can still be unqualified for a particular identity
provider, storage topology, connector, load profile, or external service.

## 2. Scope

### 2.1 Goals

AIP 1.0 defines:

- stable participant and capability discovery;
- one native semantic envelope across supported transport bindings;
- synchronous, asynchronous, and streaming actions;
- durable lifecycle and authorized query semantics;
- first-class identity, tenant, credential-reference, policy, and approval
  context;
- plan, commit, compensation, and reconciliation semantics;
- parent-child delegation across authenticated AIP peers;
- channel, resource, callback, event, receipt, and audit models;
- compatibility boundaries for existing protocols, including MCP;
- conformance profiles for independent implementations.

### 2.2 Non-goals

AIP does not define:

- an agent reasoning algorithm or model architecture;
- a universal business ontology;
- storage-engine internals;
- a secret distribution protocol;
- a global public-key infrastructure;
- exactly-once external side effects where a provider offers no idempotency or
  reconciliation mechanism;
- product-specific API objects in the semantic core;
- cryptocurrency or economic settlement as a mandatory dependency.

## 3. Terminology and Roles

| Term | Definition |
|---|---|
| Participant | A system that sends or receives native AIP messages |
| Principal | A human, agent, service, tenant, customer, contact, or system identity |
| Client | Participant initiating discovery, handshake, action, or query messages |
| Gateway | Participant that authenticates, validates, authorizes, routes, and translates traffic |
| Runtime | Durable execution and operational state owner |
| Capability | Discoverable operation that can be invoked by an action |
| Connector | Product integration that maps an external system to AIP semantics |
| Profile | Versioned compatibility or transport projection |
| Action | One requested unit of work |
| Session | Durable relationship grouping related protocol work |
| Handler | Admitted implementation of one callable capability |
| Delegate | Participant expected to execute a child action |
| Approver | Authenticated principal authorized to decide an approval request |
| Trust domain | Administrative boundary that owns identities, policy, and capabilities |
| Receipt | Hash-linkable evidence of a protocol decision or transition |

A participant MAY implement more than one role. Role combination MUST NOT bypass
the authorization or durability requirements of either role.

## 4. Architecture

AIP separates five concerns:

1. **Semantic core:** principals, capabilities, actions, sessions, messages,
   policy, transactions, delegation, resources, and events.
2. **Runtime:** durable ownership, scheduling, leases, replay, callbacks,
   receipts, and operational queries.
3. **Transport bindings:** native HTTP, NATS, SSE, and WebSocket framing.
4. **Compatibility profiles:** mapping to protocols such as MCP or A2A without
   importing their DTOs into the core.
5. **Connectors:** mapping external products and provider behavior to admitted
   AIP capabilities.

A compatibility profile MUST map into the same native runtime semantics used by
native clients. It MUST NOT create a parallel action store, policy engine, or
connector execution path unless the profile specification explicitly defines a
federated runtime boundary.

## 5. Data Representation

### 5.1 JSON encoding

Native messages MUST be encoded as UTF-8 JSON. Numbers MUST remain within the
range accepted by the applicable schema and implementation. A sender MUST NOT
depend on object-member ordering.

Typed AIP objects reject members not admitted by their versioned schema. The
explicit `extensions`, profile binding metadata, and other schema-defined open
objects are the extension points.

### 5.2 Time

Wire timestamps MUST use RFC 3339. Senders SHOULD emit UTC with a `Z` suffix.
Receivers MUST compare instants rather than textual forms.

### 5.3 Identifiers

Generated identifiers use the following prefixes:

| Object | Prefix |
|---|---|
| Message | `msg_` |
| Session | `sess_` |
| Correlation | `corr_` |
| Action | `act_` |
| Approval | `appr_` |
| Delegation | `dlg_` |
| Event | `evt_` |
| Receipt | `rcpt_` |
| Transaction | `txn_` |
| Conversation | `conv_` |

Implementations SHOULD generate time-sortable, collision-resistant identifiers.
Receivers MUST treat identifiers as opaque. `PrincipalId`, `CapabilityId`, and
`ProfileId` are non-empty deployment-stable strings and have no mandatory
prefix.

### 5.4 Null and omission

Optional members MAY be omitted. A receiver MUST follow the applicable schema
when `null` is present. Senders SHOULD omit absent optional values to minimize
ambiguity and payload size.

### 5.5 Canonicalization

Operations that sign envelopes, hash governed input, or build receipt chains
MUST use the AIP canonical JSON procedure defined by the cryptographic profile.
Ordinary transport decoding MUST NOT assume that received JSON was already
canonicalized.

## 6. Native Envelope

Every native message is carried in an `Envelope`.

| Member | Required | Meaning |
|---|---:|---|
| `aip_version` | Yes | Protocol version; exactly `1.0` |
| `message_type` | Yes | Registered fully qualified message type |
| `message_id` | Yes | Unique message id |
| `sent_at` | Yes | Sender timestamp |
| `body` | Yes | Exactly one externally tagged message body |
| `session_id` | No | Active session |
| `correlation_id` | No | Request/workflow correlation |
| `in_response_to` | No | Message or correlation reference |
| `idempotency_key` | No | Envelope-level delivery deduplication key |
| `from` | No | Claimed sender principal |
| `to` | No | Intended recipient principal |
| `trace` | No | Trace metadata |
| `security` | No | Signature or authentication metadata |
| `extensions` | No | Profile or vendor extensions |

### 6.1 Body tagging

`body` MUST contain exactly one snake-case key whose value is the message
payload, for example `{"action": {...}}`. `message_type` MUST equal the type
implied by that body key.

### 6.2 Correlation

A response SHOULD copy the request `correlation_id` and set `in_response_to` to
the request message id or correlation id. Stream chunks and a final result for
one action MUST remain attributable to that action and SHOULD share its
correlation id.

### 6.3 Envelope identity

`from` and `to` are semantic claims. A receiver MUST NOT treat `from` as
authenticated merely because the envelope is schema-valid. Authentication MUST
bind the claim to trusted transport or signature context as specified in
Section 22.

### 6.4 Envelope validation

A receiver MUST reject an envelope when:

- `aip_version` is unsupported;
- `message_type` does not match `body`;
- `message_id` is empty;
- `idempotency_key` is present but empty;
- JSON Schema validation fails;
- message-specific semantic validation fails;
- authentication, replay, or authorization policy rejects it.

### 6.5 Example

```json
{
  "aip_version": "1.0",
  "message_type": "aip.core.v1.action",
  "message_id": "msg_0190c42f2d5a70008000000000000001",
  "sent_at": "2026-07-14T08:30:00Z",
  "correlation_id": "corr_0190c42f2d5a70008000000000000002",
  "from": {
    "id": "service:booking-client",
    "kind": "service"
  },
  "to": {
    "id": "agent:restaurant-manager",
    "kind": "agent"
  },
  "body": {
    "action": {
      "id": "act_0190c42f2d5a70008000000000000003",
      "capability_id": "cap:restaurant:booking:create",
      "input": {
        "name": "Jordan",
        "party_size": 2,
        "requested_time": "2026-07-14T19:30:00+04:00"
      },
      "mode": "sync",
      "idempotency_key": "booking-jordan-20260714-1930"
    }
  }
}
```

## 7. Message Type Registry

Message type names use `aip.<family>.v<major>.<name>`. A sender MUST use the
registered string exactly.

### 7.1 Core and lifecycle

| Message type | Body key | Direction or purpose |
|---|---|---|
| `aip.core.v1.handshake` | `handshake` | Session negotiation request |
| `aip.core.v1.handshake_response` | `handshake_response` | Negotiation response |
| `aip.core.v1.action` | `action` | Capability invocation |
| `aip.core.v1.ack` | `ack` | Admission acknowledgement |
| `aip.core.v1.stream_chunk` | `stream_chunk` | Incremental output |
| `aip.core.v1.action_result` | `action_result` | Final action result |
| `aip.core.v1.error` | `error` | Protocol or action error |
| `aip.core.v1.cancel` | `cancel` | Action or session cancellation |
| `aip.core.v1.heartbeat` | `heartbeat` | Liveness or progress signal |
| `aip.core.v1.heartbeat_ack` | `heartbeat_ack` | Heartbeat acknowledgement |
| `aip.core.v1.escalation` | `escalation` | Human escalation request |
| `aip.core.v1.escalation_resolution` | `escalation_resolution` | Escalation outcome |
| `aip.lifecycle.v1.action_status_request` | `action_status_request` | Read action status |
| `aip.lifecycle.v1.action_status` | `action_status` | Durable action view |
| `aip.lifecycle.v1.action_result_request` | `action_result_request` | Read final result |
| `aip.lifecycle.v1.action_list_request` | `action_list_request` | List action views |
| `aip.lifecycle.v1.action_list` | `action_list` | Action list response |
| `aip.lifecycle.v1.action_events_request` | `action_events_request` | Read action events |
| `aip.lifecycle.v1.action_events` | `action_events` | Action event response |

### 7.2 Session, policy, transaction, and delegation

| Message type | Body key | Purpose |
|---|---|---|
| `aip.session.v1.session_request` | `session_request` | Read one session |
| `aip.session.v1.session_view` | `session_view` | Session response |
| `aip.session.v1.session_list_request` | `session_list_request` | List sessions |
| `aip.session.v1.session_list` | `session_list` | Session list response |
| `aip.session.v1.session_close_request` | `session_close_request` | Close a session |
| `aip.session.v1.session_resume_request` | `session_resume_request` | Resume a session |
| `aip.session.v1.session_resume` | `session_resume` | Resume response and replay |
| `aip.policy.v1.approval_request` | `approval_request` | Create approval workflow |
| `aip.policy.v1.approval_decision` | `approval_decision` | Decide approval workflow |
| `aip.policy.v1.approval_query_request` | `approval_query_request` | Read approval record |
| `aip.policy.v1.approval_list_request` | `approval_list_request` | List approvals |
| `aip.policy.v1.approval_record_view` | `approval_record_view` | Approval record response |
| `aip.policy.v1.approval_list` | `approval_list` | Approval list response |
| `aip.transaction.v1.request` | `transaction_request` | Execute transaction stage |
| `aip.transaction.v1.result` | `transaction_result` | Transaction stage result |
| `aip.transaction.v1.query_request` | `transaction_query_request` | Query transaction |
| `aip.transaction.v1.view` | `transaction_view` | Durable transaction view |
| `aip.agent.v1.delegation_request` | `delegation_request` | Delegate child action |
| `aip.agent.v1.delegation_result` | `delegation_result` | Child action outcome |

### 7.3 Discovery, resources, callbacks, channels, and audit

| Message type | Body key | Purpose |
|---|---|---|
| `aip.discovery.v1.manifest_request` | `manifest_request` | Discover participant contract |
| `aip.discovery.v1.manifest_response` | `manifest` | Manifest response |
| `aip.discovery.v1.event_stream_request` | `event_stream_request` | Read global events |
| `aip.discovery.v1.event_stream_response` | `event_stream` | Global event response |
| `aip.resource.v1.resource_list_request` | `resource_list_request` | List resources |
| `aip.resource.v1.resource_list` | `resource_list` | Resource list response |
| `aip.resource.v1.resource_read_request` | `resource_read_request` | Read resource |
| `aip.resource.v1.resource_read_result` | `resource_read_result` | Resource content response |
| `aip.callback.v1.delivery_query_request` | `callback_delivery_query_request` | Read callback delivery |
| `aip.callback.v1.delivery_list_request` | `callback_delivery_list_request` | List callback deliveries |
| `aip.callback.v1.delivery_record` | `callback_delivery_record` | Delivery record response |
| `aip.callback.v1.delivery_list` | `callback_delivery_list` | Delivery list response |
| `aip.channel.v1.message_created` | `channel_message` | External channel message |
| `aip.channel.v1.conversation_updated` | `conversation` | Conversation update |
| `aip.audit.v1.receipt_chain` | `receipt_chain` | Hash-linked receipts |
| `aip.audit.v1.receipt_query_request` | `receipt_query_request` | Read receipt chain |
| `aip.audit.v1.audit_event` | `audit_event` | Audit event |
| `aip.audit.v1.audit_query_request` | `audit_query_request` | Query audit events |
| `aip.audit.v1.audit_query_result` | `audit_query_result` | Audit query response |
| `aip.economic.v1.batch_settlement` | `batch_settlement` | Optional settlement batch |

Unknown message types MUST be rejected with an unsupported-message error unless
an explicitly negotiated extension profile owns the type.

## 8. Principals and Identity Context

### 8.1 Principal

A `Principal` has a REQUIRED non-empty `id` and `kind`. Kinds are `human`,
`agent`, `service`, `tenant`, `customer`, `contact`, and `system`.

Optional fields include display name, trust domain, DID, external references,
delegated authority, and profile authentication metadata. Display names and
external references MUST NOT be used as authentication proof.

### 8.2 External references

An `ExternalRef` contains `system`, `type`, and `id`. Connectors SHOULD preserve
provider-local identity and object references this way rather than overloading
native principal ids.

### 8.3 Identity context

`IdentityContext` MAY contain:

- tenant reference;
- external account and external user references;
- human actor and service account;
- `acted_on_behalf_of` principal;
- opaque credential reference with issuer and scopes;
- OAuth issuer, client id, scopes, expiration, and refresh availability.

Raw credential material MUST NOT appear in `IdentityContext`.

### 8.4 Delegated authority

A delegated authority grant names the covered principal, scopes, expiration,
and optional reason. Expired or revoked grants MUST be ignored. Authorization
MUST bind the authenticated delegate, target principal, scope, capability,
tenant, and applicable risk/value constraints.

## 9. Discovery and Manifests

### 9.1 Manifest

An AIP manifest contains:

| Member | Required | Meaning |
|---|---:|---|
| `manifest_version` | Yes | Exactly `aip-manifest/v1` for this specification |
| `agent` | Yes | Provider principal |
| `capabilities` | No | Callable or discoverable operations |
| `profiles` | Yes | Supported native and compatibility profiles |
| `resources` | No | Readable resources |
| `channels` | No | Supported channel operations |
| `security` | No | Authentication and signature metadata |
| `governance` | No | Audit and compliance metadata |
| `limits` | No | Provider limits |
| `compatibility` | No | Profile compatibility metadata |
| `extensions` | No | Vendor extensions |

`profiles` MUST NOT be empty. Capability ids within one manifest MUST be
unique. Discovery admission MUST validate the complete manifest before making
any capability visible.

### 9.2 Atomic capability admission

A runtime MUST NOT advertise a callable capability without an admitted handler
whose declared implementation support matches the capability contract. Manifest
composition and handler admission MUST be atomic from the perspective of
clients.

### 9.3 Capability

A capability has REQUIRED `id`, `name`, `kind`, and `input_schema`. The input
schema MUST be a JSON object schema. `output_schema`, description, risk,
stability, cost, auth, bindings, compatibility approval flag, and enterprise
contract are optional.

Capability kinds are `agent`, `tool`, `workflow`, `channel`, `resource`, and
`human_task`. Risk values are `low`, `medium`, `high`, and `critical`.
Stability values are `stable`, `experimental`, and `deprecated`.

### 9.4 Capability contract

When `contract` is present:

- `side_effects` MUST contain at least one declared effect;
- idempotency, execution, and data contracts are REQUIRED;
- at least one of sync, async, or streaming execution MUST be supported;
- a supported compensation mode MUST identify its compensating capability;
- a transaction contract MUST list at least one supported mode;
- declared positive durations MUST be greater than zero.

Side effects are `read`, `write`, `delete`, `send_message`, `financial`,
`identity`, `medical`, `legal`, `external_network`, and `code_execution`.

An implementation MUST apply the conservative interpretation when a
compatibility projection lacks enough information to populate a stronger
contract.

### 9.5 Idempotency contract

The requirement is `required`, `optional`, or `unsupported`. Collision behavior
is `return_original_result`, `reject_conflict`, or `revalidate_input_hash`.
Scope is `action`, `capability`, `principal`, `tenant`, or `external_account`.

A runtime MUST atomically reserve a required key before handler dispatch. It
MUST NOT claim exactly-once provider behavior when the provider lacks compatible
idempotency or reconciliation.

### 9.6 Execution and data contracts

Execution declares supported modes, cancellation, retry, expected completion,
and retry safety. Retry safety is `safe`, `safe_with_idempotency_key`, `unsafe`,
or `unknown`.

Data sensitivity is `public`, `internal`, `confidential`, `restricted`,
`regulated`, or `unknown`. Policy MUST treat `unknown` conservatively. Data
contracts MAY further require redaction, residency, retention, and legal-hold
behavior.

### 9.7 Resources

A `Resource` has REQUIRED `id` and `name` and MAY declare kind, owning
capability, description, MIME type, tenant, access policy, and expiration.

Resource metadata is subject to authorization. A runtime MUST NOT reveal even
the existence of a resource to a principal that cannot list it. A read policy
may allow any authenticated principal, specific principals, required scopes,
and a matching tenant boundary.

### 9.8 Discovery filtering

A `ManifestRequest` MAY filter capability ids, resource kinds, profiles, risk,
side effects, approval requirement, streaming, and transaction support. A
filtered response MUST remain a valid manifest and MUST NOT weaken security or
expose otherwise invisible metadata.

## 10. Handshake and Sessions

### 10.1 Handshake request

A `Handshake` contains the caller principal, a non-empty purpose, supported
profiles, and optional requested capabilities, authentication metadata,
compliance requirements, heartbeat, encryption, and billing preferences.

Authentication metadata in the body is not self-authenticating. The receiver
MUST validate it through the negotiated profile or trusted transport.

### 10.2 Handshake response

A `HandshakeResponse.status` is `accepted`, `rejected`, or `redirect`.

- `accepted` SHOULD include a session id, responder, agreed profiles, and agreed
  capabilities.
- `rejected` SHOULD include a structured rejection reason.
- `redirect` SHOULD include an authenticated or policy-approved redirect target.

A receiver MUST NOT follow a redirect to a weaker security boundary without
explicit policy.

### 10.3 Session state machine

Session states are:

```text
new -> active
active -> queued | processing | cancelled
queued -> processing | cancelled | failed
processing -> streaming | waiting_for_human | completed | failed | cancelled
streaming -> waiting_for_human | completed | failed | cancelled
waiting_for_human -> processing | completed | failed | cancelled
completed | failed | cancelled -> settled
```

Any transition not shown is invalid. A settled session is terminal.

### 10.4 Session operational model

The durable session view includes session id, status, initiator, peer, creation
and update time, optional expiration, active-action count, and binding links.

Session queries MUST be authorized against the authenticated reader and any
delegated authority. List filters MUST NOT broaden visibility.

### 10.5 Resume

A handshake MAY issue an opaque, single-use resume token. A resume request MAY
include that token and the last observed event cursor. On successful resume, the
runtime MUST:

1. authenticate the requester and verify ownership or delegated authority;
2. atomically consume the supplied token;
3. return the current session view;
4. replay visible retained events after the cursor;
5. issue a replacement token when token-based resume is enabled.

Resume tokens are credentials and MUST NOT appear in logs, URLs, receipts, or
audit payload data.

## 11. Actions and Lifecycle

### 11.1 Action

An `Action` has REQUIRED `id`, `capability_id`, and non-null `input`. Optional
members are mode, idempotency key, timeout, conversation, memory context,
delegation chain, federation, callback, observability, compliance, identity,
approval, and transaction context.

Action modes are `sync`, `async`, and `streaming`. A runtime MUST reject a mode
that the admitted capability contract does not support.

An action timeout, when present, MUST be greater than zero. A runtime MUST
derive an immutable execution deadline and MUST NOT let a connector extend it
from untrusted payload metadata.

### 11.2 Trusted execution context

Before handler dispatch, the runtime MUST freeze a trusted execution context
containing at least:

- transport-authenticated principal and issuer;
- verified scopes and delegated authority;
- tenant and external-account binding when applicable;
- resolved opaque credential reference;
- immutable deadline and cancellation token;
- trace context;
- validated delegation chain;
- policy and approval result;
- transaction ownership state;
- bounded stream publisher.

A connector MUST use this context rather than reconstructing authority from
`Action.input`, `Action.identity`, or extension metadata.

### 11.3 Admission

For each action, a gateway/runtime MUST perform, in order or atomically where
required:

1. envelope and schema validation;
2. transport authentication and replay claim;
3. manifest and handler lookup;
4. capability input-schema validation;
5. identity, tenant, credential, and scope resolution;
6. mode, deadline, risk, and contract validation;
7. idempotency reservation;
8. policy and approval evaluation;
9. durable action admission;
10. handler dispatch or queueing.

The implementation MAY combine steps but MUST preserve the same fail-closed
outcome. No provider side effect may occur before the applicable admission and
ownership steps succeed.

### 11.4 Acknowledgement

`Ack.status` is `accepted`, `rejected`, `queued`, `streaming`, or `cached`.

`cached` means the runtime returned a previously retained idempotent outcome; it
MUST NOT dispatch the handler again. `rejected` SHOULD include a reason and MUST
NOT imply that an external side effect occurred.

### 11.5 Durable lifecycle states

The operational action state is one of:

- `unknown`;
- `accepted`;
- `queued`;
- `running`;
- `streaming`;
- `pending_approval`;
- `cancelling`;
- `cancelled`;
- `completed`;
- `failed`;
- `expired`;
- `dead_lettered`.

`cancelled`, `completed`, `failed`, `expired`, and `dead_lettered` are terminal
for one action record. A recovery operation that creates new work MUST create a
new action and link it through audit, transaction, or compensation metadata.

### 11.6 Streaming

`StreamChunk` contains action id, monotonically increasing sequence, kind, and
optional structured data or message part. Kinds are `data`, `progress`, `tool`,
`thought`, `preview`, `pending_approval`, `error`, and `done`.

For one action:

- sequence values MUST increase monotonically;
- a sender MUST NOT reuse a sequence for different content;
- a receiver MUST tolerate duplicate delivery of the same retained chunk;
- `done` terminates the chunk stream but the final `ActionResult` remains the
  authoritative terminal outcome;
- stream errors MUST be represented by an error chunk and/or failed final
  result; they MUST NOT silently close the stream.

### 11.7 Final result

`ActionResult.status` is `completed`, `failed`, `cancelled`,
`pending_approval`, or `requires_human`.

A failed result MUST include `error`. A completed result MAY include structured
output, rich message parts, memory update, usage, and a receipt reference. When
a capability declares an output schema, structured output MUST validate before
the result is admitted as completed.

### 11.8 Cancellation

`Cancel.target` selects an action or session. Cancellation is a request, not a
claim that a provider stopped.

The runtime MUST record cancellation intent durably, signal the active handler,
and invoke provider cancellation when supported. It MUST NOT report `cancelled`
until the applicable ownership boundary confirms terminal cancellation. If the
provider outcome may be committed but cannot be determined, the transaction
MUST enter unknown-outcome reconciliation rather than being labelled cancelled.

### 11.9 Heartbeats

`Heartbeat` carries a sequence and optional status/progress. A receiver SHOULD
reply with `HeartbeatAck` containing the same sequence and receive time.
Heartbeat loss MAY trigger liveness policy but MUST NOT by itself prove that a
provider action failed or did not commit.

## 12. Approval, Policy, and Escalation

### 12.1 Approval policy

An approval policy declares whether approval is required, why, who may approve,
TTL, evidence, delegated authority, an optional composed rule, minimum distinct
principals, separation of duties, and policy version.

Approver selectors are a specific principal, trusted role, trusted group,
tenant policy, or verified external system. Composed rules support `all`, `any`,
`quorum`, principal, role, group, tenant policy, external system, and delegated
authority leaves.

Authority leaves MUST be evaluated against a trusted resolver. Values asserted
only by the action or decision payload MUST NOT satisfy an authority rule.

### 12.2 Approval request

An `ApprovalRequest` binds approval id, action id, capability id, requester,
subject, selector, reason, evidence, expiration, policy decision id, identity,
policy snapshot/hash, operator, risk, and governed value as applicable.

The runtime MUST derive the request from the admitted action and policy. A
caller MUST NOT be allowed to substitute a different governed action after the
request is created.

### 12.3 Policy snapshot and evidence

The runtime SHOULD retain an immutable policy snapshot and MUST retain a
canonical policy/governed-subject hash when later approval depends on that
snapshot.

Evidence artifacts contain an id, kind, optional URI, optional integrity hash,
and redaction flag. Raw secret material MUST NOT be stored as evidence.
Sensitive action input SHOULD remain in a separately authorized evidence store;
ordinary approval records carry its hash or redacted reference.

### 12.4 Approval decision

Decision kinds are `approved`, `denied`, `expired`, and `revoked`. A decision
contains the approval id, claimed approver, time, optional reason, constraints,
evidence, stable decision id, policy hash, authority path, and revocation target
as applicable.

Before accepting a decision, the runtime MUST verify:

- the authenticated principal matches the claimed approver;
- the approval exists and is visible to that principal;
- authority rules and quorum are satisfied;
- separation-of-duties requirements hold;
- the request and any delegated grant are unexpired and non-revoked;
- the policy hash and governed input still match;
- constraints are valid and enforceable;
- decision replay is idempotent.

An `Action.approval` value is valid only when its decision kind is `approved` and
the runtime verifies it against the stored approval record.

### 12.5 Resume after approval

Approval MUST resume the original durable action or transaction stage. The
runtime MUST revalidate expiration, policy, identity, transaction ownership,
input hash, and approval constraints immediately before dispatch.

### 12.6 Approval receipts

The runtime SHOULD emit receipts for policy decision, approval requested,
granted, denied, expired, and revoked transitions. Receipt data MUST NOT contain
unredacted governed input.

### 12.7 Escalation

Escalation kinds are `approval`, `input`, `handoff`, and `policy_exception`.
Escalation decisions are `approve`, `reject`, `modify`, `handoff`, and `cancel`.

Approval is the authorization of a known governed operation. Escalation is the
broader request for human input, takeover, or exception handling. An
implementation MUST NOT treat arbitrary escalation text as an approved
`ApprovalDecision`.

## 13. Transactions and Compensation

### 13.1 Transaction context

An action transaction contains a REQUIRED mode and optional transaction id,
plan id, and compensated action id. Modes are `execute`, `dry_run`, `plan`,
`commit`, `compensate`, `reconcile`, and `rollback_not_supported`.

A `commit` action MUST include `plan_id`. A `compensate` action MUST include
`compensation_for`. A first-class `TransactionRequest.transaction_id` MUST match
the id inside the action transaction when both are present.

### 13.2 Dry run

Dry-run fidelity is `schema_only`, `policy_and_schema`,
`downstream_validation`, or `full_simulation`. A provider MUST NOT advertise a
stronger fidelity than it executes. A dry run MUST NOT intentionally commit the
business side effect.

### 13.3 Plan

A durable `TransactionPlan` binds:

- plan, transaction, action, and capability ids;
- transaction mode;
- requesting principal;
- canonical input hash and optional snapshot;
- predicted side effects;
- approval requirement and policy;
- compensation contract;
- dry-run fidelity;
- trusted identity snapshot;
- creation and optional expiration;
- bounded metadata.

A planned `TransactionResult` MUST contain a plan whose transaction, action, and
capability ids match the result.

### 13.4 Commit

The runtime MUST atomically claim commit ownership for one plan before provider
dispatch. A commit MUST be rejected if the plan is expired, already terminal,
owned by another valid claim, or no longer matches capability, input, identity,
policy, approval, or transaction context.

Commit ownership MUST use fencing suitable for the configured storage backend.
A stale worker MUST NOT be able to commit after its lease or claim is superseded.

### 13.5 Transaction states

Wire-visible transaction states are:

- `dry_run_completed`;
- `planned`;
- `prepared`;
- `committing`;
- `committed`;
- `compensating`;
- `compensated`;
- `requires_human`;
- `cancelled`;
- `rollback_not_supported`;
- `failed`;
- `outcome_unknown`;
- `reconciling`;
- `reconciled`.

A failed transaction result MUST include a protocol error or a failed action
result containing an error.

### 13.6 Unknown outcomes and reconciliation

If an external side effect may have committed but no definitive response is
available, the connector MUST return an uncertain-outcome failure with a
durable provider operation reference when one exists. The runtime MUST record
`outcome_unknown` and MUST NOT automatically retry commit.

Reconciliation MUST query provider state using the retained operation reference
and cursor. Only a definitive reconciled outcome may authorize retry,
completion, or compensation.

### 13.7 Compensation

Compensation modes are `not_required`, `supported`, `best_effort`, and
`rollback_not_supported`. `supported` requires a compensating capability id.

Compensation is a new governed action. It MUST have its own authorization,
idempotency, approval, lifecycle, result, and receipts. It MUST reference the
action being compensated. AIP does not describe compensation as atomic rollback
across independent systems.

## 14. Delegation and Federation

### 14.1 Delegation request

A `DelegationRequest` contains delegation id, parent action id, complete child
action, requester, delegate, non-empty scope, and optional callback/metadata.
Parent and child action ids MUST differ.

The child action MUST satisfy normal action validation and admission. Delegation
does not bypass capability policy, approval, transaction, tenant, or credential
requirements.

### 14.2 Routing and peer authentication

A delegation router resolves the delegate principal or child capability to a
versioned transport endpoint. The receiving peer MUST authenticate the immediate
sender and verify expected peer principal, trust domain, capability, scope, and
immutable execution contract.

A URL or NATS subject alone is not identity. Production routes MUST bind an
expected peer identity and authentication method.

### 14.3 Delegation chain

Each chain entry records delegating principal, delegate principal, scope, and
time. A native action MUST NOT contain more than ten entries. A deployment MAY
set a lower limit.

Each hop MUST preserve or narrow authority. A delegate MUST NOT create scope it
did not receive. Runtimes MUST reject loops, expired grants, forbidden trust
domains, and chains that fail tenant or data-residency policy.

### 14.4 Delegation result

Delegation status is `accepted`, `running`, `completed`, `failed`, `cancelled`,
or `requires_human`. A terminal result MUST contain an action result or protocol
error. The result identifies delegation, parent action, and child action.

Natural-language output from an agent MUST NOT be treated as trusted evidence
that a delegated child action executed. A trusted result must come from the
authenticated AIP child workflow.

### 14.5 Parent cancellation and recovery

Parent cancellation SHOULD propagate to active child actions according to
workflow policy. The graph MUST retain parent-child correlation through retry,
restart, callback, and terminal settlement. A remote child in unknown provider
state follows transaction reconciliation rules.

## 15. Conversations and Content

### 15.1 Conversation

A conversation has id, channel metadata, status, and optional external
references, contact, assignee, priority, labels, and metadata. Status is `open`,
`pending`, `resolved`, `snoozed`, or `archived`. Priority is `low`, `medium`,
`high`, or `urgent`.

### 15.2 Message parts

AIP supports typed message parts:

- text with optional format;
- image with URL or inline data, MIME type, and alt text;
- file with URL or inline data, MIME type, filename, and size;
- audio with URL or inline data, MIME type, and transcript;
- form;
- card;
- structured JSON with optional schema;
- tool result with call id and data or error.

Inline binary content SHOULD be bounded by transport and policy limits. Large or
sensitive content SHOULD use authenticated resource URIs and integrity metadata.

### 15.3 Channel messages

A channel message contains conversation, optional identity, provider message
metadata, sender, parts, delivery metadata, and optional raw payload.

Connectors MUST verify provider authenticity and delivery replay before emitting
`aip.channel.v1.message_created`. Raw payload retention MUST be explicit,
authorized, and redacted according to data policy.

## 16. Events and Operational Read Model

### 16.1 Events

An event contains id, kind, occurrence time, and optional session, action,
correlation, actor, and data. Event kinds are namespaced strings. Event data MUST
be safe for the authorized event audience.

### 16.2 Cursors

Cursors are opaque, query-scoped, identity-scoped, and retention-bound. Clients
MUST NOT decode or manufacture them. A runtime MAY replay events after a cursor
and MAY return duplicates across reconnect; consumers MUST deduplicate by event
id or binding event id.

### 16.3 Query authorization

Every action, session, approval, transaction, callback, resource, receipt, and
audit query MUST authorize the authenticated reader independently of filters or
object ids supplied by the caller.

At minimum, visibility policy SHOULD consider owner principal, delegated
authority, tenant, requested scope, sensitivity, and export intent. A list query
MUST NOT reveal hidden object counts or identifiers.

### 16.4 Pagination and waits

Native list limits MUST be between 1 and 1000. A response MUST NOT contain more
than 1000 records. Bounded action waits MUST NOT exceed 30,000 milliseconds.
Longer observation uses events, callbacks, or repeated reads with backoff.

### 16.5 Action queries

Action status MAY include capability, session, correlation, queue state, result
status, approval, transaction, delegation, timestamps, retry, lease, final
result, receipt chain, chunks, and typed links.

Action event responses MUST contain only events and chunks scoped to the
requested action. `terminal` states whether the action has reached a terminal
lifecycle state.

### 16.6 Approval evidence export

Ordinary approval reads MUST NOT include raw governed action input. An explicit
evidence-payload expansion requires both approval visibility and dedicated
sensitive export authority. The returned payload MUST identify action,
capability, canonical input hash, exact input, and applicable transaction and
trusted identity context.

### 16.7 Audit export

Normal audit browsing and evidence export are separate operations. Export mode
MUST require dedicated authority because exported records may leave the runtime
trust boundary.

## 17. Callback Delivery

### 17.1 Callback target

A callback names a profile, target URI or subject, and optional profile metadata.
Targets MUST be validated against deployment policy before an action is
admitted.

### 17.2 Delivery policy

A callback delivery policy contains delivery id, target, maximum attempts,
per-attempt timeout, retry backoff, propagated idempotency key, signing flag, and
terminal-only flag.

Delivery ids and idempotency keys MUST be stable across retry. A callback retry
MUST NOT re-execute the source action.

### 17.3 Durable outbox

Callback state is `pending`, `running`, `delivered`, `failed`, or
`dead_lettered`. The runtime MUST durably retain attempts, next-attempt time,
lease owner/expiry, last error, dead-letter reason, timestamps, and optional
receipt chain.

Delivery workers MUST use atomic leases and fencing. A successful target
acknowledgement MUST be recorded before the delivery is considered complete.

### 17.4 HTTP callback security

HTTP callback dispatch MUST enforce scheme, exact host allowlist, DNS/address
policy, redirect policy, request size, timeout, and response size. Production
deployments SHOULD require HTTPS and signed payloads. Private, loopback,
link-local, and metadata-service addresses MUST be denied unless explicitly
owned and allowed by deployment policy.

## 18. Receipts, Audit, and Settlement

### 18.1 Receipts

A receipt identifies a protocol transition, actor, time, optional correlation,
data, previous hash, and current hash. Receipt types are:

- `request_received`;
- `action_accepted`;
- `policy_decision`;
- `approval_requested`;
- `approval_granted`;
- `approval_denied`;
- `approval_expired`;
- `approval_revoked`;
- `tool_executed`;
- `delegation_made`;
- `human_approved`;
- `result_returned`;
- `settlement_recorded`;
- `transaction_planned`;
- `transaction_commit_started`;
- `transaction_committed`;
- `transaction_compensated`;
- `transaction_dry_run_completed`;
- `transaction_rollback_unsupported`;
- `transaction_failed`;
- `callback_delivery_attempted`;
- `callback_delivered`;
- `callback_delivery_failed`.

Receipt data SHOULD contain identifiers, decisions, hashes, and redacted
metadata rather than full business payloads.

### 18.2 Receipt hashing

The AIP 1.0 receipt hash procedure is:

1. copy the receipt and omit its current `hash` value;
2. recursively sort every JSON object by member name;
3. encode compact UTF-8 JSON without omitting any other field;
4. compute SHA-256;
5. encode the digest as lowercase hexadecimal.

`previous_hash` MUST equal the prior receipt hash or be absent for the first
receipt. A chain `root_hash` is the lowercase hexadecimal SHA-256 digest of the
UTF-8 concatenation of receipt hash strings in order.

A non-empty receipt chain MUST include `root_hash`. Verifiers MUST validate
every receipt and link before trusting the root.

Receipt-chain integrity proves that retained data did not change. It does not by
itself authenticate the original actor; identity and signature evidence remain
necessary.

### 18.3 Audit events

An audit event contains id, actor, optional identity context, action label,
time, and optional redacted data. Audit events MUST be authorization-scoped and
SHOULD be append-only in production storage.

Audit query filters MUST NOT override reader visibility. Evidence export MUST be
explicit and separately authorized.

### 18.4 Economic settlement

`BatchSettlement` is OPTIONAL. It contains a batch id, settlement model, and
records. Core action execution MUST NOT depend on settlement support unless the
capability contract and negotiated profile explicitly require it.

## 19. Error Model

### 19.1 Protocol error

A `ProtocolError` contains REQUIRED `code`, `message`, and `category`, plus
optional retryability, retry delay, structured details, and source metadata.

Codes MUST be stable namespaced strings. Human-readable messages MAY change and
MUST NOT be used for program logic. Details and source metadata MUST be redacted
for the authorized recipient.

Categories are:

| Category | Meaning | Native HTTP mapping |
|---|---|---:|
| `temporary` | Potentially recoverable failure | 503 |
| `permanent` | Request cannot succeed unchanged | 400 |
| `auth` | Authentication or authorization failure | 401 |
| `policy` | Authenticated request denied by policy | 403 |
| `economic` | Billing or settlement failure | 402 |
| `connector` | External integration failure | 502 |
| `transport` | Delivery-path failure | 503 |

A binding MAY define more specific statuses, but it MUST preserve the protocol
category.

### 19.2 Retry decision

A client or runtime MUST NOT retry solely because a category is `temporary` or
`transport`. Retry is allowed only when:

- the error and capability contract permit it;
- required idempotency is present;
- the deadline, policy, and approval remain valid;
- no unresolved provider outcome exists;
- retry delay and bounded backoff are observed.

### 19.3 Connector errors

Connector failures SHOULD preserve a provider request id, provider operation
reference, remote status, retryability, retry delay, failed connector operation,
uncertain-outcome flag, source component, and redacted details.

When `uncertain_outcome` is true for a mutation, the runtime MUST follow Section
13.6.

## 20. Native Transport Bindings

Transport bindings carry the same native envelope and MUST NOT alter semantic
meaning. Authentication, replay, size, timeout, and flow-control policy are
binding responsibilities.

### 20.1 Native HTTP JSON

The profile id is `aip.native.http.v1`.

Canonical endpoints are:

| Method | Path | Purpose |
|---|---|---|
| `POST` | `/aip/v1/messages` | Any native envelope |
| `POST` | `/aip/v1/actions` | Action invocation |
| `GET` | `/aip/v1/manifest` | Manifest discovery |

The operational read endpoints are specified in
[Native HTTP API](../reference/http-api.md). A complete envelope uses
`Content-Type: application/aip+json`. Implementations MUST bound request and
response size and MUST authenticate before returning protected operational
data.

HTTP connection loss does not cancel admitted work. Clients use action status,
events, callbacks, or idempotent replay to determine the outcome.

### 20.2 Server-Sent Events

The profile id is `aip.sse.stream.v1`. Each SSE event contains:

- `id` for replay;
- optional `retry` milliseconds;
- `event` name;
- `data` containing one complete envelope as compact JSON.

Standard event names are `ack`, `chunk`, `done`, `result`,
`delegation_request`, `delegation_result`, `heartbeat`, `heartbeat_ack`,
`error`, and `message`.

An action result, delegation result, protocol error, or `done` stream chunk is a
terminal SSE event for its correlation stream. A reconnect MAY use
`Last-Event-ID`. The server MUST preserve authorization during replay and MAY
reject an expired cursor.

### 20.3 WebSocket

The profile id is `aip.websocket.stream.v1`. One text frame contains one complete
JSON envelope. Binary data frames are unsupported in AIP 1.0; binary application
content is represented through message parts or resources.

Receivers MUST answer WebSocket ping with pong, process close frames, and reject
non-text data as unsupported. Multiplexing uses session id and message type;
correlation ids scope stream subscriptions.

The authenticated HTTP upgrade identity applies to the WebSocket connection.
Per-message authorization remains REQUIRED.

### 20.4 NATS

The profile id is `aip.native.nats.v1`.

The canonical request/reply subject is:

```text
aip.v1.<trust-domain>.<service>.<service-version>.<message-type>
```

Dots, spaces, forward slashes, and backslashes inside a subject component are
replaced with underscores. A service-wide subscriber uses:

```text
aip.v1.<trust-domain>.<service>.<service-version>.>
```

Correlation streams use:

```text
aip.v1.<trust-domain>.<service>.<service-version>.stream.<correlation-id>
```

Standard headers are `AIP-Version`, `AIP-Message-Type`, `AIP-Message-Id`, and,
when present, `AIP-Session-Id` and `AIP-Correlation-Id`.

The canonical payload is a JSON `TransportMessage` containing `envelope` and
optional normalized `metadata`. Receivers MAY accept a direct envelope for
compatibility, but senders SHOULD use the canonical wrapper.

NATS deployments MUST use accounts, credentials, TLS as applicable, subject
ACLs, and queue groups. Subject access is transport authorization and does not
replace capability authorization.

## 21. Compatibility Profiles

Compatibility profiles are versioned mappings at the gateway boundary. They
MUST NOT introduce foreign protocol DTOs into the native semantic core.

### 21.1 MCP

The profile id is `aip.mcp.compat.v1`. Supported stable MCP versions are
`2024-11-05`, `2025-03-26`, `2025-06-18`, and `2025-11-25`.

The profile maps tools, resources, prompts, completions, roots, sampling,
elicitation, logging, progress, cancellation, notifications, and tasks to the
applicable native AIP capabilities, resources, actions, events, and lifecycle
views.

MCP initialization and session ownership MUST complete before stateful methods
are accepted. Method availability MUST follow the negotiated MCP version.
Streamable HTTP MUST enforce session id, protocol version, origin policy,
content type, request bounds, replay ownership, and DELETE lifecycle. Legacy
HTTP+SSE is restricted to the `2024-11-05` compatibility binding.

MCP OAuth protection MUST bind issuer, audience/resource, subject, expiration,
and required scopes to a trusted AIP principal. Tool arguments MUST NOT override
the authenticated principal.

Native AIP semantics that cannot be represented by a base MCP object remain in
the AIP runtime and MAY be exposed through documented facade tools or metadata.
The profile MUST NOT claim an approval, transaction, idempotency, or
compensation guarantee that cannot be projected faithfully.

### 21.2 A2A compatibility

The profile id is `aip.a2a.compat.v1`. Agent cards, skills, tasks, messages,
artifacts, streaming, cancellation, subscriptions, and push notification
configuration are mapped at the profile boundary.

Native delegation remains the authoritative parent-child action model. An A2A
task projection MUST preserve lifecycle and authenticated peer identity without
placing A2A task objects in `aip-core`.

### 21.3 Webhook compatibility

The profile id is `aip.http.webhook.v1`. Inbound webhook profiles MUST verify
the raw payload signature, timestamp skew, body limit, source/subscription
binding, and delivery replay before parsing and emitting AIP envelopes.

Delivery ids SHOULD map to AIP idempotency keys. A successful webhook
acknowledgement means the event was durably admitted, not that every downstream
action completed.

## 22. Security Requirements

### 22.1 Threat model

AIP assumes that clients, connectors, external providers, network paths, and
message payloads may be malicious or faulty. A production gateway MUST fail
closed at authentication, authorization, schema, policy, tenant, credential,
replay, and side-effect ownership boundaries.

### 22.2 Signed native envelopes

The AIP 1.0 native signature profile uses Ed25519 and `did:key`.

1. `security` MUST be an object containing `did` and `signature`.
2. `did` MUST encode an Ed25519 public key as `did:key:z` followed by the
   base58btc encoding of multicodec bytes `0xed 0x01` and the 32-byte key.
3. To produce signing bytes, serialize the complete envelope, remove exactly
   `security.signature`, recursively sort all object member names, and encode
   compact UTF-8 JSON.
4. Sign those bytes with Ed25519.
5. Encode the 64-byte signature using standard Base64 and place it in
   `security.signature`.

Application fields named `signature` elsewhere in the envelope MUST remain
inside the signed data.

Signature verification proves key possession only. The verifier MUST bind the
DID to the expected principal and trust-domain policy before authorizing work.

### 22.3 Replay protection

A receiver MUST enforce an acceptable `sent_at` skew and durably claim signed
message ids or profile delivery ids for the configured replay window. Action
idempotency is additional protection and MUST NOT replace transport replay
claims.

### 22.4 Transport security

Network HTTP and WebSocket deployments SHOULD use TLS 1.2 or newer and SHOULD
prefer TLS 1.3. NATS deployments SHOULD use TLS and authenticated accounts.
Plaintext transports are acceptable only inside an explicitly controlled local
or equivalent protected boundary.

### 22.5 Authorization

Authorization MUST use transport-authenticated context. It MUST evaluate the
capability, action mode, side effects, risk, scopes, delegated authority,
tenant, credential policy, approval, transaction stage, resource sensitivity,
and requested read/export operation as applicable.

### 22.6 Tenant isolation

Tenant membership and external account binding MUST come from trusted identity
resolution. A request-supplied tenant id is a selector or claim, not authority.
Storage queries and connector credentials MUST be tenant-scoped.

### 22.7 Secret handling

Raw tokens, passwords, signing seeds, API keys, and client secrets MUST NOT be
serialized into manifests, envelopes, action input, errors, events, receipts,
audit records, or logs. Protocol objects carry opaque references. Secret
material SHOULD be loaded from owner-controlled files, workload identity, or a
secret manager and zeroized when practical.

### 22.8 Schema and size limits

Implementations MUST bound envelope, schema, string, collection, stream, and
provider-response sizes. Schema compilation SHOULD be isolated from async
worker stacks and MUST reject excessive depth, node count, or text size.

### 22.9 Privacy and redaction

Data classification and redaction policy apply to logs, traces, events,
callbacks, cross-domain delegation, approval evidence, and audit exports.
Restricted or regulated raw payloads MUST NOT be emitted to a broader audience
than the original action without explicit policy.

### 22.10 Key rotation

Deployments SHOULD add a new explicit signer binding, accept old and new keys
during a bounded overlap, migrate active sessions/callbacks, and then revoke the
old binding. A key published in a manifest is not trusted until policy admits it.

### 22.11 Optional session encryption

An encryption profile MAY negotiate ephemeral X25519 key agreement, derive a
256-bit key with HKDF-SHA256 using the session id as salt and
`aip-session-v1` as info, and encrypt with AES-256-GCM using unique 96-bit
nonces and authenticated associated data. The profile MUST define key lifetime,
nonce ownership, associated data, and rekey behavior.

## 23. Versioning and Extensions

### 23.1 Protocol version

`aip_version` identifies the native envelope contract. AIP 1.0 receivers MUST
accept `1.0` and MUST reject unsupported versions before message dispatch.

An incompatible envelope change requires a new major protocol version. An
additive change still requires a published schema and negotiated support; it
MUST NOT be smuggled into a closed typed object under the `1.0` schema.

### 23.2 Message families

The `v1` component in a message type versions that family. Incompatible body
semantics require a new family major and message type. Unknown types are
rejected unless an explicitly negotiated profile owns them.

### 23.3 Profiles

Transport and compatibility profiles version independently. A handshake or
manifest MUST identify the exact supported profile ids. Negotiation MUST select
only mutually supported versions.

### 23.4 Extensions

Extensions belong only in schema-defined extension objects. Extension keys
SHOULD use a collision-resistant namespace such as a reverse domain or URI.
Extensions MUST NOT weaken core validation, authentication, authorization,
idempotency, or lifecycle requirements.

A receiver MAY ignore an unknown non-critical extension. A sender that requires
extension behavior MUST negotiate a profile that defines it before sending the
message.

### 23.5 Deprecation

Deprecated capabilities remain discoverable with `stability: deprecated`
during their announced compatibility window. Providers SHOULD publish a
replacement reference in description or extension metadata and MUST NOT change
the old capability's semantics in place.

## 24. Conformance

### 24.1 Conformance statement

An implementation claiming AIP 1.0 conformance MUST publish:

- implementation and version;
- supported conformance classes;
- supported profiles and transports;
- schema revision or digest;
- known limits;
- any unsupported optional message families;
- conformance report and test-suite revision.

### 24.2 Conformance classes

| Class | Required behavior |
|---|---|
| Core producer | Emit schema-valid envelopes with correct type/body correlation |
| Core consumer | Decode, validate, reject unsupported input, and return typed errors |
| Discovery provider | Publish and atomically filter/admit valid manifests |
| Action runtime | Enforce admission, idempotency, lifecycle, result, cancellation, and recovery |
| Streaming runtime | Order, persist, replay, and terminate chunks correctly |
| Operational read model | Authorize and serve action/session/event queries with opaque cursors |
| Approval runtime | Persist requests, verify authority, enforce policy hash/TTL/SoD, and resume |
| Transaction runtime | Plan, claim commit, reconcile unknown outcomes, and compensate |
| Delegation runtime | Authenticate peers and retain durable parent-child graphs |
| Callback runtime | Validate targets and provide durable leased delivery/outbox behavior |
| Native HTTP binding | Implement native media, endpoints, status mapping, auth, and bounds |
| Native NATS binding | Implement subjects, headers, request/reply, auth, and queue behavior |
| MCP compatibility | Pass the declared stable-version method and transport matrix |
| Connector | Pass frozen SDK conformance for every advertised behavior |

An implementation MAY claim only the classes it implements. It MUST NOT claim
full AIP runtime conformance from core serialization alone.

### 24.3 Required test categories

Conformance suites MUST include:

- positive and negative schema fixtures;
- type/body and cross-field invariant tests;
- malformed, oversized, and unsupported input;
- authentication and authorization denial;
- duplicate and conflicting idempotency keys;
- lifecycle transitions and cancellation races;
- stream ordering, duplicate replay, reconnect, and terminal behavior;
- approval spoofing, expiration, revocation, quorum, and separation of duties;
- plan mutation, duplicate commit, stale lease, uncertain outcome, and
  reconciliation;
- delegation peer mismatch, scope escalation, loop, and parent recovery;
- callback SSRF, signature, retry, lease, and dead-letter behavior;
- tenant isolation and sensitive export denial;
- receipt-chain tampering.

### 24.4 External qualification

Repository-owned conformance does not prove independent interoperability or a
real provider. Compatibility and connector release claims SHOULD include
cross-process execution with independent implementations and retained,
secret-free evidence tied to exact source and image digests.

## 25. Standard Registries

### 25.1 Profile ids

The AIP 1.0 standard profile ids are:

| Profile id | Purpose |
|---|---|
| `aip.native.http.v1` | Native HTTP JSON |
| `aip.native.nats.v1` | Native NATS |
| `aip.sse.stream.v1` | Native SSE streaming |
| `aip.websocket.stream.v1` | Native WebSocket streaming |
| `aip.mcp.compat.v1` | MCP compatibility |
| `aip.a2a.compat.v1` | A2A compatibility |
| `aip.http.webhook.v1` | Signed HTTP webhook compatibility |

Connector-specific profile ids use `aip.connector.<name>.v1` but are not part
of the standard profile registry.

### 25.2 Event kinds and error codes

Standard event kinds and error codes use an `aip.` namespace. Connector or
provider codes SHOULD use a stable connector namespace. Registration MUST
document semantics, retry behavior, and data classification.

## 26. Reference Flows

### 26.1 Synchronous action

```text
Client -> Gateway: action
Gateway -> Runtime: validate, authorize, reserve
Runtime -> Handler: trusted action context
Handler -> Runtime: completed result
Runtime -> Client: action_result
Client -> Runtime: optional status/receipt query
```

### 26.2 Approval-gated commit

```text
Client -> Runtime: transaction plan
Runtime -> Client: durable plan
Client -> Runtime: commit(plan_id)
Runtime -> Policy: approval required
Runtime -> Approver: approval_request
Approver -> Runtime: signed/authenticated approval_decision
Runtime -> Connector: commit under atomic plan claim
Connector -> Runtime: committed result or uncertain outcome
Runtime -> Client: transaction_result and receipts
```

### 26.3 Remote delegation

```text
Parent -> Parent gateway: delegation_request
Parent gateway -> Remote gateway: authenticated delegation_request
Remote gateway -> Child handler: child action
Child handler -> Remote gateway: chunks and result
Remote gateway -> Parent gateway: authenticated delegation_result
Parent gateway -> Parent runtime: settle graph and callback
```

## Appendix A. JSON Schema Registry

The canonical schema files are:

- `envelope.schema.json`, `manifest.schema.json`, `manifest_filter.schema.json`;
- `action.schema.json`, `ack.schema.json`, `stream_chunk.schema.json`,
  `action_result.schema.json`;
- `action_status_request.schema.json`, `action_status.schema.json`,
  `action_result_request.schema.json`, `action_list_request.schema.json`,
  `action_list.schema.json`, `action_events_request.schema.json`, and
  `action_events.schema.json`;
- `capability_contract.schema.json`, `identity_context.schema.json`;
- `approval_request.schema.json`, `approval_decision.schema.json`,
  `approval_query_request.schema.json`, `approval_record_view.schema.json`,
  `approval_list_request.schema.json`, and `approval_list.schema.json`;
- `session_request.schema.json`, `session_view.schema.json`,
  `session_list_request.schema.json`, `session_list.schema.json`,
  `session_close_request.schema.json`, `session_resume_request.schema.json`, and
  `session_resume.schema.json`;
- `transaction_plan.schema.json`, `transaction_request.schema.json`,
  `transaction_result.schema.json`, `transaction_query_request.schema.json`, and
  `transaction_view.schema.json`;
- `delegation_request.schema.json`, `delegation_result.schema.json`;
- `resource_list_request.schema.json`, `resource_list.schema.json`,
  `resource_read_request.schema.json`, and `resource_read_result.schema.json`;
- `callback_delivery_policy.schema.json`,
  `callback_delivery_query_request.schema.json`,
  `callback_delivery_list_request.schema.json`,
  `callback_delivery_record.schema.json`, and
  `callback_delivery_list.schema.json`;
- `receipt_query_request.schema.json`, `audit_query_request.schema.json`, and
  `audit_query_result.schema.json`;
- `event.schema.json`, `event_stream.schema.json`, `channel_message.schema.json`,
  and `escalation.schema.json`.

Schema `$id` values use `https://aip.dev/schemas/aip/<file-name>`. A local or
offline implementation MAY resolve those ids to the versioned files in this
repository, but it MUST verify that the content matches its declared schema
revision.

## Appendix B. Relationship to RFCs

RFC 0001 defines the MCP compatibility analysis, RFC 0002 defines enterprise
capability, approval, and transaction decisions, RFC 0003 defines the native
operational read model, and RFC 0004 defines the frozen connector/runtime
boundary and qualification requirements. This specification incorporates their
accepted protocol semantics. RFC status ledgers remain implementation evidence
and do not override this normative contract.

## Appendix C. Normative References

- [BCP 14: RFC 2119, Key words for use in RFCs to Indicate Requirement
  Levels](https://www.rfc-editor.org/rfc/rfc2119)
- [BCP 14: RFC 8174, Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
  Words](https://www.rfc-editor.org/rfc/rfc8174)
- [RFC 3339, Date and Time on the Internet:
  Timestamps](https://www.rfc-editor.org/rfc/rfc3339)
- [RFC 4648, The Base16, Base32, and Base64 Data
  Encodings](https://www.rfc-editor.org/rfc/rfc4648)
- [RFC 5869, HMAC-based Extract-and-Expand Key Derivation Function
  (HKDF)](https://www.rfc-editor.org/rfc/rfc5869)
- [RFC 6455, The WebSocket Protocol](https://www.rfc-editor.org/rfc/rfc6455)
- [RFC 7662, OAuth 2.0 Token
  Introspection](https://www.rfc-editor.org/rfc/rfc7662)
- [RFC 7748, Elliptic Curves for
  Security](https://www.rfc-editor.org/rfc/rfc7748)
- [RFC 8032, Edwards-Curve Digital Signature Algorithm
  (EdDSA)](https://www.rfc-editor.org/rfc/rfc8032)
- [RFC 8259, The JavaScript Object Notation (JSON) Data Interchange
  Format](https://www.rfc-editor.org/rfc/rfc8259)
- [JSON Schema Draft 2020-12](https://json-schema.org/draft/2020-12)