{
  "schemaVersion": "1.0",
  "title": "Connector admission and supply-chain trust",
  "description": "Use this page to understand how the reviewed AIP implementation converts a signed connector release and independently trusted evidence into registry state that can receive traffic. It is primarily for security reviewers; connector developer",
  "canonical": "https://getaip.org/docs/architecture/connector-admission",
  "route": "/docs/architecture/connector-admission",
  "source": "docs/architecture/connector-admission.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Architecture and Security",
  "documentType": "Architecture",
  "language": "en",
  "downloads": {
    "md": "/docs/download/architecture/connector-admission.md",
    "txt": "/docs/download/architecture/connector-admission.txt",
    "json": "/docs/download/architecture/connector-admission.json",
    "pdf": "/docs/download/architecture/connector-admission.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Connector admission and supply-chain trust\ndescription: Understand how signed releases and independently trusted evidence become restartably published connector state\nkind: explanation\naudience: security-reviewer\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# Connector admission and supply-chain trust\n\nUse this page to understand how the reviewed AIP implementation converts a\nsigned connector release and independently trusted evidence into registry state\nthat can receive traffic. It is primarily for security reviewers; connector\ndevelopers and operators can use the same model to distinguish packaging,\nverification, application, deployment, and revocation.\n\nThe architecture describes version `1.0.0` of the Rust workspace at source\nrevision `97be86e9efedf07ecf1783b03800f683f107fb04`. This admission pipeline is an\nimplementation security boundary, not a release process required by AIP 1.0.\n\n## A release signature is necessary but insufficient\n\nA valid package signature establishes that a trusted release authority\nauthorized this exact canonical package value. It does not independently prove\nthe expected source, an acceptable license set, or conformance. It also does not\nprove the absence of disallowed vulnerabilities or a current unrevoked state.\n\nThe admission boundary separates those decisions. A release authority signs the\ncomplete declarative package. Seven evidence roles each sign a statement about\nthe same artifact and manifest. A deployment-owned trust policy decides which\nsigning identities may speak for each role and which outcome is acceptable.\n\nOnly the verifier derives the registry's `ArtifactAttestation`. Package callers\ncannot submit `Passed` registry statuses directly.\n\n## Keep five authorities separate\n\n~~~mermaid\nflowchart LR\n    B[\"Build and policy systems\"] --> E[\"Seven signed evidence documents\"]\n    R[\"Release authority\"] --> P[\"Signed admission package\"]\n    E --> P\n    P --> V[\"Admission verifier\"]\n    T[\"Deployment trust policy\"] --> V\n    V --> A[\"Verified package and derived attestation\"]\n    A -.->|journaled idempotent writes| G[\"Connector registry control plane\"]\n    G --> D[\"Registry data plane\"]\n    A -.->|exact targets only| O[\"External orchestration\"]\n~~~\n\nThe text equivalent is:\n\n1. Build and policy systems produce evidence documents for one exact artifact\n   and manifest.\n2. Each evidence authority signs a canonical statement containing the evidence\n   kind, subject digests, document digest, validity window, and outcome.\n3. The release authority embeds the seven signed documents in one declarative\n   package and signs the complete package.\n4. The admission verifier applies deployment-owned trust roots, bounds,\n   signatures, digests, time windows, subject relationships, and registry\n   invariants.\n5. A short-lived administrator claims the verified package in a durable journal\n   and applies its state through restartable idempotent steps.\n6. Long-running data-plane and orchestration processes consume admitted\n   identities without receiving catalog-administrator authority.\n\n| Authority | May establish | Does not establish |\n|---|---|---|\n| Release authority | Authorization of the exact complete package | Independent scanner, conformance, license, or revocation success |\n| Evidence authority | One role-specific signed observation and outcome | Permission to publish the package or start a process |\n| Admission verifier | Whether all configured trust, subject, freshness, bounds, and compatibility checks pass | Whether an artifact is running or a provider is healthy |\n| Catalog administrator | Durable application or revocation of verified registry state | Client action authorization or provider mutation |\n| Orchestration executor | Whether exact admitted replica processes match signed deployment intent | Artifact admission, tenant binding, or registry administration |\n\n## Bind the complete release subject\n\nThe signed `AdmissionPackage` is a declarative catalog change, not an image or\ndeployment command.\n\n| Package group | Bound content |\n|---|---|\n| Package identity | Schema, stable package ID, monotonic revision, issue time, and expiration time |\n| Connector type | Stable type ID, name, owner, and initial enabled state |\n| Version declaration | Version ID, type ID, release label, requested admitted or active status, complete manifest, manifest digest, artifact digest, implementation support, supported AIP versions, and SDK requirement |\n| Policy and tenancy | Admission policies, tenant-owned instances, capability bindings, policy revisions, and opaque credential or secret-provider references |\n| Deployment identities | Pre-provisioned replica IDs, peer identities, endpoints, topology, capacity, and initial lifecycle state |\n| Evidence | Exactly one signed document for each mandatory evidence kind |\n\nEvery instance in the package must use the package's connector type and\nversion. Every replica must refer to one package instance and version, begin\n`offline`, and have zero active assignments. Every binding must refer to a\npackage instance owned by the same tenant.\n\nThe package requests `admitted` or `active` version status. It cannot introduce\na `candidate` or already `revoked` version. The canonical digest of the embedded\nmanifest must equal the declared manifest digest before evidence is considered.\n\n## Require seven evidence roles\n\n| Evidence kind | Required signed outcome | Decision represented |\n|---|---|---|\n| `oci_signature` | `verified` | A detached signature statement is bound to the immutable artifact digest |\n| `sbom` | `verified` | A software bill of materials document is present and digest-bound |\n| `provenance` | `verified` | Build provenance is present and digest-bound |\n| `conformance` | `passed` | A trusted evaluator accepted the exact artifact and manifest under connector conformance policy |\n| `vulnerability` | `passed` | A trusted evaluator accepted the exact artifact and software bill of materials under vulnerability policy |\n| `license` | `passed` | A trusted evaluator accepted the exact artifact and software bill of materials under license policy |\n| `revocation` | `passed` | A trusted evaluator reported an acceptable non-revocation state for the artifact and signer |\n\nThe verifier requires the exact seven-kind set. A missing kind fails closed, and\nan extra unsupported kind is rejected.\n\nEach `EvidenceStatement` binds:\n\n- its evidence schema and kind;\n- the exact artifact and manifest digests from the package;\n- the canonical digest of the embedded evidence document;\n- a bounded human- or service-readable signer identity;\n- issue and expiration times; and\n- the role-specific outcome.\n\nThe embedded evidence document is JSON retained for the release pipeline. The\nadmission verifier checks its canonical size and digest but does not reinterpret\nthe document's domain-specific contents. Trust in `passed` therefore comes from\nthe configured role-specific signer and its signed outcome, not from an\nuntrusted field inside the document.\n\n## Apply deployment-owned trust policy\n\n`AdmissionTrustPolicy` supplies package signer roots, a non-empty signer-root\nset for every evidence kind, and hard limits for package size, evidence size,\ninstance count, replica count, binding count, and clock skew. It can also require\none connector owner.\n\nDistinct signing identities are required by default. When that option is\nenabled, the package signer and all seven evidence signers must be eight\ndifferent DIDs. This prevents one broad release key from silently asserting\nscanner, conformance, license, and revocation outcomes.\n\nDisabling distinct-signer enforcement does not remove role-specific trust\nchecks. Each evidence signer still has to belong to the root set configured for\nthat exact evidence kind.\n\nAll signatures use Ed25519 `did:key` identities over canonical JSON. The\npackage and evidence statement must have a valid time window: expiration is\nafter issuance and the current time, and issuance cannot exceed the configured\nclock lead. A signature over stale or not-yet-valid evidence is insufficient.\n\nAt this revision, the package signature covers the `package` payload. The outer\n`signer_did` selects the trusted verification key, while the outer\n`signer_identity` is bounded and included in the journaled wrapper digest but\nis not part of the signed payload.\n\nSecurity decisions must use the trusted DID;\nthe package-level display identity is audit metadata. In contrast, each evidence\nstatement includes its display identity inside the signed statement.\n\n## Verify before any catalog write\n\n`verify_admission_package` is a pure verification boundary. It completes the\nfollowing work before returning a `VerifiedAdmissionPackage`:\n\n1. Validate that trust roots and every configured bound are present and valid.\n2. Canonicalize the complete signed wrapper and enforce the package byte limit.\n3. Verify the package signer against release roots and verify its signature over\n   the package payload.\n4. Validate package schema, ID, non-zero revision, validity window, optional\n   owner, object counts, type-version relationship, requested status, and\n   manifest digest.\n5. Validate instance, replica, and binding references and their initial state.\n6. For each evidence kind, verify the expected subject, trusted role signer,\n   optional signer separation, identity, time window, document size and digest,\n   statement signature, and exact required outcome.\n7. Derive the artifact attestation and connector version from verified data.\n8. Re-run registry version admission over manifest bounds, capability\n   definitions, implementation-support claims, current AIP compatibility, SDK\n   compatibility, attestation statuses, and the canonical schema-bundle digest.\n9. Digest the complete signed wrapper for journal and replay fencing.\n\nNo mutable registry method is available in this function. Verification failure\ntherefore cannot leave a partial catalog change.\n\n## Derive, do not accept, the attestation\n\nThe derived `ArtifactAttestation` records:\n\n- the artifact and canonical manifest-schema bundle digests;\n- software bill of materials, provenance, conformance, vulnerability, and\n  license document digests;\n- the detached-signature evidence reference and package-level display identity;\n- the connector owner, supported AIP versions, and SDK version requirement; and\n- passed conformance, vulnerability, license, and revocation statuses.\n\nThe verifier invokes registry version validation before returning. Attestation\nvalidation is reused during registry admission or activation, host\nregistration, and authenticated connector callback or event ingress.\n\nAt the reviewed revision, the declared AIP set must contain the current protocol\nversion, and the SDK requirement must include the registry crate version. Every\nmandatory policy status must be `passed`, and the schema bundle must match the\nmanifest's input and output schemas.\n\nAn attestation is a verified record of supplied evidence. It is not a claim\nthat every possible security property was tested or that an external provider\nwill behave correctly.\n\n## Apply through a restartable journal\n\nVerification produces an in-memory trusted value. Application separately uses\na short-lived process that holds both registry-administrator and admission\njournal authority.\n\nBefore the first catalog write, `apply_verified_package` records and claims this\nsecret-free operation identity:\n\n| Field | Purpose |\n|---|---|\n| `package_id`, `revision`, `package_digest` | Fence one exact signed package revision |\n| `connector_type_id`, `version_id` | Identify the catalog subject |\n| `signer_identity` | Retain the bounded package-level display identity for audit correlation |\n| `claim_id`, `claim_expires_at` | Fence the current application worker with a renewable five-minute claim |\n| `state`, `last_error`, `updated_at` | Record progress, bounded failure detail, and audit time |\n\nThe claim result is one of:\n\n- `New` when no operation existed;\n- `Resume` when the same digest can safely continue after a failed or expired\n  attempt; or\n- `AlreadyApplied` when the exact operation completed earlier.\n\nThe journal state is `applying` while a valid claim owns the work and `failed`\nwhen a resumable step records an error. It becomes `applied` after every step\ncompletes or `revoked` after the exact applied version is disabled for new\ntraffic.\n\nThe journal rejects a stale revision, a different digest or catalog subject\nunder the same package revision, or a new revision while an earlier revision is\nunfinished. It also rejects a live competing claim or resumption of a revoked\noperation.\n\n### Apply ordered idempotent steps\n\nThe application order is:\n\n1. admission policies;\n2. connector type;\n3. immutable connector version and capability definitions;\n4. connector instances;\n5. pre-provisioned offline replicas; and\n6. tenant capability bindings.\n\nThe process renews its claim before every step. Each registry write validates\nits references and is idempotent for identical content. Conflicting immutable\ncontent or a stale monotonic revision is rejected.\n\nThe complete package is deliberately not one database transaction. If a\nprocess fails after an intermediate step, the journal records a bounded failure\nand a later worker resumes the exact package and digest. Earlier identical\nwrites become no-ops; later steps continue in the same order. The operation\nbecomes `applied` only after every step completes.\n\nThis multi-step design allows bounded restartable work without giving the\ncentral daemon, connector hosts, lifecycle service, or external orchestrator\ncatalog-administrator credentials.\n\n## Revoke the exact version\n\nRevocation accepts only an `applied` journal operation. It first moves the exact\nconnector version to irrevocable `revoked` status, which stops new traffic, and\nthen marks the package operation `revoked` with a bounded reason. Repeating an\nalready completed revoke returns the recorded state.\n\nThe connector type remains enabled so another independently admitted version\nof the same type can continue serving. A type-wide emergency stop is a separate\nregistry-administrator action.\n\nRevocation does not erase the package, attestation, route assignments, or\njournal record. It also does not determine whether an action already in progress\ncommitted a provider side effect; that remains a lifecycle and reconciliation\ndecision.\n\n## Interpret each evidence level precisely\n\n| Observed state | What it supports | What it does not support |\n|---|---|---|\n| Signed package | A trusted release key authorized exact package content | Any independent policy outcome |\n| Complete signed evidence set | Trusted role signers bound required outcomes to the exact artifact, manifest, documents, and validity windows | Correctness beyond the supplied evaluator scopes |\n| `VerifiedAdmissionPackage` | The current verifier accepted trust, subject, bounds, compatibility, and registry invariants | A durable registry write |\n| Journal state `applied` | Every ordered registry step completed for the exact package digest | A running or ready connector host |\n| Active version and ready replica | Routing may consider an otherwise eligible target | Tenant action authorization or provider success |\n| Journal state `revoked` | New traffic is disabled for that exact version | Cancellation or rollback of an already committed provider effect |\n\nSource presence, a local image digest, a generated software bill of materials,\nor an unsigned test report does not reach these evidence levels by itself.\n\n## Fail closed at the responsible boundary\n\n| Failure | Decision |\n|---|---|\n| Unknown package or evidence signer | Reject as a signature failure |\n| Missing, extra, stale, mismatched, oversized, or rejected evidence | Reject as an evidence failure |\n| Wrong schema, relationship, digest, status, owner, count, or compatibility | Reject as invalid admission input |\n| Same revision with different signed content | Reject as an operation conflict |\n| Another unexpired claim owns the operation | Stop and let that claim complete or expire |\n| Idempotent catalog step fails | Record bounded failure and resume the exact digest; do not skip ahead |\n| Applied artifact becomes unacceptable | Revoke the exact version and stop new routing |\n\nNever replace failed evidence by editing its signed outcome or registry\nattestation. Produce a new evidence statement and a new signed package revision\nunder the configured trust policy.\n\n## Trade-offs and non-implications\n\n- **Role-specific signatures reduce self-assertion.** They require management\n  of several trust roots, signer lifecycles, and evidence expiration windows.\n- **Canonical digests strengthen subject binding.** Formatting-equivalent JSON\n  converges on one representation, while a change to canonical content produces\n  a different package identity.\n- **Restartable writes favor recoverability.** They expose intermediate durable\n  catalog state to administrators, so routing eligibility still depends on the\n  complete active type, version, binding, replica, lease, and policy chain.\n- **Version-scoped revocation preserves independent releases.** Emergency\n  containment across every version requires a separate type-wide decision.\n\nAdmission does not build or execute an image, start a host, resolve provider\ncredentials, grant a client permission, prove connector readiness, qualify a\ndeployment, or observe an external product. A signed and applied package is a\nprerequisite for those later boundaries, not a substitute for them.\n\n## Related pages\n\n- [Build a connector](../guides/build-a-connector.md)\n- [Deploy the connector fleet](../guides/deploy-connector-fleet.md)\n- [Connector registry and routing](connector-registry-and-routing.md)\n- [Orchestrate and roll back connector hosts](../guides/connector-orchestration.md)\n- [Release artifacts and verification](../reference/release-artifacts.md)\n",
    "text": "Connector admission and supply-chain trust\n\nUse this page to understand how the reviewed AIP implementation converts a\nsigned connector release and independently trusted evidence into registry state\nthat can receive traffic. It is primarily for security reviewers; connector\ndevelopers and operators can use the same model to distinguish packaging,\nverification, application, deployment, and revocation.\n\nThe architecture describes version 1.0.0 of the Rust workspace at source\nrevision 97be86e9efedf07ecf1783b03800f683f107fb04. This admission pipeline is an\nimplementation security boundary, not a release process required by AIP 1.0.\n\nA release signature is necessary but insufficient\n\nA valid package signature establishes that a trusted release authority\nauthorized this exact canonical package value. It does not independently prove\nthe expected source, an acceptable license set, or conformance. It also does not\nprove the absence of disallowed vulnerabilities or a current unrevoked state.\n\nThe admission boundary separates those decisions. A release authority signs the\ncomplete declarative package. Seven evidence roles each sign a statement about\nthe same artifact and manifest. A deployment-owned trust policy decides which\nsigning identities may speak for each role and which outcome is acceptable.\n\nOnly the verifier derives the registry's ArtifactAttestation. Package callers\ncannot submit Passed registry statuses directly.\n\nKeep five authorities separate\n\nmermaid\nflowchart LR\n    B[\"Build and policy systems\"] --> E[\"Seven signed evidence documents\"]\n    R[\"Release authority\"] --> P[\"Signed admission package\"]\n    E --> P\n    P --> V[\"Admission verifier\"]\n    T[\"Deployment trust policy\"] --> V\n    V --> A[\"Verified package and derived attestation\"]\n    A -.->|journaled idempotent writes| G[\"Connector registry control plane\"]\n    G --> D[\"Registry data plane\"]\n    A -.->|exact targets only| O[\"External orchestration\"]\n\nThe text equivalent is:\n1. Build and policy systems produce evidence documents for one exact artifact\n   and manifest.\n2. Each evidence authority signs a canonical statement containing the evidence\n   kind, subject digests, document digest, validity window, and outcome.\n3. The release authority embeds the seven signed documents in one declarative\n   package and signs the complete package.\n4. The admission verifier applies deployment-owned trust roots, bounds,\n   signatures, digests, time windows, subject relationships, and registry\n   invariants.\n5. A short-lived administrator claims the verified package in a durable journal\n   and applies its state through restartable idempotent steps.\n6. Long-running data-plane and orchestration processes consume admitted\n   identities without receiving catalog-administrator authority.\n\n| Authority | May establish | Does not establish |\n\n| Release authority | Authorization of the exact complete package | Independent scanner, conformance, license, or revocation success |\n| Evidence authority | One role-specific signed observation and outcome | Permission to publish the package or start a process |\n| Admission verifier | Whether all configured trust, subject, freshness, bounds, and compatibility checks pass | Whether an artifact is running or a provider is healthy |\n| Catalog administrator | Durable application or revocation of verified registry state | Client action authorization or provider mutation |\n| Orchestration executor | Whether exact admitted replica processes match signed deployment intent | Artifact admission, tenant binding, or registry administration |\n\nBind the complete release subject\n\nThe signed AdmissionPackage is a declarative catalog change, not an image or\ndeployment command.\n\n| Package group | Bound content |\n\n| Package identity | Schema, stable package ID, monotonic revision, issue time, and expiration time |\n| Connector type | Stable type ID, name, owner, and initial enabled state |\n| Version declaration | Version ID, type ID, release label, requested admitted or active status, complete manifest, manifest digest, artifact digest, implementation support, supported AIP versions, and SDK requirement |\n| Policy and tenancy | Admission policies, tenant-owned instances, capability bindings, policy revisions, and opaque credential or secret-provider references |\n| Deployment identities | Pre-provisioned replica IDs, peer identities, endpoints, topology, capacity, and initial lifecycle state |\n| Evidence | Exactly one signed document for each mandatory evidence kind |\n\nEvery instance in the package must use the package's connector type and\nversion. Every replica must refer to one package instance and version, begin\noffline, and have zero active assignments. Every binding must refer to a\npackage instance owned by the same tenant.\n\nThe package requests admitted or active version status. It cannot introduce\na candidate or already revoked version. The canonical digest of the embedded\nmanifest must equal the declared manifest digest before evidence is considered.\n\nRequire seven evidence roles\n\n| Evidence kind | Required signed outcome | Decision represented |\n\n| ocisignature | verified | A detached signature statement is bound to the immutable artifact digest |\n| sbom | verified | A software bill of materials document is present and digest-bound |\n| provenance | verified | Build provenance is present and digest-bound |\n| conformance | passed | A trusted evaluator accepted the exact artifact and manifest under connector conformance policy |\n| vulnerability | passed | A trusted evaluator accepted the exact artifact and software bill of materials under vulnerability policy |\n| license | passed | A trusted evaluator accepted the exact artifact and software bill of materials under license policy |\n| revocation | passed | A trusted evaluator reported an acceptable non-revocation state for the artifact and signer |\n\nThe verifier requires the exact seven-kind set. A missing kind fails closed, and\nan extra unsupported kind is rejected.\n\nEach EvidenceStatement binds:\n• its evidence schema and kind;\n• the exact artifact and manifest digests from the package;\n• the canonical digest of the embedded evidence document;\n• a bounded human- or service-readable signer identity;\n• issue and expiration times; and\n• the role-specific outcome.\n\nThe embedded evidence document is JSON retained for the release pipeline. The\nadmission verifier checks its canonical size and digest but does not reinterpret\nthe document's domain-specific contents. Trust in passed therefore comes from\nthe configured role-specific signer and its signed outcome, not from an\nuntrusted field inside the document.\n\nApply deployment-owned trust policy\n\nAdmissionTrustPolicy supplies package signer roots, a non-empty signer-root\nset for every evidence kind, and hard limits for package size, evidence size,\ninstance count, replica count, binding count, and clock skew. It can also require\none connector owner.\n\nDistinct signing identities are required by default. When that option is\nenabled, the package signer and all seven evidence signers must be eight\ndifferent DIDs. This prevents one broad release key from silently asserting\nscanner, conformance, license, and revocation outcomes.\n\nDisabling distinct-signer enforcement does not remove role-specific trust\nchecks. Each evidence signer still has to belong to the root set configured for\nthat exact evidence kind.\n\nAll signatures use Ed25519 did:key identities over canonical JSON. The\npackage and evidence statement must have a valid time window: expiration is\nafter issuance and the current time, and issuance cannot exceed the configured\nclock lead. A signature over stale or not-yet-valid evidence is insufficient.\n\nAt this revision, the package signature covers the package payload. The outer\nsignerdid selects the trusted verification key, while the outer\nsigneridentity is bounded and included in the journaled wrapper digest but\nis not part of the signed payload.\n\nSecurity decisions must use the trusted DID;\nthe package-level display identity is audit metadata. In contrast, each evidence\nstatement includes its display identity inside the signed statement.\n\nVerify before any catalog write\n\nverifyadmissionpackage is a pure verification boundary. It completes the\nfollowing work before returning a VerifiedAdmissionPackage:\n1. Validate that trust roots and every configured bound are present and valid.\n2. Canonicalize the complete signed wrapper and enforce the package byte limit.\n3. Verify the package signer against release roots and verify its signature over\n   the package payload.\n4. Validate package schema, ID, non-zero revision, validity window, optional\n   owner, object counts, type-version relationship, requested status, and\n   manifest digest.\n5. Validate instance, replica, and binding references and their initial state.\n6. For each evidence kind, verify the expected subject, trusted role signer,\n   optional signer separation, identity, time window, document size and digest,\n   statement signature, and exact required outcome.\n7. Derive the artifact attestation and connector version from verified data.\n8. Re-run registry version admission over manifest bounds, capability\n   definitions, implementation-support claims, current AIP compatibility, SDK\n   compatibility, attestation statuses, and the canonical schema-bundle digest.\n9. Digest the complete signed wrapper for journal and replay fencing.\n\nNo mutable registry method is available in this function. Verification failure\ntherefore cannot leave a partial catalog change.\n\nDerive, do not accept, the attestation\n\nThe derived ArtifactAttestation records:\n• the artifact and canonical manifest-schema bundle digests;\n• software bill of materials, provenance, conformance, vulnerability, and\n  license document digests;\n• the detached-signature evidence reference and package-level display identity;\n• the connector owner, supported AIP versions, and SDK version requirement; and\n• passed conformance, vulnerability, license, and revocation statuses.\n\nThe verifier invokes registry version validation before returning. Attestation\nvalidation is reused during registry admission or activation, host\nregistration, and authenticated connector callback or event ingress.\n\nAt the reviewed revision, the declared AIP set must contain the current protocol\nversion, and the SDK requirement must include the registry crate version. Every\nmandatory policy status must be passed, and the schema bundle must match the\nmanifest's input and output schemas.\n\nAn attestation is a verified record of supplied evidence. It is not a claim\nthat every possible security property was tested or that an external provider\nwill behave correctly.\n\nApply through a restartable journal\n\nVerification produces an in-memory trusted value. Application separately uses\na short-lived process that holds both registry-administrator and admission\njournal authority.\n\nBefore the first catalog write, applyverifiedpackage records and claims this\nsecret-free operation identity:\n\n| Field | Purpose |\n\n| packageid, revision, packagedigest | Fence one exact signed package revision |\n| connectortypeid, versionid | Identify the catalog subject |\n| signeridentity | Retain the bounded package-level display identity for audit correlation |\n| claimid, claimexpiresat | Fence the current application worker with a renewable five-minute claim |\n| state, lasterror, updatedat | Record progress, bounded failure detail, and audit time |\n\nThe claim result is one of:\n• New when no operation existed;\n• Resume when the same digest can safely continue after a failed or expired\n  attempt; or\n• AlreadyApplied when the exact operation completed earlier.\n\nThe journal state is applying while a valid claim owns the work and failed\nwhen a resumable step records an error. It becomes applied after every step\ncompletes or revoked after the exact applied version is disabled for new\ntraffic.\n\nThe journal rejects a stale revision, a different digest or catalog subject\nunder the same package revision, or a new revision while an earlier revision is\nunfinished. It also rejects a live competing claim or resumption of a revoked\noperation.\n\nApply ordered idempotent steps\n\nThe application order is:\n1. admission policies;\n2. connector type;\n3. immutable connector version and capability definitions;\n4. connector instances;\n5. pre-provisioned offline replicas; and\n6. tenant capability bindings.\n\nThe process renews its claim before every step. Each registry write validates\nits references and is idempotent for identical content. Conflicting immutable\ncontent or a stale monotonic revision is rejected.\n\nThe complete package is deliberately not one database transaction. If a\nprocess fails after an intermediate step, the journal records a bounded failure\nand a later worker resumes the exact package and digest. Earlier identical\nwrites become no-ops; later steps continue in the same order. The operation\nbecomes applied only after every step completes.\n\nThis multi-step design allows bounded restartable work without giving the\ncentral daemon, connector hosts, lifecycle service, or external orchestrator\ncatalog-administrator credentials.\n\nRevoke the exact version\n\nRevocation accepts only an applied journal operation. It first moves the exact\nconnector version to irrevocable revoked status, which stops new traffic, and\nthen marks the package operation revoked with a bounded reason. Repeating an\nalready completed revoke returns the recorded state.\n\nThe connector type remains enabled so another independently admitted version\nof the same type can continue serving. A type-wide emergency stop is a separate\nregistry-administrator action.\n\nRevocation does not erase the package, attestation, route assignments, or\njournal record. It also does not determine whether an action already in progress\ncommitted a provider side effect; that remains a lifecycle and reconciliation\ndecision.\n\nInterpret each evidence level precisely\n\n| Observed state | What it supports | What it does not support |\n\n| Signed package | A trusted release key authorized exact package content | Any independent policy outcome |\n| Complete signed evidence set | Trusted role signers bound required outcomes to the exact artifact, manifest, documents, and validity windows | Correctness beyond the supplied evaluator scopes |\n| VerifiedAdmissionPackage | The current verifier accepted trust, subject, bounds, compatibility, and registry invariants | A durable registry write |\n| Journal state applied | Every ordered registry step completed for the exact package digest | A running or ready connector host |\n| Active version and ready replica | Routing may consider an otherwise eligible target | Tenant action authorization or provider success |\n| Journal state revoked | New traffic is disabled for that exact version | Cancellation or rollback of an already committed provider effect |\n\nSource presence, a local image digest, a generated software bill of materials,\nor an unsigned test report does not reach these evidence levels by itself.\n\nFail closed at the responsible boundary\n\n| Failure | Decision |\n\n| Unknown package or evidence signer | Reject as a signature failure |\n| Missing, extra, stale, mismatched, oversized, or rejected evidence | Reject as an evidence failure |\n| Wrong schema, relationship, digest, status, owner, count, or compatibility | Reject as invalid admission input |\n| Same revision with different signed content | Reject as an operation conflict |\n| Another unexpired claim owns the operation | Stop and let that claim complete or expire |\n| Idempotent catalog step fails | Record bounded failure and resume the exact digest; do not skip ahead |\n| Applied artifact becomes unacceptable | Revoke the exact version and stop new routing |\n\nNever replace failed evidence by editing its signed outcome or registry\nattestation. Produce a new evidence statement and a new signed package revision\nunder the configured trust policy.\n\nTrade-offs and non-implications\n• Role-specific signatures reduce self-assertion. They require management\n  of several trust roots, signer lifecycles, and evidence expiration windows.\n• Canonical digests strengthen subject binding. Formatting-equivalent JSON\n  converges on one representation, while a change to canonical content produces\n  a different package identity.\n• Restartable writes favor recoverability. They expose intermediate durable\n  catalog state to administrators, so routing eligibility still depends on the\n  complete active type, version, binding, replica, lease, and policy chain.\n• Version-scoped revocation preserves independent releases. Emergency\n  containment across every version requires a separate type-wide decision.\n\nAdmission does not build or execute an image, start a host, resolve provider\ncredentials, grant a client permission, prove connector readiness, qualify a\ndeployment, or observe an external product. A signed and applied package is a\nprerequisite for those later boundaries, not a substitute for them.\n\nRelated pages\n• Build a connector (../guides/build-a-connector.md)\n• Deploy the connector fleet (../guides/deploy-connector-fleet.md)\n• Connector registry and routing (connector-registry-and-routing.md)\n• Orchestrate and roll back connector hosts (../guides/connector-orchestration.md)\n• Release artifacts and verification (../reference/release-artifacts.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "c9973b062639ea10a1c9f8c5709966882bc7ef800659fc6c8732b84da59ee977"
  }
}