{
  "schemaVersion": "1.0",
  "title": "Compatibility profiles",
  "description": "Use this reference to select an implemented AIP profile, match its stable version and route surface, and identify which semantics remain native AIP responsibilities. It covers the three compatibility profiles and four native transport profi",
  "canonical": "https://getaip.org/docs/spec/compatibility-profiles",
  "route": "/docs/spec/compatibility-profiles",
  "source": "docs/spec/compatibility-profiles.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Protocol Standard",
  "documentType": "Specification reference",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "97be86e9efedf07ecf1783b03800f683f107fb04",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/spec/compatibility-profiles.md",
    "txt": "/docs/download/spec/compatibility-profiles.txt",
    "json": "/docs/download/spec/compatibility-profiles.json",
    "pdf": "/docs/download/spec/compatibility-profiles.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Compatibility profiles\ndescription: Select an implemented AIP profile and look up its stable versions, routes, projections, and limits\nkind: reference\naudience: protocol-implementer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# Compatibility profiles\n\nUse this reference to select an implemented AIP profile, match its stable\nversion and route surface, and identify which semantics remain native AIP\nresponsibilities. It covers the three compatibility profiles and four native\ntransport profiles present in the reviewed source.\n\nThe normative compatibility boundary is defined by\n[AIP 1.0](AIP-1.0.md#21-compatibility-profiles). This page records the\nimplementation at revision\n`97be86e9efedf07ecf1783b03800f683f107fb04`; it does not extend that\nnormative contract or qualify a deployment.\n\n## Choose a profile\n\nThe profile identifier selects a defined mapping or binding. It does not name\na connector, process, credential, or deployment.\n\n| Profile ID | Class | Select it when |\n|---|---|---|\n| `aip.native.http.v1` | Native request/response binding | A client exchanges native envelopes or uses the daemon's native HTTP views |\n| `aip.native.nats.v1` | Native broker binding | A trusted deployment routes native envelopes through NATS subjects |\n| `aip.sse.stream.v1` | Native server-stream codec | A server emits one native envelope per SSE data field |\n| `aip.websocket.stream.v1` | Native bidirectional codec | Peers exchange one native envelope per WebSocket text frame |\n| `aip.mcp.compat.v1` | MCP compatibility profile | An MCP client needs a projected view of AIP capabilities and lifecycle |\n| `aip.a2a.compat.v1` | A2A compatibility profile | An A2A client needs Agent Card discovery and task-oriented operations |\n| `aip.http.webhook.v1` | Generic webhook verification profile | A connector normalizes and verifies a signed HTTP webhook before mapping it |\n\nNative bindings retain the AIP envelope as their application message.\nCompatibility profiles translate a foreign protocol's DTOs, lifecycle, and\nerrors at the edge. The [profiles and connectors](../concepts/profiles-and-connectors.md)\nconcept page explains this layer model; the sections below provide exact\nlookup tables for the implemented surface.\n\n## Shared profile boundary\n\nEvery profile adapter remains outside the native semantic core. A successful\nwire decode is only the first step:\n\n1. the selected profile validates its own framing and version rules;\n2. the adapter maps the request to a native message or bounded native query;\n3. the gateway authenticates the transport-bound principal and applies\n   validation, replay, authorization, approval, and lifecycle policy;\n4. the adapter projects the native result or typed error back to the foreign\n   protocol.\n\nA profile cannot weaken native admission rules. A foreign request ID, tool\nname, task ID, header, or Agent Card field does not independently establish an\nAIP principal, tenant, capability grant, approval, idempotency reservation, or\nterminal result.\n\nProfile support also has three separate meanings:\n\n| Claim | What it establishes |\n|---|---|\n| Identifier present in a manifest | The endpoint declares the profile |\n| Mapping present in source | The reviewed implementation contains the DTO or transport mapping |\n| Route enabled and qualified | An exact artifact and configuration passed the applicable checks |\n\nDo not infer the third claim from either of the first two.\n\n## MCP compatibility profile\n\n`aip.mcp.compat.v1` maps MCP JSON-RPC requests to AIP capabilities,\nresources, actions, cancellations, event views, and typed results. MCP\nsessions, request correlation, roots, sampling, elicitation, prompts,\ncompletions, and task views remain profile state; they do not become native AIP\nmessage families.\n\n### Stable protocol versions\n\nThe implementation recognizes four stable MCP versions. The method set is\nversioned even when two versions currently have the same count.\n\n| MCP version | Stable methods | Change from the 24-method base |\n|---|---:|---|\n| `2024-11-05` | 24 | Base set |\n| `2025-03-26` | 24 | Same implemented stable method set |\n| `2025-06-18` | 25 | Adds `elicitation/create` |\n| `2025-11-25` | 31 | Adds elicitation completion and five task methods |\n\nThe 24-method base is grouped here for exact lookup:\n\n| Group | Stable methods |\n|---|---|\n| Lifecycle and control | `initialize`, `notifications/initialized`, `ping`, `notifications/cancelled`, `notifications/progress` |\n| Tools | `tools/list`, `tools/call`, `notifications/tools/list_changed` |\n| Resources | `resources/list`, `resources/read`, `resources/templates/list`, `resources/subscribe`, `resources/unsubscribe`, `notifications/resources/list_changed`, `notifications/resources/updated` |\n| Prompts | `prompts/list`, `prompts/get`, `notifications/prompts/list_changed` |\n| Completion | `completion/complete` |\n| Logging | `logging/setLevel`, `notifications/message` |\n| Roots | `roots/list`, `notifications/roots/list_changed` |\n| Sampling | `sampling/createMessage` |\n\n`2025-11-25` adds\n`notifications/elicitation/complete`, `tasks/list`, `tasks/get`,\n`tasks/result`, `tasks/cancel`, and `notifications/tasks/status`.\nUnstable parser-only methods are excluded from this matrix and are not part of\nthe stable advertised surface.\n\n### MCP transports and routes\n\nTransport choice constrains the executable version matrix:\n\n| Transport | `2024-11-05` | `2025-03-26` | `2025-06-18` | `2025-11-25` |\n|---|:---:|:---:|:---:|:---:|\n| stdio | Yes | Yes | Yes | Yes |\n| Legacy HTTP and SSE | Yes | No | No | No |\n| Streamable HTTP | No | Yes | Yes | Yes |\n\nThe daemon exposes these network routes:\n\n| Surface | Method | Routes |\n|---|---|---|\n| Streamable HTTP | `GET`, `POST`, `DELETE` | `/mcp`, `/mcp/v1`, `/aip/v1/mcp` |\n| Legacy SSE stream | `GET` | `/mcp/legacy/sse` |\n| Legacy client messages | `POST` | `/mcp/legacy/messages` |\n| Protected-resource metadata | `GET` | `/.well-known/oauth-protected-resource`, `/.well-known/oauth-protected-resource/mcp` |\n\nOn Streamable HTTP, `POST` carries JSON-RPC messages, `GET` opens the\nserver event stream, and `DELETE` removes the addressed session. The\ntransport processes `MCP-Protocol-Version`, `MCP-Session-Id`, and\n`Last-Event-ID`. Authentication, allowed origins, request bounds, session\nownership, and resume behavior remain deployment and transport controls.\n\nstdio carries one JSON-RPC frame per line and relies on the spawning host for\nprocess identity and isolation. It has no HTTP bearer, Origin, or session-header\nboundary.\n\n### MCP projection and stable facade\n\n`tools/call` becomes a native `Action` and follows the same gateway and\nruntime path as a native request. Request-to-action correlation allows an MCP\ncancellation notification to target the active action. The result is projected\nback as MCP content, structured content, a task view when enabled, or a\nJSON-RPC error derived from the native error.\n\nThe server can expose generated tools for a bounded local manifest and stable\nAIP facade tools. The stable surface includes `aip_capabilities` for\ndiscovery and `aip_call` for invocation, plus focused lifecycle, event,\napproval, resource, receipt, transaction, and delegation tools.\n\nWhen a tenant-scoped connector catalog is installed, generated fleet\ncapabilities are not expanded into one global in-memory `tools/list`.\n`aip_capabilities` queries the catalog using the identity bound to the MCP\nsession and returns a bounded page with `catalog_revision`, `total`,\n`capabilities`, and `next_cursor`. This preserves tenant visibility and\nrevision-fenced pagination while keeping the MCP tool surface stable.\n\nServer features remain composition-dependent. A method may belong to the\nnegotiated MCP version while its provider is unavailable, disabled, or empty.\nFor example, roots, sampling, elicitation, dynamic notifications, tasks, and\ngenerated capability tools are advertised only when the active composition can\nserve the corresponding behavior.\n\nUse [AIP through MCP](../guides/use-aip-through-mcp.md) for a task-oriented\nconnection and invocation flow.\n\n## A2A compatibility profile\n\n`aip.a2a.compat.v1` maps Agent Card discovery, messages, tasks,\ncancellation, streaming, and push-notification configuration to native AIP\nmanifests, actions, results, events, and durable profile state.\n\n### Current A2A operations\n\nThe current advertised surface has eleven operation names:\n\n| Group | Operations |\n|---|---|\n| Send | `SendMessage`, `SendStreamingMessage` |\n| Read and follow tasks | `GetTask`, `ListTasks`, `SubscribeToTask` |\n| Cancel | `CancelTask` |\n| Push configuration | `CreateTaskPushNotificationConfig`, `GetTaskPushNotificationConfig`, `ListTaskPushNotificationConfigs`, `DeleteTaskPushNotificationConfig` |\n| Extended discovery | `GetExtendedAgentCard` |\n\nLegacy operation aliases may be accepted as inputs for compatibility, but they\nare not advertised as the current surface.\n\n### A2A routes\n\n| Surface | Method | Routes |\n|---|---|---|\n| Agent Card | `GET` | `/.well-known/agent-card.json`, `/.well-known/agent.json`, `/a2a/agent-card` |\n| JSON-RPC | `POST` | `/a2a`, `/a2a/v1`, `/aip/v1/a2a` |\n\nThe Agent Card can project manifest identity, documentation, skills, media\nmodes, interfaces, extensions, security schemes and requirements, signatures,\nand supported streaming, push, or extended-card features. The advertised\nfeature set must match the active composition.\n\n`SendMessage` and `SendStreamingMessage` create native actions.\n`CancelTask` creates a native cancellation. Task status and artifacts project\nfrom the durable action view, while subscriptions project the event stream.\nThe sender's message ID produces the native idempotency key\n`a2a-message:{message_id}`. Clients must reuse the message ID when retrying an\nuncertain send.\n\nPush configurations and delivery cursors are profile state, not fields copied\ninto the action. The daemon implementation encrypts stored push credentials,\nsigns outbound payloads, validates callback destinations against egress policy,\nand uses leased retryable delivery. Those controls describe the reviewed\ndaemon, not every independent implementation of the profile.\n\nUse [AIP through A2A](../guides/use-aip-through-a2a.md) for a complete\ndiscovery, send, stream, and recovery flow.\n\n## Generic HTTP webhook profile\n\n`aip.http.webhook.v1` defines a small provider-neutral signing and\nverification boundary. It normalizes five values:\n\n| Field | Meaning |\n|---|---|\n| `delivery` | Delivery identity supplied to the signing input |\n| `timestamp` | Unix time in seconds |\n| `signature` | Standard-base64 HMAC-SHA256 bytes |\n| `source_system` | Normalized source identifier |\n| `event_type` | Normalized source event type |\n\nThe signing input is the UTF-8 text\n`{timestamp}.{delivery}.{payload}`. Verification:\n\n1. rejects a timestamp whose absolute distance from current UTC time exceeds\n   the caller-supplied skew;\n2. recomputes HMAC-SHA256 with the configured secret;\n3. decodes the expected and supplied signatures from standard base64;\n4. rejects unequal lengths; and\n5. compares equal-length signature bytes in constant time.\n\nThe generic profile does not define raw HTTP header names, an ingress route,\npayload schema, replay store, delivery deduplication, provider parser, or\nnative message mapping. A connector owns those choices. It should verify the\noriginal request body before parsing, persist or reject repeated delivery IDs\naccording to its contract, and only then construct the appropriate native AIP\nmessage.\n\nBecause the signing helper treats the payload as UTF-8 text, a connector that\naccepts arbitrary binary request bodies needs an explicitly defined binary\ncanonicalization instead of assuming this profile covers it.\n\n## Native transport profiles\n\nThe four native profiles share the profile namespace but do not translate a\nforeign semantic model:\n\n| Profile | Implemented framing | Deployed daemon surface |\n|---|---|---|\n| `aip.native.http.v1` | Complete envelope encoded as JSON | Native message, action, manifest, and operational HTTP routes |\n| `aip.native.nats.v1` | JSON transport wrapper, with raw-envelope receive compatibility | Structured subjects, publish, and request/reply |\n| `aip.sse.stream.v1` | Complete envelope in each SSE `data` field | Durable event and action follow routes use a daemon-specific adapter |\n| `aip.websocket.stream.v1` | Complete envelope in each text frame | `GET /aip/v1/ws` adds envelope exchange and subscription control |\n\nThe framework-neutral SSE and WebSocket codecs use in-memory correlation or\nsession queues. Their cursors and frames are not the durable event query shape\nof the daemon adapters. NATS Core delivery does not imply JetStream retention,\nand HTTP reachability does not establish peer identity.\n\nUse [transport bindings](../reference/transport-bindings.md) for exact native\nroutes, media behavior, subjects, headers, framing, authentication, recovery,\nand implementation differences.\n\n## Negotiation and failure behavior\n\nProfile negotiation must select an identifier and version supported by both\npeers and executable on the chosen transport. A manifest declaration does not\noverride a transport-version restriction.\n\n| Failure | Interpretation |\n|---|---|\n| Unknown profile ID | No mapping is selected; reject or negotiate a supported profile |\n| Unsupported stable version | Do not silently use version-specific methods from another matrix |\n| Known method with unavailable provider | The protocol surface exists, but the active composition cannot serve it |\n| Mapping or schema error | Reject before native dispatch when no valid native request can be formed |\n| Native policy or authorization error | Project the typed native failure; do not reinterpret it as transport success |\n| Connection loss after dispatch | Preserve the original mutation identity and query durable native state |\n| Cursor rejected or expired | Re-establish the stream from a supported durable position and reconcile state |\n\nCompatibility does not provide exactly-once external effects. The native\ncapability contract, idempotency key, action status, transaction state,\nreceipts, and provider reconciliation remain authoritative after an uncertain\noutcome.\n\n## Conformance and evidence\n\nProfile unit tests establish deterministic DTO and mapping behavior for the\nreviewed source. Transport and server tests cover additional lifecycle and\nroute behavior. Neither proves that an arbitrary deployment has enabled the\nsame providers, identity configuration, durable stores, callbacks, or external\nsystems.\n\nA conformance claim must name the profile, protocol version, transport,\nimplementation revision, configuration boundary, suite, and retained result.\nProvider or connector qualification is a separate evidence layer. See\n[conformance and qualification](../reference/conformance.md) before publishing\na compatibility or readiness claim.\n\n## Related documentation\n\n- [AIP 1.0 normative specification](AIP-1.0.md)\n- [Profiles and connectors](../concepts/profiles-and-connectors.md)\n- [Transport bindings](../reference/transport-bindings.md)\n- [Conformance and qualification](../reference/conformance.md)\n",
    "text": "Compatibility profiles\n\nUse this reference to select an implemented AIP profile, match its stable\nversion and route surface, and identify which semantics remain native AIP\nresponsibilities. It covers the three compatibility profiles and four native\ntransport profiles present in the reviewed source.\n\nThe normative compatibility boundary is defined by\nAIP 1.0 (AIP-1.0.md#21-compatibility-profiles). This page records the\nimplementation at revision\n97be86e9efedf07ecf1783b03800f683f107fb04; it does not extend that\nnormative contract or qualify a deployment.\n\nChoose a profile\n\nThe profile identifier selects a defined mapping or binding. It does not name\na connector, process, credential, or deployment.\n\n| Profile ID | Class | Select it when |\n\n| aip.native.http.v1 | Native request/response binding | A client exchanges native envelopes or uses the daemon's native HTTP views |\n| aip.native.nats.v1 | Native broker binding | A trusted deployment routes native envelopes through NATS subjects |\n| aip.sse.stream.v1 | Native server-stream codec | A server emits one native envelope per SSE data field |\n| aip.websocket.stream.v1 | Native bidirectional codec | Peers exchange one native envelope per WebSocket text frame |\n| aip.mcp.compat.v1 | MCP compatibility profile | An MCP client needs a projected view of AIP capabilities and lifecycle |\n| aip.a2a.compat.v1 | A2A compatibility profile | An A2A client needs Agent Card discovery and task-oriented operations |\n| aip.http.webhook.v1 | Generic webhook verification profile | A connector normalizes and verifies a signed HTTP webhook before mapping it |\n\nNative bindings retain the AIP envelope as their application message.\nCompatibility profiles translate a foreign protocol's DTOs, lifecycle, and\nerrors at the edge. The profiles and connectors (../concepts/profiles-and-connectors.md)\nconcept page explains this layer model; the sections below provide exact\nlookup tables for the implemented surface.\n\nShared profile boundary\n\nEvery profile adapter remains outside the native semantic core. A successful\nwire decode is only the first step:\n1. the selected profile validates its own framing and version rules;\n2. the adapter maps the request to a native message or bounded native query;\n3. the gateway authenticates the transport-bound principal and applies\n   validation, replay, authorization, approval, and lifecycle policy;\n4. the adapter projects the native result or typed error back to the foreign\n   protocol.\n\nA profile cannot weaken native admission rules. A foreign request ID, tool\nname, task ID, header, or Agent Card field does not independently establish an\nAIP principal, tenant, capability grant, approval, idempotency reservation, or\nterminal result.\n\nProfile support also has three separate meanings:\n\n| Claim | What it establishes |\n\n| Identifier present in a manifest | The endpoint declares the profile |\n| Mapping present in source | The reviewed implementation contains the DTO or transport mapping |\n| Route enabled and qualified | An exact artifact and configuration passed the applicable checks |\n\nDo not infer the third claim from either of the first two.\n\nMCP compatibility profile\n\naip.mcp.compat.v1 maps MCP JSON-RPC requests to AIP capabilities,\nresources, actions, cancellations, event views, and typed results. MCP\nsessions, request correlation, roots, sampling, elicitation, prompts,\ncompletions, and task views remain profile state; they do not become native AIP\nmessage families.\n\nStable protocol versions\n\nThe implementation recognizes four stable MCP versions. The method set is\nversioned even when two versions currently have the same count.\n\n| MCP version | Stable methods | Change from the 24-method base |\n\n| 2024-11-05 | 24 | Base set |\n| 2025-03-26 | 24 | Same implemented stable method set |\n| 2025-06-18 | 25 | Adds elicitation/create |\n| 2025-11-25 | 31 | Adds elicitation completion and five task methods |\n\nThe 24-method base is grouped here for exact lookup:\n\n| Group | Stable methods |\n\n| Lifecycle and control | initialize, notifications/initialized, ping, notifications/cancelled, notifications/progress |\n| Tools | tools/list, tools/call, notifications/tools/listchanged |\n| Resources | resources/list, resources/read, resources/templates/list, resources/subscribe, resources/unsubscribe, notifications/resources/listchanged, notifications/resources/updated |\n| Prompts | prompts/list, prompts/get, notifications/prompts/listchanged |\n| Completion | completion/complete |\n| Logging | logging/setLevel, notifications/message |\n| Roots | roots/list, notifications/roots/listchanged |\n| Sampling | sampling/createMessage |\n\n2025-11-25 adds\nnotifications/elicitation/complete, tasks/list, tasks/get,\ntasks/result, tasks/cancel, and notifications/tasks/status.\nUnstable parser-only methods are excluded from this matrix and are not part of\nthe stable advertised surface.\n\nMCP transports and routes\n\nTransport choice constrains the executable version matrix:\n\n| Transport | 2024-11-05 | 2025-03-26 | 2025-06-18 | 2025-11-25 |\n\n| stdio | Yes | Yes | Yes | Yes |\n| Legacy HTTP and SSE | Yes | No | No | No |\n| Streamable HTTP | No | Yes | Yes | Yes |\n\nThe daemon exposes these network routes:\n\n| Surface | Method | Routes |\n\n| Streamable HTTP | GET, POST, DELETE | /mcp, /mcp/v1, /aip/v1/mcp |\n| Legacy SSE stream | GET | /mcp/legacy/sse |\n| Legacy client messages | POST | /mcp/legacy/messages |\n| Protected-resource metadata | GET | /.well-known/oauth-protected-resource, /.well-known/oauth-protected-resource/mcp |\n\nOn Streamable HTTP, POST carries JSON-RPC messages, GET opens the\nserver event stream, and DELETE removes the addressed session. The\ntransport processes MCP-Protocol-Version, MCP-Session-Id, and\nLast-Event-ID. Authentication, allowed origins, request bounds, session\nownership, and resume behavior remain deployment and transport controls.\n\nstdio carries one JSON-RPC frame per line and relies on the spawning host for\nprocess identity and isolation. It has no HTTP bearer, Origin, or session-header\nboundary.\n\nMCP projection and stable facade\n\ntools/call becomes a native Action and follows the same gateway and\nruntime path as a native request. Request-to-action correlation allows an MCP\ncancellation notification to target the active action. The result is projected\nback as MCP content, structured content, a task view when enabled, or a\nJSON-RPC error derived from the native error.\n\nThe server can expose generated tools for a bounded local manifest and stable\nAIP facade tools. The stable surface includes aipcapabilities for\ndiscovery and aipcall for invocation, plus focused lifecycle, event,\napproval, resource, receipt, transaction, and delegation tools.\n\nWhen a tenant-scoped connector catalog is installed, generated fleet\ncapabilities are not expanded into one global in-memory tools/list.\naipcapabilities queries the catalog using the identity bound to the MCP\nsession and returns a bounded page with catalogrevision, total,\ncapabilities, and nextcursor. This preserves tenant visibility and\nrevision-fenced pagination while keeping the MCP tool surface stable.\n\nServer features remain composition-dependent. A method may belong to the\nnegotiated MCP version while its provider is unavailable, disabled, or empty.\nFor example, roots, sampling, elicitation, dynamic notifications, tasks, and\ngenerated capability tools are advertised only when the active composition can\nserve the corresponding behavior.\n\nUse AIP through MCP (../guides/use-aip-through-mcp.md) for a task-oriented\nconnection and invocation flow.\n\nA2A compatibility profile\n\naip.a2a.compat.v1 maps Agent Card discovery, messages, tasks,\ncancellation, streaming, and push-notification configuration to native AIP\nmanifests, actions, results, events, and durable profile state.\n\nCurrent A2A operations\n\nThe current advertised surface has eleven operation names:\n\n| Group | Operations |\n\n| Send | SendMessage, SendStreamingMessage |\n| Read and follow tasks | GetTask, ListTasks, SubscribeToTask |\n| Cancel | CancelTask |\n| Push configuration | CreateTaskPushNotificationConfig, GetTaskPushNotificationConfig, ListTaskPushNotificationConfigs, DeleteTaskPushNotificationConfig |\n| Extended discovery | GetExtendedAgentCard |\n\nLegacy operation aliases may be accepted as inputs for compatibility, but they\nare not advertised as the current surface.\n\nA2A routes\n\n| Surface | Method | Routes |\n\n| Agent Card | GET | /.well-known/agent-card.json, /.well-known/agent.json, /a2a/agent-card |\n| JSON-RPC | POST | /a2a, /a2a/v1, /aip/v1/a2a |\n\nThe Agent Card can project manifest identity, documentation, skills, media\nmodes, interfaces, extensions, security schemes and requirements, signatures,\nand supported streaming, push, or extended-card features. The advertised\nfeature set must match the active composition.\n\nSendMessage and SendStreamingMessage create native actions.\nCancelTask creates a native cancellation. Task status and artifacts project\nfrom the durable action view, while subscriptions project the event stream.\nThe sender's message ID produces the native idempotency key\na2a-message:{messageid}. Clients must reuse the message ID when retrying an\nuncertain send.\n\nPush configurations and delivery cursors are profile state, not fields copied\ninto the action. The daemon implementation encrypts stored push credentials,\nsigns outbound payloads, validates callback destinations against egress policy,\nand uses leased retryable delivery. Those controls describe the reviewed\ndaemon, not every independent implementation of the profile.\n\nUse AIP through A2A (../guides/use-aip-through-a2a.md) for a complete\ndiscovery, send, stream, and recovery flow.\n\nGeneric HTTP webhook profile\n\naip.http.webhook.v1 defines a small provider-neutral signing and\nverification boundary. It normalizes five values:\n\n| Field | Meaning |\n\n| delivery | Delivery identity supplied to the signing input |\n| timestamp | Unix time in seconds |\n| signature | Standard-base64 HMAC-SHA256 bytes |\n| sourcesystem | Normalized source identifier |\n| eventtype | Normalized source event type |\n\nThe signing input is the UTF-8 text\n{timestamp}.{delivery}.{payload}. Verification:\n1. rejects a timestamp whose absolute distance from current UTC time exceeds\n   the caller-supplied skew;\n2. recomputes HMAC-SHA256 with the configured secret;\n3. decodes the expected and supplied signatures from standard base64;\n4. rejects unequal lengths; and\n5. compares equal-length signature bytes in constant time.\n\nThe generic profile does not define raw HTTP header names, an ingress route,\npayload schema, replay store, delivery deduplication, provider parser, or\nnative message mapping. A connector owns those choices. It should verify the\noriginal request body before parsing, persist or reject repeated delivery IDs\naccording to its contract, and only then construct the appropriate native AIP\nmessage.\n\nBecause the signing helper treats the payload as UTF-8 text, a connector that\naccepts arbitrary binary request bodies needs an explicitly defined binary\ncanonicalization instead of assuming this profile covers it.\n\nNative transport profiles\n\nThe four native profiles share the profile namespace but do not translate a\nforeign semantic model:\n\n| Profile | Implemented framing | Deployed daemon surface |\n\n| aip.native.http.v1 | Complete envelope encoded as JSON | Native message, action, manifest, and operational HTTP routes |\n| aip.native.nats.v1 | JSON transport wrapper, with raw-envelope receive compatibility | Structured subjects, publish, and request/reply |\n| aip.sse.stream.v1 | Complete envelope in each SSE data field | Durable event and action follow routes use a daemon-specific adapter |\n| aip.websocket.stream.v1 | Complete envelope in each text frame | GET /aip/v1/ws adds envelope exchange and subscription control |\n\nThe framework-neutral SSE and WebSocket codecs use in-memory correlation or\nsession queues. Their cursors and frames are not the durable event query shape\nof the daemon adapters. NATS Core delivery does not imply JetStream retention,\nand HTTP reachability does not establish peer identity.\n\nUse transport bindings (../reference/transport-bindings.md) for exact native\nroutes, media behavior, subjects, headers, framing, authentication, recovery,\nand implementation differences.\n\nNegotiation and failure behavior\n\nProfile negotiation must select an identifier and version supported by both\npeers and executable on the chosen transport. A manifest declaration does not\noverride a transport-version restriction.\n\n| Failure | Interpretation |\n\n| Unknown profile ID | No mapping is selected; reject or negotiate a supported profile |\n| Unsupported stable version | Do not silently use version-specific methods from another matrix |\n| Known method with unavailable provider | The protocol surface exists, but the active composition cannot serve it |\n| Mapping or schema error | Reject before native dispatch when no valid native request can be formed |\n| Native policy or authorization error | Project the typed native failure; do not reinterpret it as transport success |\n| Connection loss after dispatch | Preserve the original mutation identity and query durable native state |\n| Cursor rejected or expired | Re-establish the stream from a supported durable position and reconcile state |\n\nCompatibility does not provide exactly-once external effects. The native\ncapability contract, idempotency key, action status, transaction state,\nreceipts, and provider reconciliation remain authoritative after an uncertain\noutcome.\n\nConformance and evidence\n\nProfile unit tests establish deterministic DTO and mapping behavior for the\nreviewed source. Transport and server tests cover additional lifecycle and\nroute behavior. Neither proves that an arbitrary deployment has enabled the\nsame providers, identity configuration, durable stores, callbacks, or external\nsystems.\n\nA conformance claim must name the profile, protocol version, transport,\nimplementation revision, configuration boundary, suite, and retained result.\nProvider or connector qualification is a separate evidence layer. See\nconformance and qualification (../reference/conformance.md) before publishing\na compatibility or readiness claim.\n\nRelated documentation\n• AIP 1.0 normative specification (AIP-1.0.md)\n• Profiles and connectors (../concepts/profiles-and-connectors.md)\n• Transport bindings (../reference/transport-bindings.md)\n• Conformance and qualification (../reference/conformance.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "fd47f7b7ae8873783c11381852f480b12d616afadf81ef4f5696666f9ace025d"
  }
}