{
  "schemaVersion": "1.0",
  "title": "Connector fleet architecture",
  "description": "Use this page to understand how the reviewed AIP implementation can add, isolate, and scale connector processes without adding product code or provider secrets to the central aipd binary. It is primarily for developers designing the fleet b",
  "canonical": "https://getaip.org/docs/architecture/connector-fleet",
  "route": "/docs/architecture/connector-fleet",
  "source": "docs/architecture/connector-fleet.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Architecture and Security",
  "documentType": "Architecture",
  "language": "en",
  "downloads": {
    "md": "/docs/download/architecture/connector-fleet.md",
    "txt": "/docs/download/architecture/connector-fleet.txt",
    "json": "/docs/download/architecture/connector-fleet.json",
    "pdf": "/docs/download/architecture/connector-fleet.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Connector fleet architecture\ndescription: Understand how AIP separates central routing, connector hosts, lifecycle control, admission, and orchestration\nkind: explanation\naudience: developer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# Connector fleet architecture\n\nUse this page to understand how the reviewed AIP implementation can add,\nisolate, and scale connector processes without adding product code or provider\nsecrets to the central `aipd` binary. It is primarily for developers designing\nthe fleet boundary; operators and security reviewers can use the same model to\nlocate lifecycle, release, routing, and secret authority.\n\nThis architecture describes version `1.0.0` of the Rust workspace at source\nrevision `97be86e9efedf07ecf1783b03800f683f107fb04`. It is an implementation\ntopology, not a process topology required by the AIP 1.0 protocol.\n\n## Why the fleet is a separate boundary\n\nA bundled connector shares the central daemon's release, resource, fault, and\ncredential boundary. That can be useful for a small trusted local module, but\nit becomes difficult to manage when connector versions, product accounts,\nrollout schedules, and failure domains grow independently.\n\nThe fleet moves product adapters into standalone connector hosts. The primary\n`aipd` package depends on product-neutral connector contracts, registry access,\nand remote dispatch, but not on the six maintained product adapters. Adding or\nscaling an already admitted connector therefore changes catalog, process, and\nlease state rather than the `aipd` executable.\n\nThis separation provides three practical properties:\n\n- a product adapter and its secrets stay inside its connector-host process;\n- a connector release can be admitted, started, drained, or replaced without\n  changing the central binary;\n- central routing can apply tenant, capability, version, health, topology, and\n  capacity constraints before a provider request leaves the platform.\n\nIt does not remove distributed-systems work. The fleet introduces durable\nrouting, signed peer identity, leases, host-local recovery, release admission,\nand external process orchestration as explicit responsibilities.\n\n## Six planes with different authority\n\nThe implementation separates the connector fleet into six cooperating planes.\nThe solid arrows in the diagram carry discovery, action, result, or event data.\nDashed arrows carry release, deployment, or lifecycle control.\n\n~~~mermaid\nflowchart LR\n    C[\"AIP client\"] --> D[\"Product-neutral aipd\"]\n    D -->|catalog and route| R[\"Connector registry data plane\"]\n    D -->|signed action| H[\"Standalone connector host\"]\n    H -->|provider request| P[\"External product\"]\n    H -->|result, callback, or event| D\n    A[\"Admission authority\"] -.->|publish admitted state| R\n    O[\"External orchestrator\"] -.->|start exact replica| H\n    H -.->|register and renew lease| L[\"Lifecycle control plane\"]\n    L -.->|update lifecycle state| R\n~~~\n\nThe text equivalent is:\n\n1. The central daemon discovers tenant-visible capabilities through the\n   registry data plane.\n2. For a fleet action, the daemon resolves and persists one route, then sends a\n   signed native AIP request to the selected standalone host.\n3. The host verifies the route and central peer, uses its process-owned provider\n   credentials, and calls the external product.\n4. The result returns on the action path. Stream callbacks and normalized\n   provider events return through authenticated central ingress.\n5. Separately, admission publishes trusted catalog state, an external\n   orchestrator starts only declared replicas, and the lifecycle service\n   registers, renews, drains, or offlines those replicas.\n\n| Plane | Owns | Deliberately does not own |\n|---|---|---|\n| Central data plane | Tenant-scoped discovery, action governance, fair local admission, route resolution, signed dispatch, callbacks, and event ingress | Product implementation code, provider secrets, catalog administration, or process creation |\n| Connector-host data plane | One admitted connector instance and version, provider execution, local durable recovery, webhook normalization, and signed responses | Selection of another tenant, instance, version, or replica |\n| Registry data plane | Indexed catalog reads, leases, durable action assignments, capacity state, and settlement | Provider credentials, connector execution, or artifact startup |\n| Lifecycle control plane | Signed registration, heartbeat, drain, and offline transitions through a restricted registry role | Catalog migration, release admission, client execution, or provider mutation |\n| Release admission | Verification and atomic publication of one immutable release package and its independently trusted evidence | Process startup, host lifecycle, client execution, or provider mutation |\n| External orchestration | Reconciliation of exact admitted process identities and artifact digests on a deployment platform | Registry administrator credentials or invention of connector identities |\n\nThe central daemon installs its capability catalog and catch-all remote handler\nas one pair. It cannot advertise a remote capability without installing the\nexecution path that can resolve and dispatch it.\n\n## Keep the fleet identity chain explicit\n\nThe word *connector* is too broad to identify a safe route. The fleet uses a\nchain of identities, each answering a different question.\n\n| Identity | Question it answers | Stability |\n|---|---|---|\n| Connector type | Which adapter family implements this product boundary? | Stable across its releases |\n| Connector version | Which admitted artifact and manifest implement it? | Artifact and manifest identity remain immutable; lifecycle status can change |\n| Connector instance | Which tenant-owned product account or installation is configured? | Logical deployment identity |\n| Connector replica | Which pre-provisioned process identity may serve the instance? | Concrete lifecycle and lease identity |\n| Connector host | Which running process enforces that replica's signed, storage, and secret boundary? | One instance and one version per process |\n| Route assignment | Which exact replica is pinned to this action under the accepted catalog and policy state? | Durable for the action |\n\nA capability binding connects a verified tenant and capability to an eligible\ninstance. A route assignment then connects one action to one replica. Payload\ndata and transport code do not choose the tenant, product account, endpoint, or\nreplica.\n\nKeeping these identities separate allows several versions of one connector\ntype, several tenant-owned instances of a version, and several replicas of an\ninstance to coexist without treating them as interchangeable.\n\n## Follow one fleet action\n\n### Discover only callable tenant bindings\n\nThe tenant-scoped catalog exposes capabilities that have an enabled binding and\nan implementation admitted for the selected profile. Discovery does not prove\nthat a provider is reachable or authorize a later action by itself. The action\nstill enters normal gateway and runtime governance.\n\n### Admit work before selecting a host\n\nThe shared remote scheduler applies bounded global and per-tenant concurrency,\nqueue, request-size, and queue-age limits. Tenant weights affect local fairness;\nthey do not grant capability or routing authority.\n\nAfter local admission, the remote handler asks the registry to resolve the\naction from runtime-established tenant and capability context. The registry\neither returns the action's existing assignment or creates one from eligible\ncatalog, policy, lease, topology, and capacity state.\n\n### Persist, then dispatch\n\nThe route exists durably before the connector can perform a provider side\neffect. The assignment pins the peer, tenant, instance, replica, immutable\nversion, manifest, policy revisions, credential revision, capacity reservation,\nand fence state. The dispatcher signs the native AIP request for that assigned\npeer and carries the route coordinates needed for host verification.\n\nThe host rejects a request when the signed sender or pinned coordinates do not\nmatch its own identity. It also rejects the request when its lease or readiness\nis invalid, when it is draining, or when local capacity, credential revision,\nor approval evidence is not acceptable. Only then does the product adapter\nreceive trusted execution context and access its provider credential.\n\n### Preserve the route after uncertainty\n\nSuccessful, cancelled, and uncertain outcomes settle against the same\nassignment. A retry or cancellation reuses the action's durable route rather\nthan selecting another account or replica. If a provider may have committed a\nmutation before a response was lost, reconciliation determines provider truth;\nthe architecture does not promise exactly-once external effects.\n\n## Return results, callbacks, and provider events safely\n\nThe normal action result returns from the assigned host to the central runtime.\nA streaming host can send signed chunks through a callback route derived from\nthe same durable assignment. Central ingress checks the callback against the\nassignment and current replica identity before accepting it.\n\nProvider-originated events take a different route. The host verifies the\nprovider webhook, normalizes the event, stores it in a bounded durable outbox,\nand publishes it to shared authenticated event ingress. Central AIP owns the\nprotocol-level actor after authenticating the host; provider actor information\nis retained as data rather than trusted as an AIP sender claim.\n\nAn active host lease is required for event publication. A transient central\nfailure can leave an accepted event batch queued for retry, and central event\nstorage deduplicates repeated event identifiers. This path is not a substitute\nfor action-route authorization.\n\n## Change scale without changing identity meaning\n\nFleet growth happens at different layers. Each change has a different safety\nboundary.\n\n| Change | State that changes | State that remains fixed |\n|---|---|---|\n| Add a connector type | Admitted type, version, manifest, implementation claims, and release evidence | Central product-neutral executable and native AIP semantics |\n| Add a tenant account | Instance, capability bindings, policy, and credential revision references | Connector artifact and provider secrets outside the registry |\n| Add capacity | Pre-provisioned replica identity, placement, endpoint, lease, and capacity | Instance ownership and immutable version |\n| Roll out a version | New admitted version, target replicas, binding or rollout state, and deployment generation | Existing action assignments and retained release evidence |\n| Drain capacity | Replica lifecycle state and eventual process observation | Pinned work and its original assignment |\n\nThe external orchestration contract derives a deterministic, signed sequence of\nstart, restart, drain, and stop operations from a verified admission package,\noperator intent, and an exact platform observation. It is platform-neutral: the\nexecutor maps those operations to its deployment system and checks fresh state\nbefore applying them.\n\nA host serves exactly one logical instance and one immutable version. Scaling\ntherefore creates additional declared replica processes; it does not turn one\nhost into a multi-tenant product router.\n\n## Keep lifecycle authority narrow\n\nConnector hosts register, heartbeat, drain, and go offline through a standalone\nsigned lifecycle service. That service uses a restricted registry role and must\nnot retain catalog-administration credentials. Schema migration and release\nadmission remain operator-controlled actions outside the long-running service.\n\nThe lease establishes current routing eligibility, not release trust. Admission\nestablishes release trust, not current host health. Orchestration establishes\nwhich exact process should run, not whether a client action is authorized.\n\nThis separation prevents one authority from silently acquiring another:\n\n- a running host cannot admit a replacement artifact;\n- the lifecycle service cannot create a tenant binding or change a release;\n- the central daemon cannot start arbitrary images;\n- an orchestrator cannot mint unregistered replica identities;\n- a client cannot choose a product account through request metadata.\n\n## Isolate state and secrets by failure domain\n\n| Boundary | Durable or sensitive state | Effect of failure |\n|---|---|---|\n| Central runtime | Action lifecycle, approvals, transactions, callbacks, events, replay, and recovery records | Authorized lifecycle observation and recovery may pause, but connector identity does not change |\n| Connector registry | Catalog state, bindings, replicas, leases, assignments, capacity, settlement, and admission journal | New discovery or routing may stop; existing assignments remain the identity for recovery |\n| Connector host | Provider credential access, local action checkpoints, webhook replay, event outbox, and provider evidence | One instance and version lose execution capacity; other hosts need not share its secret or fault |\n| External product | Product objects and committed side effects | Provider truth may require reconciliation after an ambiguous response |\n| Release and deployment systems | Signed packages, evidence, desired generations, platform observations, and execution journal | New rollout work stops without granting action-path authority |\n\nThe registry stores opaque credential and secret-provider references, not\nprovider credential values. The host deployment resolves the referenced secret\ninside the host boundary. Rotation can advance accepted revisions and drain old\nwork without exposing the secret to the central daemon.\n\n## Contain failures instead of silently rerouting them\n\n| Failure | Containment behavior |\n|---|---|\n| No eligible instance or replica | Reject new routing; do not infer a target from client data |\n| Scheduler or capacity limit reached | Queue within configured bounds or fail explicitly; do not bypass tenant fairness |\n| Registry unavailable | Stop unsafe new selection and preserve already durable assignments for recovery |\n| Lease expires or host drains | Remove the replica from new assignments while allowing policy-governed pinned work to finish |\n| Host disappears after a provider call | Preserve the route and reconcile the uncertain outcome instead of selecting a new provider account |\n| Lifecycle service unavailable | Stop lifecycle renewal or change; do not convert the central daemon into a lifecycle administrator |\n| Admission or orchestration evidence is stale | Reject the release or plan and require a fresh verified decision |\n\nReadiness is local to a component. A ready `aipd` does not prove registry,\nconnector-host, or provider readiness. A ready host does not prove tenant\nauthorization, and a healthy provider connection does not establish artifact\nadmission.\n\n## Trade-offs and non-implications\n\n- **Isolation adds coordination.** Separate hosts reduce product-code and\n  credential blast radius but require signed identities, durable routing,\n  leases, host storage, and process supervision.\n- **Pinned routing favors evidence integrity.** It prevents silent account or\n  replica changes but can require reconciliation rather than immediate\n  failover after an uncertain mutation.\n- **Normalized state supports bounded lookup.** Indexed records allow the\n  registry to resolve a large fleet without materializing one fleet document,\n  but catalog publication and schema ownership become explicit operations.\n- **Platform-neutral orchestration limits authority.** The contract can be\n  implemented by different schedulers, but each executor must provide its own\n  platform observation, journal, and secret injection.\n\nThis implementation does not imply that every AIP deployment needs a connector\nfleet, PostgreSQL, separate processes, or an external orchestrator. Source code\nfor a fleet path does not prove that a deployment enabled or qualified it. The\narchitecture also makes no portable throughput, availability, provider-health,\nor exactly-once guarantee.\n\n## Related pages\n\n- [Connector registry and routing](connector-registry-and-routing.md)\n- [Connector admission and supply-chain trust](connector-admission.md)\n- [Deploy the connector fleet](../guides/deploy-connector-fleet.md)\n- [Operate the connector host lifecycle](../guides/connector-host-lifecycle.md)\n- [Orchestrate and roll back connector hosts](../guides/connector-orchestration.md)\n",
    "text": "Connector fleet architecture\n\nUse this page to understand how the reviewed AIP implementation can add,\nisolate, and scale connector processes without adding product code or provider\nsecrets to the central aipd binary. It is primarily for developers designing\nthe fleet boundary; operators and security reviewers can use the same model to\nlocate lifecycle, release, routing, and secret authority.\n\nThis architecture describes version 1.0.0 of the Rust workspace at source\nrevision 97be86e9efedf07ecf1783b03800f683f107fb04. It is an implementation\ntopology, not a process topology required by the AIP 1.0 protocol.\n\nWhy the fleet is a separate boundary\n\nA bundled connector shares the central daemon's release, resource, fault, and\ncredential boundary. That can be useful for a small trusted local module, but\nit becomes difficult to manage when connector versions, product accounts,\nrollout schedules, and failure domains grow independently.\n\nThe fleet moves product adapters into standalone connector hosts. The primary\naipd package depends on product-neutral connector contracts, registry access,\nand remote dispatch, but not on the six maintained product adapters. Adding or\nscaling an already admitted connector therefore changes catalog, process, and\nlease state rather than the aipd executable.\n\nThis separation provides three practical properties:\n• a product adapter and its secrets stay inside its connector-host process;\n• a connector release can be admitted, started, drained, or replaced without\n  changing the central binary;\n• central routing can apply tenant, capability, version, health, topology, and\n  capacity constraints before a provider request leaves the platform.\n\nIt does not remove distributed-systems work. The fleet introduces durable\nrouting, signed peer identity, leases, host-local recovery, release admission,\nand external process orchestration as explicit responsibilities.\n\nSix planes with different authority\n\nThe implementation separates the connector fleet into six cooperating planes.\nThe solid arrows in the diagram carry discovery, action, result, or event data.\nDashed arrows carry release, deployment, or lifecycle control.\n\nmermaid\nflowchart LR\n    C[\"AIP client\"] --> D[\"Product-neutral aipd\"]\n    D -->|catalog and route| R[\"Connector registry data plane\"]\n    D -->|signed action| H[\"Standalone connector host\"]\n    H -->|provider request| P[\"External product\"]\n    H -->|result, callback, or event| D\n    A[\"Admission authority\"] -.->|publish admitted state| R\n    O[\"External orchestrator\"] -.->|start exact replica| H\n    H -.->|register and renew lease| L[\"Lifecycle control plane\"]\n    L -.->|update lifecycle state| R\n\nThe text equivalent is:\n1. The central daemon discovers tenant-visible capabilities through the\n   registry data plane.\n2. For a fleet action, the daemon resolves and persists one route, then sends a\n   signed native AIP request to the selected standalone host.\n3. The host verifies the route and central peer, uses its process-owned provider\n   credentials, and calls the external product.\n4. The result returns on the action path. Stream callbacks and normalized\n   provider events return through authenticated central ingress.\n5. Separately, admission publishes trusted catalog state, an external\n   orchestrator starts only declared replicas, and the lifecycle service\n   registers, renews, drains, or offlines those replicas.\n\n| Plane | Owns | Deliberately does not own |\n\n| Central data plane | Tenant-scoped discovery, action governance, fair local admission, route resolution, signed dispatch, callbacks, and event ingress | Product implementation code, provider secrets, catalog administration, or process creation |\n| Connector-host data plane | One admitted connector instance and version, provider execution, local durable recovery, webhook normalization, and signed responses | Selection of another tenant, instance, version, or replica |\n| Registry data plane | Indexed catalog reads, leases, durable action assignments, capacity state, and settlement | Provider credentials, connector execution, or artifact startup |\n| Lifecycle control plane | Signed registration, heartbeat, drain, and offline transitions through a restricted registry role | Catalog migration, release admission, client execution, or provider mutation |\n| Release admission | Verification and atomic publication of one immutable release package and its independently trusted evidence | Process startup, host lifecycle, client execution, or provider mutation |\n| External orchestration | Reconciliation of exact admitted process identities and artifact digests on a deployment platform | Registry administrator credentials or invention of connector identities |\n\nThe central daemon installs its capability catalog and catch-all remote handler\nas one pair. It cannot advertise a remote capability without installing the\nexecution path that can resolve and dispatch it.\n\nKeep the fleet identity chain explicit\n\nThe word connector is too broad to identify a safe route. The fleet uses a\nchain of identities, each answering a different question.\n\n| Identity | Question it answers | Stability |\n\n| Connector type | Which adapter family implements this product boundary? | Stable across its releases |\n| Connector version | Which admitted artifact and manifest implement it? | Artifact and manifest identity remain immutable; lifecycle status can change |\n| Connector instance | Which tenant-owned product account or installation is configured? | Logical deployment identity |\n| Connector replica | Which pre-provisioned process identity may serve the instance? | Concrete lifecycle and lease identity |\n| Connector host | Which running process enforces that replica's signed, storage, and secret boundary? | One instance and one version per process |\n| Route assignment | Which exact replica is pinned to this action under the accepted catalog and policy state? | Durable for the action |\n\nA capability binding connects a verified tenant and capability to an eligible\ninstance. A route assignment then connects one action to one replica. Payload\ndata and transport code do not choose the tenant, product account, endpoint, or\nreplica.\n\nKeeping these identities separate allows several versions of one connector\ntype, several tenant-owned instances of a version, and several replicas of an\ninstance to coexist without treating them as interchangeable.\n\nFollow one fleet action\n\nDiscover only callable tenant bindings\n\nThe tenant-scoped catalog exposes capabilities that have an enabled binding and\nan implementation admitted for the selected profile. Discovery does not prove\nthat a provider is reachable or authorize a later action by itself. The action\nstill enters normal gateway and runtime governance.\n\nAdmit work before selecting a host\n\nThe shared remote scheduler applies bounded global and per-tenant concurrency,\nqueue, request-size, and queue-age limits. Tenant weights affect local fairness;\nthey do not grant capability or routing authority.\n\nAfter local admission, the remote handler asks the registry to resolve the\naction from runtime-established tenant and capability context. The registry\neither returns the action's existing assignment or creates one from eligible\ncatalog, policy, lease, topology, and capacity state.\n\nPersist, then dispatch\n\nThe route exists durably before the connector can perform a provider side\neffect. The assignment pins the peer, tenant, instance, replica, immutable\nversion, manifest, policy revisions, credential revision, capacity reservation,\nand fence state. The dispatcher signs the native AIP request for that assigned\npeer and carries the route coordinates needed for host verification.\n\nThe host rejects a request when the signed sender or pinned coordinates do not\nmatch its own identity. It also rejects the request when its lease or readiness\nis invalid, when it is draining, or when local capacity, credential revision,\nor approval evidence is not acceptable. Only then does the product adapter\nreceive trusted execution context and access its provider credential.\n\nPreserve the route after uncertainty\n\nSuccessful, cancelled, and uncertain outcomes settle against the same\nassignment. A retry or cancellation reuses the action's durable route rather\nthan selecting another account or replica. If a provider may have committed a\nmutation before a response was lost, reconciliation determines provider truth;\nthe architecture does not promise exactly-once external effects.\n\nReturn results, callbacks, and provider events safely\n\nThe normal action result returns from the assigned host to the central runtime.\nA streaming host can send signed chunks through a callback route derived from\nthe same durable assignment. Central ingress checks the callback against the\nassignment and current replica identity before accepting it.\n\nProvider-originated events take a different route. The host verifies the\nprovider webhook, normalizes the event, stores it in a bounded durable outbox,\nand publishes it to shared authenticated event ingress. Central AIP owns the\nprotocol-level actor after authenticating the host; provider actor information\nis retained as data rather than trusted as an AIP sender claim.\n\nAn active host lease is required for event publication. A transient central\nfailure can leave an accepted event batch queued for retry, and central event\nstorage deduplicates repeated event identifiers. This path is not a substitute\nfor action-route authorization.\n\nChange scale without changing identity meaning\n\nFleet growth happens at different layers. Each change has a different safety\nboundary.\n\n| Change | State that changes | State that remains fixed |\n\n| Add a connector type | Admitted type, version, manifest, implementation claims, and release evidence | Central product-neutral executable and native AIP semantics |\n| Add a tenant account | Instance, capability bindings, policy, and credential revision references | Connector artifact and provider secrets outside the registry |\n| Add capacity | Pre-provisioned replica identity, placement, endpoint, lease, and capacity | Instance ownership and immutable version |\n| Roll out a version | New admitted version, target replicas, binding or rollout state, and deployment generation | Existing action assignments and retained release evidence |\n| Drain capacity | Replica lifecycle state and eventual process observation | Pinned work and its original assignment |\n\nThe external orchestration contract derives a deterministic, signed sequence of\nstart, restart, drain, and stop operations from a verified admission package,\noperator intent, and an exact platform observation. It is platform-neutral: the\nexecutor maps those operations to its deployment system and checks fresh state\nbefore applying them.\n\nA host serves exactly one logical instance and one immutable version. Scaling\ntherefore creates additional declared replica processes; it does not turn one\nhost into a multi-tenant product router.\n\nKeep lifecycle authority narrow\n\nConnector hosts register, heartbeat, drain, and go offline through a standalone\nsigned lifecycle service. That service uses a restricted registry role and must\nnot retain catalog-administration credentials. Schema migration and release\nadmission remain operator-controlled actions outside the long-running service.\n\nThe lease establishes current routing eligibility, not release trust. Admission\nestablishes release trust, not current host health. Orchestration establishes\nwhich exact process should run, not whether a client action is authorized.\n\nThis separation prevents one authority from silently acquiring another:\n• a running host cannot admit a replacement artifact;\n• the lifecycle service cannot create a tenant binding or change a release;\n• the central daemon cannot start arbitrary images;\n• an orchestrator cannot mint unregistered replica identities;\n• a client cannot choose a product account through request metadata.\n\nIsolate state and secrets by failure domain\n\n| Boundary | Durable or sensitive state | Effect of failure |\n\n| Central runtime | Action lifecycle, approvals, transactions, callbacks, events, replay, and recovery records | Authorized lifecycle observation and recovery may pause, but connector identity does not change |\n| Connector registry | Catalog state, bindings, replicas, leases, assignments, capacity, settlement, and admission journal | New discovery or routing may stop; existing assignments remain the identity for recovery |\n| Connector host | Provider credential access, local action checkpoints, webhook replay, event outbox, and provider evidence | One instance and version lose execution capacity; other hosts need not share its secret or fault |\n| External product | Product objects and committed side effects | Provider truth may require reconciliation after an ambiguous response |\n| Release and deployment systems | Signed packages, evidence, desired generations, platform observations, and execution journal | New rollout work stops without granting action-path authority |\n\nThe registry stores opaque credential and secret-provider references, not\nprovider credential values. The host deployment resolves the referenced secret\ninside the host boundary. Rotation can advance accepted revisions and drain old\nwork without exposing the secret to the central daemon.\n\nContain failures instead of silently rerouting them\n\n| Failure | Containment behavior |\n\n| No eligible instance or replica | Reject new routing; do not infer a target from client data |\n| Scheduler or capacity limit reached | Queue within configured bounds or fail explicitly; do not bypass tenant fairness |\n| Registry unavailable | Stop unsafe new selection and preserve already durable assignments for recovery |\n| Lease expires or host drains | Remove the replica from new assignments while allowing policy-governed pinned work to finish |\n| Host disappears after a provider call | Preserve the route and reconcile the uncertain outcome instead of selecting a new provider account |\n| Lifecycle service unavailable | Stop lifecycle renewal or change; do not convert the central daemon into a lifecycle administrator |\n| Admission or orchestration evidence is stale | Reject the release or plan and require a fresh verified decision |\n\nReadiness is local to a component. A ready aipd does not prove registry,\nconnector-host, or provider readiness. A ready host does not prove tenant\nauthorization, and a healthy provider connection does not establish artifact\nadmission.\n\nTrade-offs and non-implications\n• Isolation adds coordination. Separate hosts reduce product-code and\n  credential blast radius but require signed identities, durable routing,\n  leases, host storage, and process supervision.\n• Pinned routing favors evidence integrity. It prevents silent account or\n  replica changes but can require reconciliation rather than immediate\n  failover after an uncertain mutation.\n• Normalized state supports bounded lookup. Indexed records allow the\n  registry to resolve a large fleet without materializing one fleet document,\n  but catalog publication and schema ownership become explicit operations.\n• Platform-neutral orchestration limits authority. The contract can be\n  implemented by different schedulers, but each executor must provide its own\n  platform observation, journal, and secret injection.\n\nThis implementation does not imply that every AIP deployment needs a connector\nfleet, PostgreSQL, separate processes, or an external orchestrator. Source code\nfor a fleet path does not prove that a deployment enabled or qualified it. The\narchitecture also makes no portable throughput, availability, provider-health,\nor exactly-once guarantee.\n\nRelated pages\n• Connector registry and routing (connector-registry-and-routing.md)\n• Connector admission and supply-chain trust (connector-admission.md)\n• Deploy the connector fleet (../guides/deploy-connector-fleet.md)\n• Operate the connector host lifecycle (../guides/connector-host-lifecycle.md)\n• Orchestrate and roll back connector hosts (../guides/connector-orchestration.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "c3752bb64c43d872f94e38522c906b27a8a54d91df97965fe5b950dc6d369f32"
  }
}