{
  "schemaVersion": "1.0",
  "title": "Conformance and qualification",
  "description": "Use this reference to select the evidence layer that matches a claim, run the available check correctly, and report its result against an exact artifact. Conformance asks whether a named contract is satisfied. Qualification asks whether an ",
  "canonical": "https://getaip.org/docs/reference/conformance",
  "route": "/docs/reference/conformance",
  "source": "docs/reference/conformance.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Protocol Standard",
  "documentType": "Reference",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "d7cce13d1d555644d04a4d73c66c95b113737635",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/reference/conformance.md",
    "txt": "/docs/download/reference/conformance.txt",
    "json": "/docs/download/reference/conformance.json",
    "pdf": "/docs/download/reference/conformance.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Conformance and qualification\ndescription: Select, run, interpret, and report AIP evidence without overstating what one suite proves\nkind: reference\naudience: evaluator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"d7cce13d1d555644d04a4d73c66c95b113737635\"\n---\n\n# Conformance and qualification\n\nUse this reference to select the evidence layer that matches a claim, run the\navailable check correctly, and report its result against an exact artifact.\nConformance asks whether a named contract is satisfied. Qualification asks\nwhether an exact build works with specified dependencies and topology under a\ndefined campaign.\n\nThis page describes the conformance surfaces present in GetAIP `2.0.0` at\nsource revision `d7cce13d1d555644d04a4d73c66c95b113737635`. The protected\nsource gate passed for that release, but this page does not extend the result to\na later worktree, rebuilt image, deployment, connector, or external provider.\nSee [implementation status](implementation-status.md) for current claims and\nknown gaps.\n\n## Choose the evidence layer\n\nEvidence is cumulative only when the same artifact and applicable scope pass\nevery required layer.\n\n| Layer | It can establish | It cannot establish alone |\n|---|---|---|\n| Structural validation | One instance matches a schema and basic invariants | Authorization, lifecycle, or side effects |\n| Unit or fixture test | One deterministic code path matches its assertions | Process, network, storage, or independent-peer behavior |\n| Core conformance | Named native envelope, manifest, profile-binding, and capability-contract checks pass | Every protocol requirement or deployed route |\n| Profile conformance | A named profile version, mapping, codec, or state machine passes its suite | Native policy, an independent client, or another version |\n| Connector conformance | An exact manifest and driver pass required behavior families | Real provider availability unless the evidence source is isolated-live |\n| Integration test | Selected repository components work together | Release identity or arbitrary deployment topology |\n| Isolated-live qualification | An exact artifact interoperates with pinned real dependencies in one topology | Other versions, accounts, regions, load, or production policy |\n| Deployment campaign | The target deployment passes defined security, fault, restart, and capacity scenarios | Future changes or untested conditions |\n\n`implemented`, `conforming`, `qualified`, and `production-ready` are\nnot interchangeable. A higher layer must retain the lower-layer identities\ninstead of referring to a mutable branch or product name.\n\n## Identify the subject before testing\n\nRecord these values before accepting a result:\n\n| Identity | Minimum value |\n|---|---|\n| Source | Full commit and clean or dirty state |\n| Source tree | Deterministic tree or archive digest |\n| Build | Package version plus binary, archive, or image digest |\n| Contract | AIP version, profile ID and version, or connector manifest digest |\n| Dependencies | Peer, provider, database, broker, and client revisions in scope |\n| Topology | Processes, trust domains, storage class, network boundary, and replica count |\n| Suite | Exact command or entry point, expected check IDs, and suite revision |\n| Time | UTC start and finish |\n\nA result without subject identity can describe a past observation, but it\ncannot qualify a newly built artifact.\n\n## Use the core diagnostic correctly\n\nThe CLI exposes one narrow diagnostic:\n\n```sh\ncargo run --locked -q -p getaip-cli -- conformance run \\\n  | jq -e '.passed == true'\n```\n\nWithout `--envelope`, this creates one native `ManifestRequest` body and\nruns `core.message_body`. It is a smoke check for one built-in message, not\nthe complete core or schema registry.\n\nTo inspect one envelope:\n\n```sh\ncargo run --locked -q -p getaip-cli -- conformance run \\\n  --envelope path/to/envelope.json \\\n  | jq -e '.passed == true'\n```\n\nThe file must first decode as a typed `Envelope`. The diagnostic then applies\ncombined envelope schema and core validation and prints `name`, `passed`,\nand `detail`.\n\nThe command itself does not convert a printed `passed: false` into an error\nexit. Keep the `jq -e` assertion, or parse and assert the field in the calling\ntool. A JSON decode or command error does fail the process.\n\n### Embedded manifest report\n\nThe reusable gateway manifest report contains five checks:\n\n| Check ID | Scope |\n|---|---|\n| `discovery.manifest` | Nonempty manifest version and profile set; nonempty capability names; object input schemas |\n| `discovery.profile_set` | No empty profile IDs and every caller-required profile present |\n| `discovery.profile_bindings` | Required compatibility metadata for recognized advertised profiles |\n| `enterprise.capability_contract` | Cross-field side-effect, execution, retry, approval, data, credential, transaction, and compensation rules |\n| `profile.mcp.tools_list` | Manifest capabilities project to named MCP tools |\n\nThese are implementation checks, not a complete enumeration of\n[AIP 1.0](../spec/AIP-1.0.md). Manifest admission also compares callable\ncapabilities with implementation-support declarations; see the\n[connector contract](../spec/connector-contract.md).\n\nSchema export and schema drift are separate build checks. Use\n[JSON schemas](../spec/schemas.md) for the exact 52-file registry and\nvalidation layers.\n\n## Evaluate connector conformance\n\nThe shared connector harness returns thirteen checks:\n\n1. `connector.atomic_manifest_admission`; and\n2. one `connector.behavior.*` check for each of twelve behavior families.\n\nEvery scenario is requested from the driver. A scenario may report not\napplicable only when the published manifest does not require it.\n\n| Scenario ID | Required when | Required assertions |\n|---|---|---|\n| `identity_credentials` | Any capability is advertised | `transport_actor_bound`, `tenant_isolated`, `credential_handle_opaque` |\n| `schema_enforcement` | Any capability is advertised | `invalid_input_rejected`, `invalid_output_rejected` |\n| `idempotency_duplicates` | Any contract requires idempotency | `duplicate_suppressed`, `collision_rejected`, `delivery_id_stable` |\n| `retry_exhaustion` | Any contract supports retry | `retryable_error_preserved`, `backoff_observed`, `exhaustion_dead_lettered` |\n| `cancellation_races` | Any contract supports cancellation | `before_dispatch_cancelled`, `in_flight_cancelled`, `late_cancel_preserved_terminal` |\n| `streaming_backpressure` | Any contract supports streaming | `ordered_chunks`, `bounded_backpressure`, `terminal_chunk_unique` |\n| `errors_uncertain_outcomes` | Any capability is advertised | `protocol_fields_preserved`, `uncertain_outcome_reconciled`, `error_secrets_redacted` |\n| `approval_lifecycle` | Any contract requires approval | `authority_verified`, `quorum_enforced`, `evidence_persisted`, `resume_once` |\n| `transaction_lifecycle` | Any transaction contract exists | `plan_before_commit`, `provider_operation_checkpointed`, `reconcile_before_retry`, `compensation_governed` |\n| `audit_redaction` | Any capability is advertised | `receipts_emitted`, `audit_correlated`, `sensitive_fields_redacted`, `raw_secret_absent` |\n| `webhook_security` | The generic webhook profile is advertised | `signature_verified`, `skew_rejected`, `replay_rejected` |\n| `restart_reconnect` | Any capability is advertised | `state_recovered`, `duplicate_effect_prevented`, `reconnect_cursor_resumed` |\n\nThe registry contains 38 named assertions. For an executed scenario, every\nrequired name must be present and true, and the evidence must contain at least\none nonempty artifact ID. A missing assertion, false assertion, empty artifact\nlist, or driver error fails that scenario.\n\nThe driver accepts two evidence-source classes:\n\n- `deterministic_provider_double`, which records real connector requests,\n  retries, cancellation, failures, and effects under controlled behavior; or\n- `isolated_live_provider`, which exercises a pinned real provider.\n\nStatic booleans returned without executing the connector are not valid release\nevidence. An isolated-live source can support qualification only when the exact\nprovider, artifact, topology, configuration class, timestamps, and raw\nartifacts are also retained.\n\nThe harness is reusable; its existence does not mean every connector invokes\nit or passes every applicable scenario. Check the exact connector result in\n[implementation status](implementation-status.md) and its qualification page.\n\n## Evaluate MCP conformance\n\nMCP has seven callable suite entry points. The aggregate rows below overlap;\ndo not add them into one total.\n\n| Suite entry point | Checks at this revision | Scope |\n|---|---:|---|\n| Golden fixtures | 104 | Every stable method in all four versions against the pinned official schema snapshot |\n| Negative fixtures | 110 | 104 method and parameter mutations plus six cross-cutting malformed-input checks |\n| Profile mapping | 8 | Version matrices, initialize metadata, tool listing, and result projection |\n| External client | 4 | Initialize, tool discovery, optional resource discovery, and AIP manifest projection |\n| Transport codecs | 3 | stdio JSON-RPC, Streamable HTTP POST classification, and SSE round trip |\n| Version-transport server matrix | 56 | Seven lifecycle checks for each of eight executable version-transport pairs |\n| Server aggregate | 61 | Five base server checks plus the 56-check matrix |\n\nThe first three MCP schema snapshots use JSON Schema Draft 7. The\n`2025-11-25` snapshot uses Draft 2020-12. Golden fixtures cover 24, 24, 25,\nand 31 stable methods respectively. Unstable methods are not golden fixtures.\n\n### CLI client check\n\nRun the external-client subset against Streamable HTTP:\n\n```sh\ncargo run --locked -q -p getaip-cli -- mcp conformance \\\n  --url http://127.0.0.1:18080/mcp\n```\n\nOr against a command-launched stdio server:\n\n```sh\ncargo run --locked -q -p getaip-cli -- mcp conformance \\\n  --command ./target/release/getaip-server \\\n  --arg=--mcp-stdio \\\n  --arg=--service-id \\\n  --arg=agent:getaip:server:mcp-conformance\n```\n\nThis command runs only the four external-client checks and returns an error\nwhen any of them fails. Optional resource discovery tolerates an unsupported\nor failed resource list, so it does not prove resource support. The command\ndoes not run golden, negative, profile, codec, server, or all-version matrix\nchecks.\n\nA full MCP claim must name the profile version, transport, peer role, suite\nentry points, expected check IDs, and exact client and server artifacts. Read\n[compatibility profiles](../spec/compatibility-profiles.md) for the supported\nversion and transport matrix.\n\n## Record uncovered profile boundaries\n\nThe reviewed source has no dedicated A2A conformance suite or A2A conformance\nCLI. A2A profile and daemon tests are implementation evidence, not an\nindependent interoperability claim.\n\nThe generic webhook helper exposes one signature-and-skew check. The connector\nharness adds signature, skew, and replay assertions when the webhook profile\nis advertised. Neither check qualifies a provider's raw header mapping or\ndelivery behavior without connector and live evidence.\n\nCore envelope and manifest checks do not exercise every HTTP route, SSE or\nWebSocket recovery path, NATS broker behavior, storage backend, or independent\nclient. There is no single command that establishes conformance for every AIP\nsurface at this revision.\n\n## Run the code-owned release gate\n\nThe repository release gate is:\n\n```sh\ncargo run -p xtask -- release-check\n```\n\nIt executes these source-owned checks in order:\n\n| Gate | Behavior |\n|---|---|\n| Formatting | `cargo fmt --all --check` |\n| Dependency boundaries | Product-neutral daemon/fleet boundary and private SDK closure checks |\n| Semantic versioning | Per-package checks against an earlier stable tag when one exists |\n| Schemas | Regenerate the committed AIP schema directory |\n| Lint | Workspace, all targets, all features, warnings denied |\n| Main tests | Workspace all-feature tests through `cargo nextest` |\n| Minimal features | Workspace tests with no default features |\n| Dependency policy | `cargo deny check` |\n| Vulnerability audit | `cargo audit` |\n| Unused dependencies | `cargo machete` |\n| Fuzz targets | Compile the fuzz workspace |\n| API documentation | Build workspace docs for all features without dependencies |\n\nThe release workflow installs pinned QA tool versions, checks publication\nhygiene, runs this gate, requires no schema diff, and scans full Git history\nfor secrets.\n\nThe gate does not start external products, prove connector credentials, run an\nisolated-live campaign, establish broker or database failover, or qualify a\ntarget deployment's load and fault limits. Attach those campaigns separately\nwhen the release claim requires them.\n\n## Interpret a report safely\n\nBoth report types compute success by asking whether every recorded check\npassed. An empty check list therefore also evaluates as successful. Every\nconsumer should assert the expected suite identity, check count, and stable\ncheck IDs before accepting the aggregate status.\n\nUse this interpretation order:\n\n1. verify artifact, contract, suite, and dependency identities;\n2. verify the expected checks are present exactly once;\n3. reject failed, missing, duplicate, or unexpected required checks;\n4. verify that not-applicable scenarios are permitted by the published\n   contract;\n5. resolve every artifact ID to retained, immutable, redacted evidence;\n6. record limitations and unexecuted external conditions;\n7. publish only the narrow claim supported by those facts.\n\nA green report cannot repair a stale manifest, an unpinned dependency, or a\nmissing scenario.\n\n## Retain reproducible evidence\n\nRetain a machine-readable report and raw artifacts without credentials. At\nminimum, include:\n\n- the subject identities listed above;\n- exact command arguments and relevant tool versions;\n- configuration class and topology without secret values;\n- scenario and check IDs with pass, fail, or not-applicable status;\n- action, transaction, receipt, trace, and provider request IDs when safe;\n- restart, replay, cancellation, approval, reconciliation, and provider\n  observations required by the campaign;\n- start and finish timestamps;\n- raw artifact paths, sizes, and cryptographic digests;\n- known omissions, expected failures, and environmental limits.\n\nCopy published results from the retained report rather than rewriting them\nmanually. A byte-for-byte comparison between the published artifact and the\nretained source prevents accidental status drift.\n\n## Use precise claim language\n\n| Say | Only when |\n|---|---|\n| `schema-valid` | The named instance passed the stated schema and invariant check |\n| `implemented` | The behavior exists in the identified source or artifact and deterministic tests cover it |\n| `conforming` | The exact subject passed the named complete applicable conformance matrix |\n| `qualified` | The exact artifact and pinned dependencies passed the defined qualification topology and campaign |\n| `observed live` | A timestamped live run produced retained evidence, but broader qualification is not claimed |\n| `production-ready for <target>` | That target's required security, operations, recovery, fault, and capacity campaign passed |\n\nAlways append the scope: profile version, connector, topology, artifact, and\ndate as applicable. Avoid `fully supported` or `all tests passed` when the\nstatement omits the exact suite and excluded boundaries.\n\n## Related documentation\n\n- [Implementation status](implementation-status.md)\n- [Testing and evidence index](../testing/README.md)\n- [Compatibility profiles](../spec/compatibility-profiles.md)\n- [Connector contract](../spec/connector-contract.md)\n",
    "text": "Conformance and qualification\n\nUse this reference to select the evidence layer that matches a claim, run the\navailable check correctly, and report its result against an exact artifact.\nConformance asks whether a named contract is satisfied. Qualification asks\nwhether an exact build works with specified dependencies and topology under a\ndefined campaign.\n\nThis page describes the conformance surfaces present in GetAIP 2.0.0 at\nsource revision d7cce13d1d555644d04a4d73c66c95b113737635. The protected\nsource gate passed for that release, but this page does not extend the result to\na later worktree, rebuilt image, deployment, connector, or external provider.\nSee implementation status (implementation-status.md) for current claims and\nknown gaps.\n\nChoose the evidence layer\n\nEvidence is cumulative only when the same artifact and applicable scope pass\nevery required layer.\n\n| Layer | It can establish | It cannot establish alone |\n\n| Structural validation | One instance matches a schema and basic invariants | Authorization, lifecycle, or side effects |\n| Unit or fixture test | One deterministic code path matches its assertions | Process, network, storage, or independent-peer behavior |\n| Core conformance | Named native envelope, manifest, profile-binding, and capability-contract checks pass | Every protocol requirement or deployed route |\n| Profile conformance | A named profile version, mapping, codec, or state machine passes its suite | Native policy, an independent client, or another version |\n| Connector conformance | An exact manifest and driver pass required behavior families | Real provider availability unless the evidence source is isolated-live |\n| Integration test | Selected repository components work together | Release identity or arbitrary deployment topology |\n| Isolated-live qualification | An exact artifact interoperates with pinned real dependencies in one topology | Other versions, accounts, regions, load, or production policy |\n| Deployment campaign | The target deployment passes defined security, fault, restart, and capacity scenarios | Future changes or untested conditions |\n\nimplemented, conforming, qualified, and production-ready are\nnot interchangeable. A higher layer must retain the lower-layer identities\ninstead of referring to a mutable branch or product name.\n\nIdentify the subject before testing\n\nRecord these values before accepting a result:\n\n| Identity | Minimum value |\n\n| Source | Full commit and clean or dirty state |\n| Source tree | Deterministic tree or archive digest |\n| Build | Package version plus binary, archive, or image digest |\n| Contract | AIP version, profile ID and version, or connector manifest digest |\n| Dependencies | Peer, provider, database, broker, and client revisions in scope |\n| Topology | Processes, trust domains, storage class, network boundary, and replica count |\n| Suite | Exact command or entry point, expected check IDs, and suite revision |\n| Time | UTC start and finish |\n\nA result without subject identity can describe a past observation, but it\ncannot qualify a newly built artifact.\n\nUse the core diagnostic correctly\n\nThe CLI exposes one narrow diagnostic:\n\ncargo run --locked -q -p getaip-cli -- conformance run \\\n  | jq -e '.passed == true'\n\nWithout --envelope, this creates one native ManifestRequest body and\nruns core.messagebody. It is a smoke check for one built-in message, not\nthe complete core or schema registry.\n\nTo inspect one envelope:\n\ncargo run --locked -q -p getaip-cli -- conformance run \\\n  --envelope path/to/envelope.json \\\n  | jq -e '.passed == true'\n\nThe file must first decode as a typed Envelope. The diagnostic then applies\ncombined envelope schema and core validation and prints name, passed,\nand detail.\n\nThe command itself does not convert a printed passed: false into an error\nexit. Keep the jq -e assertion, or parse and assert the field in the calling\ntool. A JSON decode or command error does fail the process.\n\nEmbedded manifest report\n\nThe reusable gateway manifest report contains five checks:\n\n| Check ID | Scope |\n\n| discovery.manifest | Nonempty manifest version and profile set; nonempty capability names; object input schemas |\n| discovery.profileset | No empty profile IDs and every caller-required profile present |\n| discovery.profilebindings | Required compatibility metadata for recognized advertised profiles |\n| enterprise.capabilitycontract | Cross-field side-effect, execution, retry, approval, data, credential, transaction, and compensation rules |\n| profile.mcp.toolslist | Manifest capabilities project to named MCP tools |\n\nThese are implementation checks, not a complete enumeration of\nAIP 1.0 (../spec/AIP-1.0.md). Manifest admission also compares callable\ncapabilities with implementation-support declarations; see the\nconnector contract (../spec/connector-contract.md).\n\nSchema export and schema drift are separate build checks. Use\nJSON schemas (../spec/schemas.md) for the exact 52-file registry and\nvalidation layers.\n\nEvaluate connector conformance\n\nThe shared connector harness returns thirteen checks:\n1. connector.atomicmanifestadmission; and\n2. one connector.behavior. check for each of twelve behavior families.\n\nEvery scenario is requested from the driver. A scenario may report not\napplicable only when the published manifest does not require it.\n\n| Scenario ID | Required when | Required assertions |\n\n| identitycredentials | Any capability is advertised | transportactorbound, tenantisolated, credentialhandleopaque |\n| schemaenforcement | Any capability is advertised | invalidinputrejected, invalidoutputrejected |\n| idempotencyduplicates | Any contract requires idempotency | duplicatesuppressed, collisionrejected, deliveryidstable |\n| retryexhaustion | Any contract supports retry | retryableerrorpreserved, backoffobserved, exhaustiondeadlettered |\n| cancellationraces | Any contract supports cancellation | beforedispatchcancelled, inflightcancelled, latecancelpreservedterminal |\n| streamingbackpressure | Any contract supports streaming | orderedchunks, boundedbackpressure, terminalchunkunique |\n| errorsuncertainoutcomes | Any capability is advertised | protocolfieldspreserved, uncertainoutcomereconciled, errorsecretsredacted |\n| approvallifecycle | Any contract requires approval | authorityverified, quorumenforced, evidencepersisted, resumeonce |\n| transactionlifecycle | Any transaction contract exists | planbeforecommit, provideroperationcheckpointed, reconcilebeforeretry, compensationgoverned |\n| auditredaction | Any capability is advertised | receiptsemitted, auditcorrelated, sensitivefieldsredacted, rawsecretabsent |\n| webhooksecurity | The generic webhook profile is advertised | signatureverified, skewrejected, replayrejected |\n| restartreconnect | Any capability is advertised | staterecovered, duplicateeffectprevented, reconnectcursorresumed |\n\nThe registry contains 38 named assertions. For an executed scenario, every\nrequired name must be present and true, and the evidence must contain at least\none nonempty artifact ID. A missing assertion, false assertion, empty artifact\nlist, or driver error fails that scenario.\n\nThe driver accepts two evidence-source classes:\n• deterministicproviderdouble, which records real connector requests,\n  retries, cancellation, failures, and effects under controlled behavior; or\n• isolatedliveprovider, which exercises a pinned real provider.\n\nStatic booleans returned without executing the connector are not valid release\nevidence. An isolated-live source can support qualification only when the exact\nprovider, artifact, topology, configuration class, timestamps, and raw\nartifacts are also retained.\n\nThe harness is reusable; its existence does not mean every connector invokes\nit or passes every applicable scenario. Check the exact connector result in\nimplementation status (implementation-status.md) and its qualification page.\n\nEvaluate MCP conformance\n\nMCP has seven callable suite entry points. The aggregate rows below overlap;\ndo not add them into one total.\n\n| Suite entry point | Checks at this revision | Scope |\n\n| Golden fixtures | 104 | Every stable method in all four versions against the pinned official schema snapshot |\n| Negative fixtures | 110 | 104 method and parameter mutations plus six cross-cutting malformed-input checks |\n| Profile mapping | 8 | Version matrices, initialize metadata, tool listing, and result projection |\n| External client | 4 | Initialize, tool discovery, optional resource discovery, and AIP manifest projection |\n| Transport codecs | 3 | stdio JSON-RPC, Streamable HTTP POST classification, and SSE round trip |\n| Version-transport server matrix | 56 | Seven lifecycle checks for each of eight executable version-transport pairs |\n| Server aggregate | 61 | Five base server checks plus the 56-check matrix |\n\nThe first three MCP schema snapshots use JSON Schema Draft 7. The\n2025-11-25 snapshot uses Draft 2020-12. Golden fixtures cover 24, 24, 25,\nand 31 stable methods respectively. Unstable methods are not golden fixtures.\n\nCLI client check\n\nRun the external-client subset against Streamable HTTP:\n\ncargo run --locked -q -p getaip-cli -- mcp conformance \\\n  --url http://127.0.0.1:18080/mcp\n\nOr against a command-launched stdio server:\n\ncargo run --locked -q -p getaip-cli -- mcp conformance \\\n  --command ./target/release/getaip-server \\\n  --arg=--mcp-stdio \\\n  --arg=--service-id \\\n  --arg=agent:getaip:server:mcp-conformance\n\nThis command runs only the four external-client checks and returns an error\nwhen any of them fails. Optional resource discovery tolerates an unsupported\nor failed resource list, so it does not prove resource support. The command\ndoes not run golden, negative, profile, codec, server, or all-version matrix\nchecks.\n\nA full MCP claim must name the profile version, transport, peer role, suite\nentry points, expected check IDs, and exact client and server artifacts. Read\ncompatibility profiles (../spec/compatibility-profiles.md) for the supported\nversion and transport matrix.\n\nRecord uncovered profile boundaries\n\nThe reviewed source has no dedicated A2A conformance suite or A2A conformance\nCLI. A2A profile and daemon tests are implementation evidence, not an\nindependent interoperability claim.\n\nThe generic webhook helper exposes one signature-and-skew check. The connector\nharness adds signature, skew, and replay assertions when the webhook profile\nis advertised. Neither check qualifies a provider's raw header mapping or\ndelivery behavior without connector and live evidence.\n\nCore envelope and manifest checks do not exercise every HTTP route, SSE or\nWebSocket recovery path, NATS broker behavior, storage backend, or independent\nclient. There is no single command that establishes conformance for every AIP\nsurface at this revision.\n\nRun the code-owned release gate\n\nThe repository release gate is:\n\ncargo run -p xtask -- release-check\n\nIt executes these source-owned checks in order:\n\n| Gate | Behavior |\n\n| Formatting | cargo fmt --all --check |\n| Dependency boundaries | Product-neutral daemon/fleet boundary and private SDK closure checks |\n| Semantic versioning | Per-package checks against an earlier stable tag when one exists |\n| Schemas | Regenerate the committed AIP schema directory |\n| Lint | Workspace, all targets, all features, warnings denied |\n| Main tests | Workspace all-feature tests through cargo nextest |\n| Minimal features | Workspace tests with no default features |\n| Dependency policy | cargo deny check |\n| Vulnerability audit | cargo audit |\n| Unused dependencies | cargo machete |\n| Fuzz targets | Compile the fuzz workspace |\n| API documentation | Build workspace docs for all features without dependencies |\n\nThe release workflow installs pinned QA tool versions, checks publication\nhygiene, runs this gate, requires no schema diff, and scans full Git history\nfor secrets.\n\nThe gate does not start external products, prove connector credentials, run an\nisolated-live campaign, establish broker or database failover, or qualify a\ntarget deployment's load and fault limits. Attach those campaigns separately\nwhen the release claim requires them.\n\nInterpret a report safely\n\nBoth report types compute success by asking whether every recorded check\npassed. An empty check list therefore also evaluates as successful. Every\nconsumer should assert the expected suite identity, check count, and stable\ncheck IDs before accepting the aggregate status.\n\nUse this interpretation order:\n1. verify artifact, contract, suite, and dependency identities;\n2. verify the expected checks are present exactly once;\n3. reject failed, missing, duplicate, or unexpected required checks;\n4. verify that not-applicable scenarios are permitted by the published\n   contract;\n5. resolve every artifact ID to retained, immutable, redacted evidence;\n6. record limitations and unexecuted external conditions;\n7. publish only the narrow claim supported by those facts.\n\nA green report cannot repair a stale manifest, an unpinned dependency, or a\nmissing scenario.\n\nRetain reproducible evidence\n\nRetain a machine-readable report and raw artifacts without credentials. At\nminimum, include:\n• the subject identities listed above;\n• exact command arguments and relevant tool versions;\n• configuration class and topology without secret values;\n• scenario and check IDs with pass, fail, or not-applicable status;\n• action, transaction, receipt, trace, and provider request IDs when safe;\n• restart, replay, cancellation, approval, reconciliation, and provider\n  observations required by the campaign;\n• start and finish timestamps;\n• raw artifact paths, sizes, and cryptographic digests;\n• known omissions, expected failures, and environmental limits.\n\nCopy published results from the retained report rather than rewriting them\nmanually. A byte-for-byte comparison between the published artifact and the\nretained source prevents accidental status drift.\n\nUse precise claim language\n\n| Say | Only when |\n\n| schema-valid | The named instance passed the stated schema and invariant check |\n| implemented | The behavior exists in the identified source or artifact and deterministic tests cover it |\n| conforming | The exact subject passed the named complete applicable conformance matrix |\n| qualified | The exact artifact and pinned dependencies passed the defined qualification topology and campaign |\n| observed live | A timestamped live run produced retained evidence, but broader qualification is not claimed |\n| production-ready for  | That target's required security, operations, recovery, fault, and capacity campaign passed |\n\nAlways append the scope: profile version, connector, topology, artifact, and\ndate as applicable. Avoid fully supported or all tests passed when the\nstatement omits the exact suite and excluded boundaries.\n\nRelated documentation\n• Implementation status (implementation-status.md)\n• Testing and evidence index (../testing/README.md)\n• Compatibility profiles (../spec/compatibility-profiles.md)\n• Connector contract (../spec/connector-contract.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "1f1259734ddc22fd778bbaa6e4fbab9b5b6d7201f7d66045d145fcd71ac063a1"
  }
}