{
  "schemaVersion": "1.0",
  "title": "Architecture overview",
  "description": "Use this page to understand which component owns each decision and state transition in the reviewed AIP implementation. It is for developers, connector developers, operators, and security reviewers who need a complete component map before c",
  "canonical": "https://getaip.org/docs/architecture/overview",
  "route": "/docs/architecture/overview",
  "source": "docs/architecture/overview.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Architecture and Security",
  "documentType": "Architecture",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "d7cce13d1d555644d04a4d73c66c95b113737635",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/architecture/overview.md",
    "txt": "/docs/download/architecture/overview.txt",
    "json": "/docs/download/architecture/overview.json",
    "pdf": "/docs/download/architecture/overview.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Architecture overview\ndescription: Understand the component, control, persistence, and failure boundaries in the AIP implementation\nkind: explanation\naudience: developer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"d7cce13d1d555644d04a4d73c66c95b113737635\"\n---\n\n# Architecture overview\n\nUse this page to understand which component owns each decision and state\ntransition in the reviewed AIP implementation. It is for developers, connector\ndevelopers, operators, and security reviewers who need a complete component map\nbefore changing an execution, fleet, storage, or trust boundary.\n\nThe architecture describes version `2.0.0` of the Rust workspace at source\nrevision `d7cce13d1d555644d04a4d73c66c95b113737635`. AIP 1.0 defines\ninteroperable message and lifecycle meaning; it does not require this Rust\ncrate layout, process topology, database, or orchestration model.\n\n## Why ownership boundaries matter\n\nAn AIP action can cross transport decoding, authentication, policy, durable\nlifecycle state, tenant routing, a connector process, and an external product.\nTreating that path as one undifferentiated service obscures who may establish\nidentity, where a secret may exist, which store survives a restart, and which\ncomponent can safely retry an uncertain operation.\n\nThe reviewed implementation keeps those concerns separate. The semantic core\ndoes not depend on networking or products. Compatibility profiles do not own\nnative action state. The target fleet composition keeps the six maintained\nproduct adapters and their provider credentials outside the primary daemon.\nConnector lifecycle control cannot admit a new artifact, and the registry does\nnot execute an image or call a provider.\n\n## The six-boundary model\n\n| Boundary | Primary responsibility | Authority it does not gain |\n|---|---|---|\n| Semantic contract | Native IDs, envelopes, message and domain objects, and pure validation | Network identity, persistence, product behavior, or deployment policy |\n| Ingress and projection | Native transport framing plus bounded MCP, A2A, and webhook mappings | Permission to invoke a capability or redefine native lifecycle meaning |\n| Central execution | Gateway authentication and policy composition plus runtime lifecycle, queues, approvals, transactions, and observation | Raw provider credentials or external product truth |\n| Connector fleet data path | Tenant catalog, immutable route assignment, signed remote dispatch, host execution, and event return | Connector release admission or arbitrary target selection by payload |\n| Fleet release and lifecycle control | Signed admission, registry administration, host leases, and platform-neutral orchestration | Client action execution, provider mutation, or secret resolution |\n| Persistence and evidence | Runtime records, registry rows, host-local durable state, provider records, and retained artifact evidence | A broader claim than the identity, topology, and procedure of each record |\n\nThese are ownership boundaries, not mandatory process counts. A small trusted\ndeployment can use a local module and file-backed state. A clustered connector\nfleet uses separate central, registry, lifecycle, host, and provider boundaries.\n\n## Component map\n\nThe solid arrows below show action and result flow. Dashed arrows show release,\ndeployment, or host-lifecycle control that is intentionally outside the action\npath.\n\n~~~mermaid\nflowchart LR\n    N[\"Native AIP client\"] --> T[\"Native transport edge\"]\n    F[\"MCP or A2A client\"] --> P[\"Compatibility profile\"]\n    T --> G[\"Gateway\"]\n    P --> G\n    G --> R[\"Durable runtime\"]\n    R --> L[\"Trusted local module\"]\n    R --> D[\"Tenant catalog and remote handler\"]\n    D --> H[\"Standalone connector host\"]\n    H --> X[\"External product\"]\n    R --> S[\"Runtime stores\"]\n    D --> Q[\"Connector registry\"]\n    H -.->|register, heartbeat, drain| C[\"Lifecycle control plane\"]\n    C -.->|lease and status| Q\n    A[\"Signed connector admission\"] -.->|atomic catalog change| Q\n    O[\"External orchestrator\"] -.->|exact admitted process| H\n~~~\n\nThe text equivalent is:\n\n1. A native transport decodes an AIP envelope, or a compatibility profile maps\n   a foreign request into native AIP.\n2. The gateway establishes the authenticated actor, resolves trusted identity\n   and tenant context, validates the message boundary, and applies policy.\n3. The runtime owns action governance and durable lifecycle state.\n4. A trusted local capability executes through a startup-admitted local module.\n   A fleet capability instead uses the tenant catalog and shared remote handler.\n5. The remote handler persists an action-specific route before dispatching a\n   signed native request to the assigned connector host.\n6. The host verifies the pinned route and its lease, resolves provider\n   credentials inside its process, and invokes the external product.\n7. Results, chunks, callbacks, or events return to the central lifecycle owner;\n   authorized readers inspect durable state independently of the original\n   connection.\n8. Separately, signed admission changes catalog state, an external orchestrator\n   starts exact admitted replicas, and the lifecycle service manages host\n   registration, heartbeat, drain, and offline transitions.\n\n## Follow one action through the component owners\n\n### Enter through one semantic path\n\nNative HTTP, NATS, SSE, and WebSocket bindings carry AIP data with different\ndelivery behavior. MCP and A2A clients enter through compatibility mappings.\nBoth routes converge on native capabilities, actions, results, and lifecycle\nstate rather than creating parallel business semantics.\n\nTransport authentication establishes a peer or actor only under the configured\nedge policy. Payload sender and tenant fields remain claims until trusted\nresolvers bind them to deployment-owned identity, membership, and credential\nevidence.\n\n### Govern and persist centrally\n\nThe gateway composes validation, replay protection, identity resolution,\nauthorization, and dispatch. The runtime owns the durable action record and\ncoordinates schema checks, capability support, idempotency, approval,\ntransaction state, cancellation, callbacks, events, receipts, retention, and\nrecovery.\n\nThe product-neutral daemon installs fleet discovery and remote execution as one\npair: it cannot publish a remote capability without a handler that can route\nit. Trusted local modules are frozen into startup composition. Long-tail product\nconnectors use the remote fleet boundary and do not add product code to the\ncentral daemon.\n\n### Select local or fleet execution\n\nA local handler runs inside the trusted central process and receives\nruntime-established execution context. This path has fewer distributed\ndependencies but shares the central process, resource, fault, and credential\nboundary.\n\nA fleet action uses verified tenant context to resolve an enabled capability\nbinding and an eligible connector instance and replica. The resulting route\nassignment pins the version, endpoint, peer identity, manifest digest, catalog\nand policy revisions, credential revision, capacity reservation, and fence token\nbefore the provider side effect. Retry, cancellation, and reconciliation reuse\nthat assignment rather than silently selecting another product account or\nhost.\n\n### Execute at the product boundary\n\nEach standalone host serves one logical connector instance and one immutable\nconnector version. It verifies signed central ingress, recipient and route\ncoordinates, lease and health state, credential revision, approval evidence,\nand local capacity before executing its compiled product adapter.\n\nProvider secrets remain inside the connector-host boundary. The connector maps\ntrusted AIP context to provider requests, normalizes results and typed failures,\nand retains provider operation evidence needed for reconciliation. The external\nproduct remains authoritative for its own committed state.\n\n## Keep control paths outside action execution\n\nThree control paths prepare or maintain the fleet without becoming an action\nhandler:\n\n| Control path | Input and decision | Output | Explicit exclusion |\n|---|---|---|---|\n| Connector admission | A signed package, exact artifact and manifest digests, mandatory independently trusted evidence, limits, freshness, and revocation policy | Atomic registry change plus durable journal result | Does not start an image or call a provider |\n| Deployment orchestration | Verified admission package, signed desired intent, exact observed replica snapshot, generation, and rollout bounds | Deterministic signed start, restart, drain, or stop plan for an external executor | Does not receive registry administrator credentials or invent replica identities |\n| Host lifecycle | Signed and replay-fenced registration, heartbeat, drain, and offline requests from an admitted replica | Monotonic health sequence, bounded lease, and routing status | Does not migrate the registry or admit a connector release |\n\nThis separation limits authority. A compromised host cannot self-admit a new\nversion. A lifecycle service cannot change the signed release package. An\norchestrator can run only the pre-provisioned identities and immutable artifact\ndigests present in a verified plan.\n\n## Place state with the component that can interpret it\n\n| State owner | Durable facts | Recovery boundary |\n|---|---|---|\n| Central runtime stores | Actions, sessions, approvals, transactions, queues, events, chunks, callbacks, receipts, replay claims, profile state, and retention metadata | Central workers resume lifecycle work under fenced leases and idempotency state |\n| Connector registry | Types, versions, capability definitions, instances, bindings, policies, replicas, health and leases, assignments, settlements, catalog revision, and admission journal | New routing and host lifecycle resume from indexed durable rows |\n| Connector-host runtime | Host-side action state, provider checkpoints, webhook replay, event outbox, and connector-owned profile state | The same immutable host identity recovers local work before declaring readiness |\n| External product | Product objects, provider operation status, and committed side effects | Reconciliation queries provider truth after an ambiguous response |\n| Release and evidence stores | Exact images or artifacts, signatures, software bill of materials, provenance, scan results, and conformance reports | Admission re-verifies identity, digest, validity, and revocation before publication |\n\nThe implementation offers in-memory, file-backed, and PostgreSQL-backed central\nruntime stores. Production connector-host bootstrap requires PostgreSQL-backed\nruntime state. The protocol object alone does not choose or qualify a storage\nbackend.\n\n## Failure ownership follows state ownership\n\n| Failure | Component that detects or records it first | Safe architectural response |\n|---|---|---|\n| Client disconnect | Transport or profile edge | Read the authorized durable lifecycle instead of inferring failure from the connection |\n| Central process restart | Runtime supervisor and selected store | Recover fenced queued, approval, callback, reconciliation, and retention work from durable state |\n| Registry or lifecycle outage | Remote handler, fleet supervisor, or connector host | Stop new unsafe routing or lease renewal; preserve existing assignments and evidence |\n| Connector-host loss | Lease maintenance and central remote dispatch | Mark the replica unavailable, preserve the pinned action route, and reconcile uncertain provider state |\n| Provider timeout after a mutation | Connector and runtime transaction state | Record outcome unknown and reconcile; do not choose a new replica or repeat blindly |\n| Stale release or deployment control | Admission or orchestration verifier | Reject by signature, digest, revision, generation, snapshot, expiry, or revocation fence |\n\nReadiness, reachability, authorization, and provider outcome are independent.\nA healthy central daemon does not prove that a connector lease or external\nproduct is healthy. A ready host does not authorize a tenant action.\n\n## Trust and data cross specific boundaries\n\n| Boundary | Trusted fact established there | Data kept out |\n|---|---|---|\n| Client edge to gateway | Authenticated actor and transport context | Self-asserted authority from payload fields |\n| Gateway to runtime | Verified tenant, resolved identity, credential handle, and policy context | Raw provider credentials |\n| Runtime to registry | Tenant-scoped capability and route request | Caller-selected instance, replica, endpoint, or secret |\n| Central daemon to connector host | Signed envelope pinned to assigned peer, tenant, instance, replica, version, and manifest | Registry administrator authority |\n| Connector host to provider | Product-authenticated request using host-owned secret material | Secret values in AIP messages, errors, metrics, or central storage |\n| Release authority to admission | Signed package and separately trusted evidence statements | Mutable image tags or self-asserted scan and conformance success |\n\nNo single signature establishes every row. Transport identity, tenant\nmembership, capability authorization, artifact admission, route identity,\nprovider credentials, and outcome evidence have separate owners.\n\n## Design choices and trade-offs\n\n- **A small semantic core supports several implementations.** Keeping async,\n  transport, cryptography, storage, and products outside the core improves\n  reuse, but requires explicit composition at the gateway and deployment edge.\n- **Durable lifecycle replaces connection-based inference.** Recovery and\n  authorized observation survive disconnects, but require stores, leases,\n  retention, and operational supervision.\n- **Profiles preserve client compatibility.** MCP and A2A mappings reduce\n  integration cost, but expose only their defined projection of native AIP.\n- **Standalone hosts isolate product code and secrets.** Independent rollout\n  and failure containment add registry, signed peer, lease, storage, and\n  orchestration responsibilities.\n- **Immutable routing favors safety over opportunistic failover.** Reusing one\n  action assignment preserves account and evidence identity, but an uncertain\n  mutation may require reconciliation instead of immediate rerouting.\n\n## What this architecture does not imply\n\n- AIP 1.0 does not require Rust, `getaip-server`, PostgreSQL, NATS, or one particular\n  process count.\n- A workspace dependency or implemented code path does not prove that a\n  deployment enables, configures, conforms to, or has qualified that path.\n- A compatibility profile is not an alternative native lifecycle.\n- A connector manifest or ready process cannot self-authorize a tenant route.\n- A signed action, admitted artifact, durable record, or receipt does not by\n  itself prove the external product outcome.\n- A control-plane component does not become a provider action executor merely\n  because both use the connector registry.\n\n## Related pages\n\n- [How AIP works](../getting-started/how-aip-works.md)\n- [Connector fleet architecture](connector-fleet.md)\n- [Gateway](gateway.md)\n- [Runtime](runtime.md)\n- [Security model](security-model.md)\n",
    "text": "Architecture overview\n\nUse this page to understand which component owns each decision and state\ntransition in the reviewed AIP implementation. It is for developers, connector\ndevelopers, operators, and security reviewers who need a complete component map\nbefore changing an execution, fleet, storage, or trust boundary.\n\nThe architecture describes version 2.0.0 of the Rust workspace at source\nrevision d7cce13d1d555644d04a4d73c66c95b113737635. AIP 1.0 defines\ninteroperable message and lifecycle meaning; it does not require this Rust\ncrate layout, process topology, database, or orchestration model.\n\nWhy ownership boundaries matter\n\nAn AIP action can cross transport decoding, authentication, policy, durable\nlifecycle state, tenant routing, a connector process, and an external product.\nTreating that path as one undifferentiated service obscures who may establish\nidentity, where a secret may exist, which store survives a restart, and which\ncomponent can safely retry an uncertain operation.\n\nThe reviewed implementation keeps those concerns separate. The semantic core\ndoes not depend on networking or products. Compatibility profiles do not own\nnative action state. The target fleet composition keeps the six maintained\nproduct adapters and their provider credentials outside the primary daemon.\nConnector lifecycle control cannot admit a new artifact, and the registry does\nnot execute an image or call a provider.\n\nThe six-boundary model\n\n| Boundary | Primary responsibility | Authority it does not gain |\n\n| Semantic contract | Native IDs, envelopes, message and domain objects, and pure validation | Network identity, persistence, product behavior, or deployment policy |\n| Ingress and projection | Native transport framing plus bounded MCP, A2A, and webhook mappings | Permission to invoke a capability or redefine native lifecycle meaning |\n| Central execution | Gateway authentication and policy composition plus runtime lifecycle, queues, approvals, transactions, and observation | Raw provider credentials or external product truth |\n| Connector fleet data path | Tenant catalog, immutable route assignment, signed remote dispatch, host execution, and event return | Connector release admission or arbitrary target selection by payload |\n| Fleet release and lifecycle control | Signed admission, registry administration, host leases, and platform-neutral orchestration | Client action execution, provider mutation, or secret resolution |\n| Persistence and evidence | Runtime records, registry rows, host-local durable state, provider records, and retained artifact evidence | A broader claim than the identity, topology, and procedure of each record |\n\nThese are ownership boundaries, not mandatory process counts. A small trusted\ndeployment can use a local module and file-backed state. A clustered connector\nfleet uses separate central, registry, lifecycle, host, and provider boundaries.\n\nComponent map\n\nThe solid arrows below show action and result flow. Dashed arrows show release,\ndeployment, or host-lifecycle control that is intentionally outside the action\npath.\n\nmermaid\nflowchart LR\n    N[\"Native AIP client\"] --> T[\"Native transport edge\"]\n    F[\"MCP or A2A client\"] --> P[\"Compatibility profile\"]\n    T --> G[\"Gateway\"]\n    P --> G\n    G --> R[\"Durable runtime\"]\n    R --> L[\"Trusted local module\"]\n    R --> D[\"Tenant catalog and remote handler\"]\n    D --> H[\"Standalone connector host\"]\n    H --> X[\"External product\"]\n    R --> S[\"Runtime stores\"]\n    D --> Q[\"Connector registry\"]\n    H -.->|register, heartbeat, drain| C[\"Lifecycle control plane\"]\n    C -.->|lease and status| Q\n    A[\"Signed connector admission\"] -.->|atomic catalog change| Q\n    O[\"External orchestrator\"] -.->|exact admitted process| H\n\nThe text equivalent is:\n1. A native transport decodes an AIP envelope, or a compatibility profile maps\n   a foreign request into native AIP.\n2. The gateway establishes the authenticated actor, resolves trusted identity\n   and tenant context, validates the message boundary, and applies policy.\n3. The runtime owns action governance and durable lifecycle state.\n4. A trusted local capability executes through a startup-admitted local module.\n   A fleet capability instead uses the tenant catalog and shared remote handler.\n5. The remote handler persists an action-specific route before dispatching a\n   signed native request to the assigned connector host.\n6. The host verifies the pinned route and its lease, resolves provider\n   credentials inside its process, and invokes the external product.\n7. Results, chunks, callbacks, or events return to the central lifecycle owner;\n   authorized readers inspect durable state independently of the original\n   connection.\n8. Separately, signed admission changes catalog state, an external orchestrator\n   starts exact admitted replicas, and the lifecycle service manages host\n   registration, heartbeat, drain, and offline transitions.\n\nFollow one action through the component owners\n\nEnter through one semantic path\n\nNative HTTP, NATS, SSE, and WebSocket bindings carry AIP data with different\ndelivery behavior. MCP and A2A clients enter through compatibility mappings.\nBoth routes converge on native capabilities, actions, results, and lifecycle\nstate rather than creating parallel business semantics.\n\nTransport authentication establishes a peer or actor only under the configured\nedge policy. Payload sender and tenant fields remain claims until trusted\nresolvers bind them to deployment-owned identity, membership, and credential\nevidence.\n\nGovern and persist centrally\n\nThe gateway composes validation, replay protection, identity resolution,\nauthorization, and dispatch. The runtime owns the durable action record and\ncoordinates schema checks, capability support, idempotency, approval,\ntransaction state, cancellation, callbacks, events, receipts, retention, and\nrecovery.\n\nThe product-neutral daemon installs fleet discovery and remote execution as one\npair: it cannot publish a remote capability without a handler that can route\nit. Trusted local modules are frozen into startup composition. Long-tail product\nconnectors use the remote fleet boundary and do not add product code to the\ncentral daemon.\n\nSelect local or fleet execution\n\nA local handler runs inside the trusted central process and receives\nruntime-established execution context. This path has fewer distributed\ndependencies but shares the central process, resource, fault, and credential\nboundary.\n\nA fleet action uses verified tenant context to resolve an enabled capability\nbinding and an eligible connector instance and replica. The resulting route\nassignment pins the version, endpoint, peer identity, manifest digest, catalog\nand policy revisions, credential revision, capacity reservation, and fence token\nbefore the provider side effect. Retry, cancellation, and reconciliation reuse\nthat assignment rather than silently selecting another product account or\nhost.\n\nExecute at the product boundary\n\nEach standalone host serves one logical connector instance and one immutable\nconnector version. It verifies signed central ingress, recipient and route\ncoordinates, lease and health state, credential revision, approval evidence,\nand local capacity before executing its compiled product adapter.\n\nProvider secrets remain inside the connector-host boundary. The connector maps\ntrusted AIP context to provider requests, normalizes results and typed failures,\nand retains provider operation evidence needed for reconciliation. The external\nproduct remains authoritative for its own committed state.\n\nKeep control paths outside action execution\n\nThree control paths prepare or maintain the fleet without becoming an action\nhandler:\n\n| Control path | Input and decision | Output | Explicit exclusion |\n\n| Connector admission | A signed package, exact artifact and manifest digests, mandatory independently trusted evidence, limits, freshness, and revocation policy | Atomic registry change plus durable journal result | Does not start an image or call a provider |\n| Deployment orchestration | Verified admission package, signed desired intent, exact observed replica snapshot, generation, and rollout bounds | Deterministic signed start, restart, drain, or stop plan for an external executor | Does not receive registry administrator credentials or invent replica identities |\n| Host lifecycle | Signed and replay-fenced registration, heartbeat, drain, and offline requests from an admitted replica | Monotonic health sequence, bounded lease, and routing status | Does not migrate the registry or admit a connector release |\n\nThis separation limits authority. A compromised host cannot self-admit a new\nversion. A lifecycle service cannot change the signed release package. An\norchestrator can run only the pre-provisioned identities and immutable artifact\ndigests present in a verified plan.\n\nPlace state with the component that can interpret it\n\n| State owner | Durable facts | Recovery boundary |\n\n| Central runtime stores | Actions, sessions, approvals, transactions, queues, events, chunks, callbacks, receipts, replay claims, profile state, and retention metadata | Central workers resume lifecycle work under fenced leases and idempotency state |\n| Connector registry | Types, versions, capability definitions, instances, bindings, policies, replicas, health and leases, assignments, settlements, catalog revision, and admission journal | New routing and host lifecycle resume from indexed durable rows |\n| Connector-host runtime | Host-side action state, provider checkpoints, webhook replay, event outbox, and connector-owned profile state | The same immutable host identity recovers local work before declaring readiness |\n| External product | Product objects, provider operation status, and committed side effects | Reconciliation queries provider truth after an ambiguous response |\n| Release and evidence stores | Exact images or artifacts, signatures, software bill of materials, provenance, scan results, and conformance reports | Admission re-verifies identity, digest, validity, and revocation before publication |\n\nThe implementation offers in-memory, file-backed, and PostgreSQL-backed central\nruntime stores. Production connector-host bootstrap requires PostgreSQL-backed\nruntime state. The protocol object alone does not choose or qualify a storage\nbackend.\n\nFailure ownership follows state ownership\n\n| Failure | Component that detects or records it first | Safe architectural response |\n\n| Client disconnect | Transport or profile edge | Read the authorized durable lifecycle instead of inferring failure from the connection |\n| Central process restart | Runtime supervisor and selected store | Recover fenced queued, approval, callback, reconciliation, and retention work from durable state |\n| Registry or lifecycle outage | Remote handler, fleet supervisor, or connector host | Stop new unsafe routing or lease renewal; preserve existing assignments and evidence |\n| Connector-host loss | Lease maintenance and central remote dispatch | Mark the replica unavailable, preserve the pinned action route, and reconcile uncertain provider state |\n| Provider timeout after a mutation | Connector and runtime transaction state | Record outcome unknown and reconcile; do not choose a new replica or repeat blindly |\n| Stale release or deployment control | Admission or orchestration verifier | Reject by signature, digest, revision, generation, snapshot, expiry, or revocation fence |\n\nReadiness, reachability, authorization, and provider outcome are independent.\nA healthy central daemon does not prove that a connector lease or external\nproduct is healthy. A ready host does not authorize a tenant action.\n\nTrust and data cross specific boundaries\n\n| Boundary | Trusted fact established there | Data kept out |\n\n| Client edge to gateway | Authenticated actor and transport context | Self-asserted authority from payload fields |\n| Gateway to runtime | Verified tenant, resolved identity, credential handle, and policy context | Raw provider credentials |\n| Runtime to registry | Tenant-scoped capability and route request | Caller-selected instance, replica, endpoint, or secret |\n| Central daemon to connector host | Signed envelope pinned to assigned peer, tenant, instance, replica, version, and manifest | Registry administrator authority |\n| Connector host to provider | Product-authenticated request using host-owned secret material | Secret values in AIP messages, errors, metrics, or central storage |\n| Release authority to admission | Signed package and separately trusted evidence statements | Mutable image tags or self-asserted scan and conformance success |\n\nNo single signature establishes every row. Transport identity, tenant\nmembership, capability authorization, artifact admission, route identity,\nprovider credentials, and outcome evidence have separate owners.\n\nDesign choices and trade-offs\n• A small semantic core supports several implementations. Keeping async,\n  transport, cryptography, storage, and products outside the core improves\n  reuse, but requires explicit composition at the gateway and deployment edge.\n• Durable lifecycle replaces connection-based inference. Recovery and\n  authorized observation survive disconnects, but require stores, leases,\n  retention, and operational supervision.\n• Profiles preserve client compatibility. MCP and A2A mappings reduce\n  integration cost, but expose only their defined projection of native AIP.\n• Standalone hosts isolate product code and secrets. Independent rollout\n  and failure containment add registry, signed peer, lease, storage, and\n  orchestration responsibilities.\n• Immutable routing favors safety over opportunistic failover. Reusing one\n  action assignment preserves account and evidence identity, but an uncertain\n  mutation may require reconciliation instead of immediate rerouting.\n\nWhat this architecture does not imply\n• AIP 1.0 does not require Rust, getaip-server, PostgreSQL, NATS, or one particular\n  process count.\n• A workspace dependency or implemented code path does not prove that a\n  deployment enables, configures, conforms to, or has qualified that path.\n• A compatibility profile is not an alternative native lifecycle.\n• A connector manifest or ready process cannot self-authorize a tenant route.\n• A signed action, admitted artifact, durable record, or receipt does not by\n  itself prove the external product outcome.\n• A control-plane component does not become a provider action executor merely\n  because both use the connector registry.\n\nRelated pages\n• How AIP works (../getting-started/how-aip-works.md)\n• Connector fleet architecture (connector-fleet.md)\n• Gateway (gateway.md)\n• Runtime (runtime.md)\n• Security model (security-model.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "6568a3836a76da06417430029fe036a0f25303d58f27d76da3f532894e1a4b98"
  }
}