Skip to content
AIPDocs
AIP 1.055 pagesNormative specification
Release status
DocumentationAIP 1.0Normative specificationProtocol Standard

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 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 and RFC 8174) 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

{
  "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:

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. 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:

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:

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

Correlation streams use:

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

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

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

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