{
  "schemaVersion": "1.0",
  "title": "How AIP works",
  "description": "AIP turns a capability request into an identified, governed, and observable unit of work. This page is for developers who need to understand what happens between discovery and a terminal result before choosing an API, profile, connector, or",
  "canonical": "https://getaip.org/docs/getting-started/how-aip-works",
  "route": "/docs/getting-started/how-aip-works",
  "source": "docs/getting-started/how-aip-works.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Start Here",
  "documentType": "Getting started",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "d7cce13d1d555644d04a4d73c66c95b113737635",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/getting-started/how-aip-works.md",
    "txt": "/docs/download/getting-started/how-aip-works.txt",
    "json": "/docs/download/getting-started/how-aip-works.json",
    "pdf": "/docs/download/getting-started/how-aip-works.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: How AIP works\ndescription: Trace an AIP action from discovery through governed execution and durable observation\nkind: explanation\naudience: developer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"d7cce13d1d555644d04a4d73c66c95b113737635\"\n---\n\n# How AIP works\n\nAIP turns a capability request into an identified, governed, and observable unit\nof work. This page is for developers who need to understand what happens between\ndiscovery and a terminal result before choosing an API, profile, connector, or\ndeployment topology.\n\nThe semantic objects described here belong to AIP 1.0. Component behavior\ndescribes the Rust implementation at source revision\n`d7cce13d1d555644d04a4d73c66c95b113737635`. AIP does not require every\nimplementation to use the same process layout or storage backend.\n\n## The problem is larger than request delivery\n\nHTTP, a queue, or a tool protocol can deliver a payload. Delivery alone does not\nsettle identity, tenancy, approval, or whether a retry represents the same\nintent. It also does not define recovery when the provider may have committed\nbut its response was lost.\n\nAIP separates those concerns into durable semantic objects:\n\n| Concern | Main objects | Stable question answered |\n|---|---|---|\n| Discovery | `Manifest`, `Capability`, `CapabilityContract` | What can be requested, in which mode, and under which declared safety conditions? |\n| Identity | `Principal`, `Envelope`, `IdentityContext` | Who is acting, through which trusted boundary, and for which tenant or external account? |\n| Work | `Action`, `Ack`, `StreamChunk`, `ActionResult` | What logical operation was submitted, accepted, streamed, or completed? |\n| Governance | approval, idempotency, transaction, and delegation objects | Which authority, replay rule, or recovery contract governs the operation? |\n| Observation | `ActionStatus`, action events, receipts, and audit views | What does the receiving implementation durably know now? |\n\nThe envelope carries one protocol message. The action identifies the logical\nwork. The operational read model survives beyond one transport exchange when a\ndurable backend is configured.\n\n## The end-to-end action flow\n\nThe following sequence shows the reviewed Rust implementation. Boxes represent\nresponsibilities, not a required AIP deployment layout.\n\n```mermaid\nsequenceDiagram\n    participant C as Client or profile adapter\n    participant E as Authenticated edge\n    participant G as AIP gateway\n    participant R as Durable runtime\n    participant H as Local or remote handler\n    participant P as External product\n\n    C->>G: Discover manifest or tenant catalog\n    C->>E: Submit Action in an Envelope\n    E->>G: Verified actor and transport context\n    G->>G: Freshness, replay, identity, and query policy\n    G->>R: Action plus trusted MessageContext\n    R->>R: Contract, policy, idempotency, approval, transaction\n    alt asynchronous action\n        R-->>C: Ack queued\n        R->>H: Worker dispatches admitted action\n    else synchronous or streaming action\n        R->>H: Dispatch admitted action\n    end\n    opt remote product capability\n        H->>P: Provider-shaped request\n        P-->>H: Provider response or uncertain outcome\n    end\n    H-->>R: Chunks and terminal result\n    R-->>C: Result, stream, or callback\n    C->>G: Authorized status, event, or receipt query\n    G->>R: Read scoped durable state\n    R-->>C: Current operational view\n```\n\nIn text, the flow is:\n\n1. The caller discovers a callable contract from a manifest or, for a remote\n   fleet, a tenant-scoped capability catalog.\n2. A transport edge authenticates the peer and passes verified identity data to\n   the gateway. A profile adapter may first translate an MCP tool call or A2A\n   task operation into the same native action model.\n3. The gateway validates the envelope boundary, replaces payload identity with\n   the authenticated actor, resolves trusted tenant and credential context, and\n   applies replay and query policy.\n4. The runtime resolves the capability, validates the action against its\n   contract, applies authorization, acquires any idempotency reservation, and\n   handles approval or transaction preconditions.\n5. The runtime either returns a governed intermediate state, queues the action,\n   or dispatches it to an admitted local or remote handler.\n6. The handler emits ordered chunks when applicable and returns a terminal\n   result. A connector may call an external product behind its own credential\n   and network boundary.\n7. The runtime records the lifecycle data supported by its backend. Authorized\n   readers can query that state independently of the original response.\n\n## A callable surface exists before work is accepted\n\nDiscovery and execution are coupled deliberately. For local capabilities, the\nruntime's production admission path validates the manifest, schemas, profile\nidentifiers, and implementation claims. It then requires the callable\ncapability IDs to match the supplied handler IDs before publishing discovery and\nhandler state together. A declared operation cannot become callable through\nthis path without an implementation owner.\n\nRemote fleet capabilities use a different boundary. The product-neutral daemon\ninstalls the tenant-scoped catalog and one shared remote handler as an\ninseparable pair. The normalized connector registry supplies admitted\ncapability bindings and ready replicas; product implementations remain in\nstandalone connector hosts. The daemon therefore does not load product crates\nor product credentials to expose their capabilities.\n\nDiscovery is still a snapshot, not proof that an external product will remain\nreachable. Admission, current replica readiness, caller authorization, and\nprovider availability are separate decisions.\n\n## Trusted ingress replaces payload claims\n\nAn AIP envelope can contain `from`, `to`, session, correlation, idempotency, and\nsecurity metadata. Those fields describe the message, but a self-asserted\n`from` value does not authenticate a caller.\n\nThe reviewed gateway has separate entry points for a directly verified\nenvelope, an authenticated edge, and a complete deployment-owned identity\nresolution result. Each trusted path replaces `Envelope.from` with the verified\nprincipal. For actions, the gateway can resolve tenant membership and a\ncredential handle before dispatch; the runtime then replaces the action's\npayload-supplied identity context with that resolved context.\n\nSigned native envelopes add integrity and peer verification. The gateway also\nuses a state-backed message-ID replay claim and a freshness window when replay\nrejection is enabled. Neither a valid signature nor a fresh message grants\npermission by itself. Capability policy, scopes, tenant membership, object\nownership, delegated authority, and approval remain distinct checks.\n\nRaw provider credentials do not belong in manifests, action inputs, or\nidentity claims. Capability contracts describe credential requirements, while\nthe deployment resolves a protected credential handle and the connector owns\nthe provider-specific secret boundary.\n\n## Governance happens before handler execution\n\nFor a normal action, the reviewed runtime performs the following decisions\nbefore calling a handler:\n\n1. It rejects reuse of an existing action ID for different work when durable\n   action state already exists.\n2. It resolves the applicable capability for the trusted context.\n3. It validates the input schema, invocation mode, capability contract, and\n   resolved credential context.\n4. It evaluates authorization and any transaction-specific policy.\n5. It derives the declared idempotency scope and acquires a durable reservation\n   when the contract requires one.\n6. It validates an attached approval decision or creates a durable pending\n   approval when policy requires human authority.\n7. It applies supported transaction preconditions, prepares a frozen execution\n   context, and selects the admitted handler.\n\nAn action ID and an idempotency key solve different problems. The action ID\nnames one logical action and its lifecycle. An idempotency key fences replay of\na provider-sensitive intent within the scope declared by the capability. A new\naction ID or key can represent new work; it is not a recovery mechanism for an\nambiguous mutation.\n\n## Execution follows the declared mode and contracts\n\nThe action mode changes the immediate protocol response, while the capability\ncontract limits which modes and recovery behaviors are valid.\n\n| Path | Immediate behavior in the reviewed runtime | Durable continuation |\n|---|---|---|\n| Synchronous | The runtime executes the handler and returns an `ActionResult` | The terminal result and lifecycle record are persisted when the selected backend supports them |\n| Asynchronous | The runtime reserves governance state, enqueues the action, and returns an `Ack` with status `queued` | A worker leases the same action record, executes it, and settles its result |\n| Streaming | The handler can emit monotonic `StreamChunk` records before returning an `ActionResult` | Chunks and the terminal result can be read independently of the live stream |\n| Pending approval | The runtime returns an action result with status `pending_approval` and retains the approval request | A verified decision advances the same governed action rather than creating unrelated work |\n| Transactional | `dry_run`, `plan`, `commit`, `compensate`, `reconcile`, or `rollback_not_supported` behavior is checked against the capability contract | Plans, provider operation checkpoints, transaction state, and reconciliation data remain correlated with the action |\n\nCancellation is cooperative. The runtime signals the active handler and calls\nits capability-specific cancellation implementation only when the admitted\nsupport and contract permit cancellation. A cancellation request cannot prove\nthat an external provider stopped unless the connector can establish that\noutcome.\n\n## Local and fleet handlers share the runtime contract\n\nA trusted local module executes inside the daemon's startup composition. Its\nhandler receives a frozen execution context containing the authenticated actor,\nverified tenant and credential state, cancellation token, stream publisher,\napproval evidence, timeout, and transaction checkpoint support relevant to the\ncapability.\n\nA fleet capability reaches the same runtime through the shared remote handler.\nThat handler requires a verified tenant, applies bounded fair admission, asks\nthe registry for a deterministic route assignment, and dispatches the action to\nthe assigned connector host. The assignment is reused for retry and\ncancellation. The host executes exactly its compiled product adapter and\nreturns a signed, correlated native result.\n\nIf remote dispatch fails after the provider may have changed state, the route\nsettlement records an unknown outcome rather than declaring the operation safe\nto repeat. A transactional connector can persist a provider operation reference\nand reconcile it. The external product remains the source of truth for its own\nstate.\n\n## Durable observation is separate from the response\n\nThe original exchange can return an acknowledgement, chunks, a final result,\nor an error. It cannot tell a disconnected caller what happened afterward.\nThe runtime therefore exposes action status, result, event, receipt, approval,\ntransaction, callback-delivery, session, audit, and resource read models as\nseparate protocol families.\n\nThe daemon's HTTP read routes convert those queries into native message bodies\nand send them through the same gateway policy boundary. Query authorization can\nenforce actor scopes, tenant selection, session ownership, and broader\n`read:any` authority. Knowing an action ID is not sufficient authorization to\nread it.\n\nDurability depends on deployment composition. The implementation offers\nin-memory, file-backed, and PostgreSQL-backed paths. In-memory state does not\nsurvive process loss, file-backed state is local to one durable directory, and\nthe reference clustered topology uses PostgreSQL so gateway replicas can share\noperational state. A protocol lifecycle object does not by itself select or\nqualify one of those backends.\n\n## Trust and data boundaries\n\n| Boundary | Trusted input created there | Data that remains untrusted or externally owned |\n|---|---|---|\n| Client to edge | Authenticated principal, transport credential status, and request limits | Payload sender claims and requested tenant selectors |\n| Edge to gateway | Verified actor and, when resolved, tenant and credential handles | Permission to invoke a specific capability until policy evaluation |\n| Gateway to runtime | Frozen message context, selected capability contract, and governed identities | Provider outcome and any undeclared handler behavior |\n| Runtime to connector host | Assigned action, bounded execution context, approval and idempotency state | Raw product secret material, which the host resolves locally |\n| Connector to product | Provider-specific authenticated request | Provider availability, commit semantics, and system-of-record state |\n| Runtime to observer | Authorized lifecycle and evidence view | Conclusions beyond the retained artifact, topology, and time window |\n\nThese boundaries let an implementation fail closed without pretending that one\nsignature, database, or receipt establishes every kind of trust.\n\n## Design choices and trade-offs\n\n- **One semantic core, several integration surfaces.** Native HTTP, NATS, SSE,\n  and WebSocket bindings coexist with MCP and A2A compatibility profiles. Each\n  surface still has its own authentication, delivery, and projection limits.\n- **Explicit lifecycle over one-shot inference.** Durable status and event\n  queries make disconnect recovery possible. They require storage, retention,\n  authorization, and operational maintenance.\n- **Declared contracts plus admitted support.** Contracts expose risk and\n  recovery behavior before execution. They remain declarations until an\n  implementation path validates and enforces them.\n- **Product-neutral gateway plus standalone hosts.** The fleet can add or scale\n  an admitted connector without recompiling `getaip-server`. It adds registry, lease,\n  routing, host identity, and remote-failure concerns.\n- **Idempotent intent rather than an exactly-once promise.** Durable reservations\n  and provider keys reduce duplicate effects. Ambiguous provider commits still\n  require reconciliation or a conservative terminal state.\n\n## What this flow does not mean\n\n- AIP 1.0 does not require one Rust daemon, one database, or one transport.\n- A declared capability does not prove that a particular build or deployment is\n  conformant, qualified, or ready for production.\n- A successful response does not authorize another reader to inspect the action.\n- A queued or pending-approval response is not a terminal provider result.\n- A cancellation request, retry flag, receipt, or idempotency key does not turn\n  an uncertain external mutation into a guaranteed rollback or exactly-once\n  effect.\n- Compatibility profiles project supported semantics; they do not make every\n  MCP or A2A feature identical to native AIP.\n\n## Related pages\n\n- [Capabilities and contracts](../concepts/capabilities.md)\n- [Actions and sessions](../concepts/actions-and-sessions.md)\n- [Identity and trust](../concepts/identity-and-trust.md)\n- [Architecture overview](../architecture/overview.md)\n- [AIP 1.0 specification](../spec/AIP-1.0.md)\n",
    "text": "How AIP works\n\nAIP turns a capability request into an identified, governed, and observable unit\nof work. This page is for developers who need to understand what happens between\ndiscovery and a terminal result before choosing an API, profile, connector, or\ndeployment topology.\n\nThe semantic objects described here belong to AIP 1.0. Component behavior\ndescribes the Rust implementation at source revision\nd7cce13d1d555644d04a4d73c66c95b113737635. AIP does not require every\nimplementation to use the same process layout or storage backend.\n\nThe problem is larger than request delivery\n\nHTTP, a queue, or a tool protocol can deliver a payload. Delivery alone does not\nsettle identity, tenancy, approval, or whether a retry represents the same\nintent. It also does not define recovery when the provider may have committed\nbut its response was lost.\n\nAIP separates those concerns into durable semantic objects:\n\n| Concern | Main objects | Stable question answered |\n\n| Discovery | Manifest, Capability, CapabilityContract | What can be requested, in which mode, and under which declared safety conditions? |\n| Identity | Principal, Envelope, IdentityContext | Who is acting, through which trusted boundary, and for which tenant or external account? |\n| Work | Action, Ack, StreamChunk, ActionResult | What logical operation was submitted, accepted, streamed, or completed? |\n| Governance | approval, idempotency, transaction, and delegation objects | Which authority, replay rule, or recovery contract governs the operation? |\n| Observation | ActionStatus, action events, receipts, and audit views | What does the receiving implementation durably know now? |\n\nThe envelope carries one protocol message. The action identifies the logical\nwork. The operational read model survives beyond one transport exchange when a\ndurable backend is configured.\n\nThe end-to-end action flow\n\nThe following sequence shows the reviewed Rust implementation. Boxes represent\nresponsibilities, not a required AIP deployment layout.\n\nsequenceDiagram\n    participant C as Client or profile adapter\n    participant E as Authenticated edge\n    participant G as AIP gateway\n    participant R as Durable runtime\n    participant H as Local or remote handler\n    participant P as External product\n\n    C->>G: Discover manifest or tenant catalog\n    C->>E: Submit Action in an Envelope\n    E->>G: Verified actor and transport context\n    G->>G: Freshness, replay, identity, and query policy\n    G->>R: Action plus trusted MessageContext\n    R->>R: Contract, policy, idempotency, approval, transaction\n    alt asynchronous action\n        R-->>C: Ack queued\n        R->>H: Worker dispatches admitted action\n    else synchronous or streaming action\n        R->>H: Dispatch admitted action\n    end\n    opt remote product capability\n        H->>P: Provider-shaped request\n        P-->>H: Provider response or uncertain outcome\n    end\n    H-->>R: Chunks and terminal result\n    R-->>C: Result, stream, or callback\n    C->>G: Authorized status, event, or receipt query\n    G->>R: Read scoped durable state\n    R-->>C: Current operational view\n\nIn text, the flow is:\n1. The caller discovers a callable contract from a manifest or, for a remote\n   fleet, a tenant-scoped capability catalog.\n2. A transport edge authenticates the peer and passes verified identity data to\n   the gateway. A profile adapter may first translate an MCP tool call or A2A\n   task operation into the same native action model.\n3. The gateway validates the envelope boundary, replaces payload identity with\n   the authenticated actor, resolves trusted tenant and credential context, and\n   applies replay and query policy.\n4. The runtime resolves the capability, validates the action against its\n   contract, applies authorization, acquires any idempotency reservation, and\n   handles approval or transaction preconditions.\n5. The runtime either returns a governed intermediate state, queues the action,\n   or dispatches it to an admitted local or remote handler.\n6. The handler emits ordered chunks when applicable and returns a terminal\n   result. A connector may call an external product behind its own credential\n   and network boundary.\n7. The runtime records the lifecycle data supported by its backend. Authorized\n   readers can query that state independently of the original response.\n\nA callable surface exists before work is accepted\n\nDiscovery and execution are coupled deliberately. For local capabilities, the\nruntime's production admission path validates the manifest, schemas, profile\nidentifiers, and implementation claims. It then requires the callable\ncapability IDs to match the supplied handler IDs before publishing discovery and\nhandler state together. A declared operation cannot become callable through\nthis path without an implementation owner.\n\nRemote fleet capabilities use a different boundary. The product-neutral daemon\ninstalls the tenant-scoped catalog and one shared remote handler as an\ninseparable pair. The normalized connector registry supplies admitted\ncapability bindings and ready replicas; product implementations remain in\nstandalone connector hosts. The daemon therefore does not load product crates\nor product credentials to expose their capabilities.\n\nDiscovery is still a snapshot, not proof that an external product will remain\nreachable. Admission, current replica readiness, caller authorization, and\nprovider availability are separate decisions.\n\nTrusted ingress replaces payload claims\n\nAn AIP envelope can contain from, to, session, correlation, idempotency, and\nsecurity metadata. Those fields describe the message, but a self-asserted\nfrom value does not authenticate a caller.\n\nThe reviewed gateway has separate entry points for a directly verified\nenvelope, an authenticated edge, and a complete deployment-owned identity\nresolution result. Each trusted path replaces Envelope.from with the verified\nprincipal. For actions, the gateway can resolve tenant membership and a\ncredential handle before dispatch; the runtime then replaces the action's\npayload-supplied identity context with that resolved context.\n\nSigned native envelopes add integrity and peer verification. The gateway also\nuses a state-backed message-ID replay claim and a freshness window when replay\nrejection is enabled. Neither a valid signature nor a fresh message grants\npermission by itself. Capability policy, scopes, tenant membership, object\nownership, delegated authority, and approval remain distinct checks.\n\nRaw provider credentials do not belong in manifests, action inputs, or\nidentity claims. Capability contracts describe credential requirements, while\nthe deployment resolves a protected credential handle and the connector owns\nthe provider-specific secret boundary.\n\nGovernance happens before handler execution\n\nFor a normal action, the reviewed runtime performs the following decisions\nbefore calling a handler:\n1. It rejects reuse of an existing action ID for different work when durable\n   action state already exists.\n2. It resolves the applicable capability for the trusted context.\n3. It validates the input schema, invocation mode, capability contract, and\n   resolved credential context.\n4. It evaluates authorization and any transaction-specific policy.\n5. It derives the declared idempotency scope and acquires a durable reservation\n   when the contract requires one.\n6. It validates an attached approval decision or creates a durable pending\n   approval when policy requires human authority.\n7. It applies supported transaction preconditions, prepares a frozen execution\n   context, and selects the admitted handler.\n\nAn action ID and an idempotency key solve different problems. The action ID\nnames one logical action and its lifecycle. An idempotency key fences replay of\na provider-sensitive intent within the scope declared by the capability. A new\naction ID or key can represent new work; it is not a recovery mechanism for an\nambiguous mutation.\n\nExecution follows the declared mode and contracts\n\nThe action mode changes the immediate protocol response, while the capability\ncontract limits which modes and recovery behaviors are valid.\n\n| Path | Immediate behavior in the reviewed runtime | Durable continuation |\n\n| Synchronous | The runtime executes the handler and returns an ActionResult | The terminal result and lifecycle record are persisted when the selected backend supports them |\n| Asynchronous | The runtime reserves governance state, enqueues the action, and returns an Ack with status queued | A worker leases the same action record, executes it, and settles its result |\n| Streaming | The handler can emit monotonic StreamChunk records before returning an ActionResult | Chunks and the terminal result can be read independently of the live stream |\n| Pending approval | The runtime returns an action result with status pendingapproval and retains the approval request | A verified decision advances the same governed action rather than creating unrelated work |\n| Transactional | dryrun, plan, commit, compensate, reconcile, or rollbacknotsupported behavior is checked against the capability contract | Plans, provider operation checkpoints, transaction state, and reconciliation data remain correlated with the action |\n\nCancellation is cooperative. The runtime signals the active handler and calls\nits capability-specific cancellation implementation only when the admitted\nsupport and contract permit cancellation. A cancellation request cannot prove\nthat an external provider stopped unless the connector can establish that\noutcome.\n\nLocal and fleet handlers share the runtime contract\n\nA trusted local module executes inside the daemon's startup composition. Its\nhandler receives a frozen execution context containing the authenticated actor,\nverified tenant and credential state, cancellation token, stream publisher,\napproval evidence, timeout, and transaction checkpoint support relevant to the\ncapability.\n\nA fleet capability reaches the same runtime through the shared remote handler.\nThat handler requires a verified tenant, applies bounded fair admission, asks\nthe registry for a deterministic route assignment, and dispatches the action to\nthe assigned connector host. The assignment is reused for retry and\ncancellation. The host executes exactly its compiled product adapter and\nreturns a signed, correlated native result.\n\nIf remote dispatch fails after the provider may have changed state, the route\nsettlement records an unknown outcome rather than declaring the operation safe\nto repeat. A transactional connector can persist a provider operation reference\nand reconcile it. The external product remains the source of truth for its own\nstate.\n\nDurable observation is separate from the response\n\nThe original exchange can return an acknowledgement, chunks, a final result,\nor an error. It cannot tell a disconnected caller what happened afterward.\nThe runtime therefore exposes action status, result, event, receipt, approval,\ntransaction, callback-delivery, session, audit, and resource read models as\nseparate protocol families.\n\nThe daemon's HTTP read routes convert those queries into native message bodies\nand send them through the same gateway policy boundary. Query authorization can\nenforce actor scopes, tenant selection, session ownership, and broader\nread:any authority. Knowing an action ID is not sufficient authorization to\nread it.\n\nDurability depends on deployment composition. The implementation offers\nin-memory, file-backed, and PostgreSQL-backed paths. In-memory state does not\nsurvive process loss, file-backed state is local to one durable directory, and\nthe reference clustered topology uses PostgreSQL so gateway replicas can share\noperational state. A protocol lifecycle object does not by itself select or\nqualify one of those backends.\n\nTrust and data boundaries\n\n| Boundary | Trusted input created there | Data that remains untrusted or externally owned |\n\n| Client to edge | Authenticated principal, transport credential status, and request limits | Payload sender claims and requested tenant selectors |\n| Edge to gateway | Verified actor and, when resolved, tenant and credential handles | Permission to invoke a specific capability until policy evaluation |\n| Gateway to runtime | Frozen message context, selected capability contract, and governed identities | Provider outcome and any undeclared handler behavior |\n| Runtime to connector host | Assigned action, bounded execution context, approval and idempotency state | Raw product secret material, which the host resolves locally |\n| Connector to product | Provider-specific authenticated request | Provider availability, commit semantics, and system-of-record state |\n| Runtime to observer | Authorized lifecycle and evidence view | Conclusions beyond the retained artifact, topology, and time window |\n\nThese boundaries let an implementation fail closed without pretending that one\nsignature, database, or receipt establishes every kind of trust.\n\nDesign choices and trade-offs\n• One semantic core, several integration surfaces. Native HTTP, NATS, SSE,\n  and WebSocket bindings coexist with MCP and A2A compatibility profiles. Each\n  surface still has its own authentication, delivery, and projection limits.\n• Explicit lifecycle over one-shot inference. Durable status and event\n  queries make disconnect recovery possible. They require storage, retention,\n  authorization, and operational maintenance.\n• Declared contracts plus admitted support. Contracts expose risk and\n  recovery behavior before execution. They remain declarations until an\n  implementation path validates and enforces them.\n• Product-neutral gateway plus standalone hosts. The fleet can add or scale\n  an admitted connector without recompiling getaip-server. It adds registry, lease,\n  routing, host identity, and remote-failure concerns.\n• Idempotent intent rather than an exactly-once promise. Durable reservations\n  and provider keys reduce duplicate effects. Ambiguous provider commits still\n  require reconciliation or a conservative terminal state.\n\nWhat this flow does not mean\n• AIP 1.0 does not require one Rust daemon, one database, or one transport.\n• A declared capability does not prove that a particular build or deployment is\n  conformant, qualified, or ready for production.\n• A successful response does not authorize another reader to inspect the action.\n• A queued or pending-approval response is not a terminal provider result.\n• A cancellation request, retry flag, receipt, or idempotency key does not turn\n  an uncertain external mutation into a guaranteed rollback or exactly-once\n  effect.\n• Compatibility profiles project supported semantics; they do not make every\n  MCP or A2A feature identical to native AIP.\n\nRelated pages\n• Capabilities and contracts (../concepts/capabilities.md)\n• Actions and sessions (../concepts/actions-and-sessions.md)\n• Identity and trust (../concepts/identity-and-trust.md)\n• Architecture overview (../architecture/overview.md)\n• AIP 1.0 specification (../spec/AIP-1.0.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "f2cbf59922d8c57d16f682b5f6b54327564d8f67fd73a0d33f5e8c49a12fb572"
  }
}