{
  "schemaVersion": "1.0",
  "title": "Architecture documentation",
  "description": "Use this index to choose the architecture page that answers a component, execution, connector-fleet, trust, or dependency question. It is for developers, connector developers, operators, security reviewers, and protocol implementers who nee",
  "canonical": "https://getaip.org/docs/architecture",
  "route": "/docs/architecture",
  "source": "docs/architecture/README.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Architecture and Security",
  "documentType": "Documentation",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "97be86e9efedf07ecf1783b03800f683f107fb04",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/architecture.md",
    "txt": "/docs/download/architecture.txt",
    "json": "/docs/download/architecture.json",
    "pdf": "/docs/download/architecture.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Architecture documentation\ndescription: Choose the architecture view for AIP components, execution, fleet, trust, or dependencies\nkind: index\naudience: developer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# Architecture documentation\n\nUse this index to choose the architecture page that answers a component,\nexecution, connector-fleet, trust, or dependency question. It is for\ndevelopers, connector developers, operators, security reviewers, and protocol\nimplementers who need the implementation model before changing or deploying\nAIP.\n\nThese pages describe version `1.0.0` of the Rust workspace at source revision\n`97be86e9efedf07ecf1783b03800f683f107fb04`. They explain how that\nimplementation realizes AIP 1.0; they do not add requirements to the normative\nwire protocol or prove that a particular deployment is qualified.\n\n## Choose an architecture view\n\nThe pages follow this order in documentation navigation:\n\n| Order | Page | Use it to answer |\n|---:|---|---|\n| 1 | [Architecture overview](overview.md) | Which layers participate in a request, and where do protocol, profile, runtime, storage, and connector responsibilities separate? |\n| 2 | [Connector fleet architecture](connector-fleet.md) | How do product-neutral daemon processes, lifecycle control, standalone hosts, and external orchestration form one fleet? |\n| 3 | [Connector registry and routing](connector-registry-and-routing.md) | How do type, version, instance, replica, binding, lease, and immutable route assignment select an execution target? |\n| 4 | [Connector admission and supply-chain trust](connector-admission.md) | Which signed package, evidence, identity, digest, revocation, and journal checks permit a connector release to enter the registry? |\n| 5 | [Gateway](gateway.md) | How does ingress become authenticated, policy-governed work dispatched to a local or remote handler? |\n| 6 | [Runtime](runtime.md) | Which component owns durable actions, sessions, approvals, transactions, events, retries, reconciliation, and recovery? |\n| 7 | [Dependency graph](dependency-graph.md) | Which crate layer may depend on which other layer, and where are product and infrastructure dependencies kept out? |\n| 8 | [Security model](security-model.md) | Where are trust established, secrets resolved, signatures and replay checked, tenants isolated, and unsafe outcomes contained? |\n\nRead one page for a bounded question. Follow the complete order when reviewing\nan architectural change that crosses multiple ownership or trust boundaries.\n\n## Responsibility map\n\n| Boundary | Owns | Does not decide |\n|---|---|---|\n| Semantic core | Native IDs, envelopes, message and domain types, and pure validation | Transport, async execution, product APIs, persistence, or deployment trust |\n| Transports and compatibility profiles | Delivery mechanics and bounded mappings for native AIP, MCP, A2A, and webhooks | Native lifecycle meaning, product behavior, or global authorization policy |\n| Gateway | Ingress validation, configured authentication, trusted identity and policy resolution, and dispatch | Durable lifecycle storage or provider-specific API semantics |\n| Runtime and storage | Lifecycle state, queues, leases, approvals, transactions, events, callbacks, reconciliation, and retention | Connector selection policy or external product truth |\n| Fleet control | Connector catalog, admission, bindings, routing, replica lifecycle, and platform-neutral orchestration plans | Secret material, image execution, or provider mutations |\n| Connector host | One admitted product boundary, provider credentials, connector execution, readiness, and event delivery | Central catalog administration or tenant-wide policy definition |\n\nThe primary daemon is product-neutral at the reviewed revision. Product\nadapters execute in separately built connector hosts; the legacy bundled daemon\nis a migration boundary rather than the target composition.\n\n## Recommended reading paths\n\n| Reader or task | Read in this order | Result |\n|---|---|---|\n| First implementation review | Architecture overview → Gateway → Runtime → Security model | Follow one request from ingress through durable state and its trust checks |\n| Connector-fleet design | Connector fleet architecture → Registry and routing → Connector admission → Security model | Separate release trust, tenant policy, routing, host lifecycle, and orchestration |\n| Connector implementation | Architecture overview → Connector fleet architecture → Gateway → Runtime | Place product behavior at the host boundary without changing native semantics |\n| Operations and incident review | Connector fleet architecture → Runtime → Security model | Identify the owner of readiness, leases, durable recovery, and containment |\n| Crate or feature change | Dependency graph → Architecture overview → the affected owner page | Preserve dependency direction and avoid moving product or infrastructure concerns into the semantic core |\n| Protocol implementation | Architecture overview → Gateway → Runtime, then the normative specification | Distinguish required wire meaning from choices made by this Rust implementation |\n\n## Use architecture claims safely\n\nArchitecture pages own component responsibilities, flows, trust boundaries, and\ndesign trade-offs. They do not own exact HTTP routes, command flags,\nenvironment variables, metric names, error inventories, schemas, connector\ncapability catalogs, or qualification results. Use the corresponding reference\nor connector page for those details.\n\nA diagram or flow describes only the revision and topology named on its page.\nA deployment can choose different storage, identity, policy, transport, or\norchestration providers while preserving the same AIP contract. Verify current\nsupport and evidence before treating an optional implementation path as\navailable or production-ready.\n\nUse documentation search for an exact crate, type, route, or trust term. Start\nwith the glossary when two similar fleet or lifecycle terms appear to overlap.\n\n## Related pages\n\n- [AIP 1.0 specification](../spec/AIP-1.0.md)\n- [How AIP works](../getting-started/how-aip-works.md)\n- [Production deployment](../guides/production-deployment.md)\n- [Implementation status](../reference/implementation-status.md)\n- [Glossary](../reference/glossary.md)\n",
    "text": "Architecture documentation\n\nUse this index to choose the architecture page that answers a component,\nexecution, connector-fleet, trust, or dependency question. It is for\ndevelopers, connector developers, operators, security reviewers, and protocol\nimplementers who need the implementation model before changing or deploying\nAIP.\n\nThese pages describe version 1.0.0 of the Rust workspace at source revision\n97be86e9efedf07ecf1783b03800f683f107fb04. They explain how that\nimplementation realizes AIP 1.0; they do not add requirements to the normative\nwire protocol or prove that a particular deployment is qualified.\n\nChoose an architecture view\n\nThe pages follow this order in documentation navigation:\n\n| Order | Page | Use it to answer |\n\n| 1 | Architecture overview (overview.md) | Which layers participate in a request, and where do protocol, profile, runtime, storage, and connector responsibilities separate? |\n| 2 | Connector fleet architecture (connector-fleet.md) | How do product-neutral daemon processes, lifecycle control, standalone hosts, and external orchestration form one fleet? |\n| 3 | Connector registry and routing (connector-registry-and-routing.md) | How do type, version, instance, replica, binding, lease, and immutable route assignment select an execution target? |\n| 4 | Connector admission and supply-chain trust (connector-admission.md) | Which signed package, evidence, identity, digest, revocation, and journal checks permit a connector release to enter the registry? |\n| 5 | Gateway (gateway.md) | How does ingress become authenticated, policy-governed work dispatched to a local or remote handler? |\n| 6 | Runtime (runtime.md) | Which component owns durable actions, sessions, approvals, transactions, events, retries, reconciliation, and recovery? |\n| 7 | Dependency graph (dependency-graph.md) | Which crate layer may depend on which other layer, and where are product and infrastructure dependencies kept out? |\n| 8 | Security model (security-model.md) | Where are trust established, secrets resolved, signatures and replay checked, tenants isolated, and unsafe outcomes contained? |\n\nRead one page for a bounded question. Follow the complete order when reviewing\nan architectural change that crosses multiple ownership or trust boundaries.\n\nResponsibility map\n\n| Boundary | Owns | Does not decide |\n\n| Semantic core | Native IDs, envelopes, message and domain types, and pure validation | Transport, async execution, product APIs, persistence, or deployment trust |\n| Transports and compatibility profiles | Delivery mechanics and bounded mappings for native AIP, MCP, A2A, and webhooks | Native lifecycle meaning, product behavior, or global authorization policy |\n| Gateway | Ingress validation, configured authentication, trusted identity and policy resolution, and dispatch | Durable lifecycle storage or provider-specific API semantics |\n| Runtime and storage | Lifecycle state, queues, leases, approvals, transactions, events, callbacks, reconciliation, and retention | Connector selection policy or external product truth |\n| Fleet control | Connector catalog, admission, bindings, routing, replica lifecycle, and platform-neutral orchestration plans | Secret material, image execution, or provider mutations |\n| Connector host | One admitted product boundary, provider credentials, connector execution, readiness, and event delivery | Central catalog administration or tenant-wide policy definition |\n\nThe primary daemon is product-neutral at the reviewed revision. Product\nadapters execute in separately built connector hosts; the legacy bundled daemon\nis a migration boundary rather than the target composition.\n\nRecommended reading paths\n\n| Reader or task | Read in this order | Result |\n\n| First implementation review | Architecture overview → Gateway → Runtime → Security model | Follow one request from ingress through durable state and its trust checks |\n| Connector-fleet design | Connector fleet architecture → Registry and routing → Connector admission → Security model | Separate release trust, tenant policy, routing, host lifecycle, and orchestration |\n| Connector implementation | Architecture overview → Connector fleet architecture → Gateway → Runtime | Place product behavior at the host boundary without changing native semantics |\n| Operations and incident review | Connector fleet architecture → Runtime → Security model | Identify the owner of readiness, leases, durable recovery, and containment |\n| Crate or feature change | Dependency graph → Architecture overview → the affected owner page | Preserve dependency direction and avoid moving product or infrastructure concerns into the semantic core |\n| Protocol implementation | Architecture overview → Gateway → Runtime, then the normative specification | Distinguish required wire meaning from choices made by this Rust implementation |\n\nUse architecture claims safely\n\nArchitecture pages own component responsibilities, flows, trust boundaries, and\ndesign trade-offs. They do not own exact HTTP routes, command flags,\nenvironment variables, metric names, error inventories, schemas, connector\ncapability catalogs, or qualification results. Use the corresponding reference\nor connector page for those details.\n\nA diagram or flow describes only the revision and topology named on its page.\nA deployment can choose different storage, identity, policy, transport, or\norchestration providers while preserving the same AIP contract. Verify current\nsupport and evidence before treating an optional implementation path as\navailable or production-ready.\n\nUse documentation search for an exact crate, type, route, or trust term. Start\nwith the glossary when two similar fleet or lifecycle terms appear to overlap.\n\nRelated pages\n• AIP 1.0 specification (../spec/AIP-1.0.md)\n• How AIP works (../getting-started/how-aip-works.md)\n• Production deployment (../guides/production-deployment.md)\n• Implementation status (../reference/implementation-status.md)\n• Glossary (../reference/glossary.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "6458ca991713bbae2b316be9446dc69fabce43b587a3681b45ebd815edccfcd4"
  }
}