{
  "schemaVersion": "1.0",
  "title": "Qualify the Cal.diy connector",
  "description": "Use this page to decide whether one exact Cal.diy connector artifact has enough evidence for a bounded release claim. It separates source-defined tests, deterministic provider fixtures, standalone-host behavior, and actual Cal.diy observati",
  "canonical": "https://getaip.org/docs/connectors/cal-diy/qualification",
  "route": "/docs/connectors/cal-diy/qualification",
  "source": "docs/connectors/cal-diy/qualification/README.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/cal-diy/qualification.md",
    "txt": "/docs/download/connectors/cal-diy/qualification.txt",
    "json": "/docs/download/connectors/cal-diy/qualification.json",
    "pdf": "/docs/download/connectors/cal-diy/qualification.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Qualify the Cal.diy connector\ndescription: >-\n  Evaluate deterministic, standalone-host, and isolated-live Cal.diy evidence\n  for one exact connector artifact\nkind: qualification\naudience: evaluator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: cal-diy\n---\n\n# Qualify the Cal.diy connector\n\nUse this page to decide whether one exact Cal.diy connector artifact has enough\nevidence for a bounded release claim. It separates source-defined tests,\ndeterministic provider fixtures, standalone-host behavior, and actual Cal.diy\nobservations so one evidence class cannot substitute for another.\n\n**Current exact-artifact result: not established by this page.** The pinned\nsource contains qualification tests and procedures, but this documentation\nreview did not execute them. The retained isolated-live result is historical,\nuses different AIP source bytes and a bundled topology, and cannot qualify the\ncurrent standalone host.\n\n## Use evidence terms consistently\n\n| Term | Required evidence |\n|---|---|\n| Implemented | The behavior and its contract exist in the identified source |\n| Conformant | The exact artifact passed the applicable conformance scenarios with retained results |\n| Controlled-qualified | The exact artifact passed a named deterministic topology and failure matrix |\n| Isolated-live verified | The exact artifact produced reviewed observations against an identified Cal.diy deployment |\n| Production-observed | Deployment-specific records show the behavior under the stated production boundary |\n\nSource presence proves only implementation. A test function proves that a gate\nexists, not that it passed for the release under review.\n\n## Bind every claim to one identity set\n\nA qualification result is invalid unless its evidence binds all applicable\nvalues:\n\n| Identity class | Required values |\n|---|---|\n| AIP source | Commit, tree or complete dirty-source digest, and clean or dirty status |\n| Connector artifact | Immutable image ID, host component, version, source label, and entrypoint |\n| Contract | Manifest digest, 81-capability catalog digest, schemas, and implementation support map |\n| Cal.diy upstream | Commit, source tree, image ID, database migration set, and relevant API configuration |\n| Harness | Harness source digest, runner image, configuration digest, and test selection |\n| Runtime | Architecture, container engine, database versions, trust policy, and topology |\n| Run | UTC start and end, unique run ID, operator or CI identity, and evidence-root digest |\n\nA mutable tag, branch name, filename, or successful command exit is not an\nartifact identity. If the source was dirty, retain enough bytes to reconstruct\nit; a digest alone distinguishes the input but does not make it reproducible.\n\n## Evaluate four independent gates\n\n| Gate | Source-owned entry point | What it can prove | What it cannot prove |\n|---|---|---|---|\n| Q1: connector contracts | `connector_contract.rs` and `frozen_conformance.rs` | Deterministic connector semantics through public Rust boundaries | Container, fleet, or external Cal.diy behavior |\n| Q2: standalone image | `verify-product-images.sh` | Exact image identity, runtime user and entrypoint, labels, inspect, history, and SBOM | Signature, vulnerability policy, admission, or provider behavior |\n| Q3: controlled fleet | `verify-product-fleet.sh` | Standalone registration, routing, profile operations, fail-closed behavior, and recovery against fixtures | Actual Cal.diy compatibility or all 81 operations |\n| Q4: isolated live | `live_cal_diy.rs` or `examples/cal-diy-qualification/qualify.sh` | Only the operations and topology observed against the identified Cal.diy deployment | Unobserved operations, arbitrary deployment, scale, or production readiness |\n\nRecord a result for each required gate. Q1 cannot replace Q3, and Q3 cannot\nreplace Q4. A release may omit Q4 only when its claim explicitly excludes\nexternal-product verification.\n\n## Review deterministic connector evidence\n\nThe provider-boundary contract suite defines 11 integration tests. Its covered\nboundaries include:\n\n- correlated, versioned booking creation and exact idempotent reuse;\n- collision and ambiguous-provider failure fencing;\n- webhook secret injection, destination binding, and response redaction;\n- path, query, and body partitioning for calendar connection events;\n- schema rejection before dispatch and canonical input hashing;\n- private-link routing, reservation schema closure, and response-size bounds.\n\nThe frozen conformance driver evaluates identity and credentials, schemas,\nidempotency, retry, errors and uncertain outcomes, approvals, transactions,\naudit and redaction, webhook security, and restart or reconnect. Cancellation\nraces and streaming are explicitly not applicable because the published\nCal.diy surface claims neither. The source test requires a passing report with\n13 checks.\n\nRetain the actual test report, exact test binary or build identity, stdout and\nstderr, start and end times, and process status. Do not report the source-level\n13-check assertion as an observed pass when no result artifact exists.\n\nThese tests exercise behavior families and selected routes. They do not prove\nthat every provider path in the 81-operation catalog was invoked.\n\n## Review the standalone image gate\n\nThe source-owned image verifier builds `aip-host-cal-diy` through the allowlisted\ncommon host Dockerfile and executes its help surface under read-only,\ncapability-dropped, no-new-privileges controls. It then requires:\n\n- an immutable `sha256` image ID;\n- runtime user `10001:10001`;\n- entrypoint `/usr/local/bin/aip-connector-host`;\n- exact source-revision, version, and component labels;\n- retained image inspect, full history, and SPDX JSON SBOM artifacts.\n\nReview those artifacts for the Cal.diy image rather than relying on the shared\nsix-host summary. An SBOM is an inventory, not a vulnerability scan, license\ndecision, signature, or provenance attestation. Supply those release controls\nthrough their own evidence roles.\n\n## Review the controlled standalone-fleet gate\n\nThe product-fleet procedure uses deterministic provider fixtures. For Cal.diy,\nthe baseline requires:\n\n- exactly 81 admitted capabilities for the identified connector version;\n- one gateway-routed `cap:cal_diy:profile.get` result;\n- one approval-governed `cap:cal_diy:profile.update` using a stable action ID\n  and idempotency key;\n- provider audit entries for `GET /v2/me` and `PATCH /v2/me`, plus shared audit\n  assertions that authorization and idempotency markers are present;\n- rejection of a deliberately invalid fixture credential.\n\nThe outer matrix also includes the Cal.diy host in graceful restart,\n`SIGKILL`, expired-lease fail-closed, restart recovery, gateway outage, shared\nPostgreSQL outage, and database recovery cases. It captures registry, database,\nimage, process, event, response, stderr, and timestamped log evidence on both\nsuccess and failure.\n\nThis gate exercises two Cal.diy capability IDs against a controlled fixture.\nIt does not exercise the other 79 capability IDs, Cal.diy webhook ingress, a\nreal Cal.diy deployment, provider version drift, or production traffic. Call\nit controlled standalone-fleet qualification, not live Cal.diy qualification.\n\n## Review isolated-live evidence\n\nThe ignored `live_cal_diy.rs` test defines a small reversible gate against an\noperator-supplied deployment. It checks authenticated health, creates one\nfuture slot reservation, repeats the same key and compares the stored result,\nthen deletes the reservation with a new key. Because the test is ignored and\nenvironment-gated, it contributes no result until an exact run is retained.\n\nThe larger source-owned campaign under `examples/cal-diy-qualification`\ndeploys an actual pinned self-hosted Cal.diy revision and exercises discovery,\navailability, booking plan and approval, one booking, idempotent replay,\nwebhook cases, and restart recovery. Its AIP component uses the legacy bundled\ndaemon, not `aip-host-cal-diy`. A new standalone-host release claim therefore\nneeds a new live campaign through the fleet topology.\n\nFor every live campaign, prove that the provider is the identified Cal.diy\nsource and image, not a deterministic fixture with compatible routes. Use\nreversible future-dated data, dedicated accounts, independent requester and\napprover identities, isolated networks, and a verified cleanup record.\n\n## Interpret the historical result narrowly\n\nThe retained 13 July 2026 JSON result records historical status `passed`. Its\nbytes have SHA-256 digest\n`507c2136aa695a5e34efddd6fe5dc6b50e46de7d898c5ad39c3d5f7ebbbb82b3`.\nIt identifies an actual Cal.diy commit and image and retains observations for\n81-capability admission, availability, approval-governed booking, one-effect\nidempotent replay, webhook authentication and duplicate handling, and restart\nrecovery.\n\nThat result does not apply to the current source revision because:\n\n- its AIP build used a different base commit plus uncommitted source identified\n  only by digest;\n- the unavailable changed bytes prevent exact reconstruction;\n- its AIP topology was the bundled daemon rather than the standalone host;\n- its retained artifact lacks the current standard's cleanup evidence;\n- it observed only the campaign's selected capability paths.\n\nPreserve the historical label and date. Do not rewrite it as a current pass.\nThe full identity and limitation record belongs to\n[Cal.diy isolated-live qualification](../../../testing/cal-diy-isolated-live.md).\n\n## Account for all 81 capabilities\n\nMaintain one generated or machine-validated coverage row per published\ncapability:\n\n| Field | Required value |\n|---|---|\n| Capability ID | Exact admitted identifier |\n| Contract evidence | Schema, method, API version, route, risk, approval, retry, and transaction mapping |\n| Deterministic evidence | Test case and result artifact, or explicit gap |\n| Standalone-fleet evidence | Case and artifact, or `not_run` |\n| Isolated-live evidence | Provider revision, case and artifact, or `not_run` |\n| Failure evidence | Auth, validation, rejection, uncertainty, replay, or recovery cases exercised |\n| Side-effect control | Idempotency, approval, plan and commit, compensation, and cleanup as applicable |\n| Review decision | Accepted scope, limitation, owner, and review time |\n\nEvery row needs contract evidence. Live mutation of all 81 operations is not a\ndefault requirement and may be unsafe. Select reversible live cases by unique\nrisk, transport, state, idempotency, approval, and provider behavior, then\npublish every unobserved capability as a gap. Never turn sampling into an\nall-capabilities-live claim.\n\n## Retain a complete evidence set\n\nA new qualification record should contain:\n\n1. immutable source, image, manifest, upstream, harness, dependency, topology,\n   and run identities;\n2. a gate manifest naming every required case and its expected invariant;\n3. raw exit records plus structured per-case results and redacted stderr;\n4. captured admission, catalog, implementation-support, and route snapshots;\n5. image inspect, history, SBOM, and separate supply-chain evidence;\n6. provider request and audit correlations without credentials or raw personal\n   data;\n7. durable action, approval, transaction, idempotency, reconciliation,\n   lifecycle, event, and webhook observations where applicable;\n8. failure and recovery ordering, including container and database events;\n9. a generated 81-row capability coverage matrix;\n10. checksums for every retained artifact and one evidence-root checksum;\n11. verified cleanup, residual-resource inventory, and any retained exception;\n12. a final summary that states scope, result, exclusions, reviewer, and time.\n\nA summary file's presence is not a pass. Review all referenced artifacts and\nensure no earlier failure was hidden by later recovery.\n\n## Assign results without ambiguity\n\n| Result | Use when |\n|---|---|\n| `passed` | Every required invariant passed for the exact identity set, artifacts are complete and redacted, gaps match the claim, and cleanup was verified |\n| `failed` | Any required invariant failed, identity mismatched, evidence was corrupted or leaked, or cleanup violated the campaign contract |\n| `blocked` | A required dependency or authority was unavailable before the invariant could be evaluated |\n| `not_run` | The gate was not executed for this identity set |\n| `historical` | A prior result is retained for a different source, artifact, topology, or evidence standard |\n\nDo not collapse `blocked`, `not_run`, or `historical` into `passed`. A gate can\npass while the broader release claim remains unestablished.\n\n## Publish only the supported claim\n\nAcceptable result language names the evidence boundary:\n\n> At the recorded time, the identified AIP and Cal.diy artifacts passed the\n> listed deterministic, standalone-fleet, and selected isolated-live cases in\n> the retained topology. The coverage matrix lists all unobserved capabilities\n> and excluded production properties.\n\nDo not publish `fully compatible`, `all 81 operations live verified`,\n`exactly-once`, or `production-ready` unless the retained campaign defines and\nproves each phrase under the stated deployment.\n\n## Reviewer checklist\n\n- [ ] Every source, artifact, manifest, upstream, harness, and run identity is\n  immutable and mutually consistent.\n- [ ] Required gates are explicit; no fixture result is labeled live.\n- [ ] The 81-row coverage matrix matches the admitted catalog.\n- [ ] Deterministic reports and standalone-fleet failure evidence are complete.\n- [ ] Live evidence names the real Cal.diy revision, topology, data, and\n  reversible cleanup.\n- [ ] Mutation results include approval, idempotency, provider effect, and\n  uncertainty or reconciliation evidence.\n- [ ] Image inventory is not presented as signature, scan, or provenance.\n- [ ] Artifacts are redacted, checksummed, access-controlled, and retained for\n  the claim lifetime.\n- [ ] Cleanup and residual resources are independently recorded.\n- [ ] The final wording states time, scope, result, gaps, and exclusions.\n\n## Related documentation\n\n- [Conformance and qualification](../../../reference/conformance.md)\n- [Connector fleet qualification](../../../testing/connector-fleet-qualification.md)\n- [Live-product qualification](../../../testing/live-product-e2e.md)\n- [Cal.diy capability index](../capabilities/README.md)\n- [Release artifacts and verification](../../../reference/release-artifacts.md)\n",
    "text": "Qualify the Cal.diy connector\n\nUse this page to decide whether one exact Cal.diy connector artifact has enough\nevidence for a bounded release claim. It separates source-defined tests,\ndeterministic provider fixtures, standalone-host behavior, and actual Cal.diy\nobservations so one evidence class cannot substitute for another.\n\nCurrent exact-artifact result: not established by this page. The pinned\nsource contains qualification tests and procedures, but this documentation\nreview did not execute them. The retained isolated-live result is historical,\nuses different AIP source bytes and a bundled topology, and cannot qualify the\ncurrent standalone host.\n\nUse evidence terms consistently\n\n| Term | Required evidence |\n\n| Implemented | The behavior and its contract exist in the identified source |\n| Conformant | The exact artifact passed the applicable conformance scenarios with retained results |\n| Controlled-qualified | The exact artifact passed a named deterministic topology and failure matrix |\n| Isolated-live verified | The exact artifact produced reviewed observations against an identified Cal.diy deployment |\n| Production-observed | Deployment-specific records show the behavior under the stated production boundary |\n\nSource presence proves only implementation. A test function proves that a gate\nexists, not that it passed for the release under review.\n\nBind every claim to one identity set\n\nA qualification result is invalid unless its evidence binds all applicable\nvalues:\n\n| Identity class | Required values |\n\n| AIP source | Commit, tree or complete dirty-source digest, and clean or dirty status |\n| Connector artifact | Immutable image ID, host component, version, source label, and entrypoint |\n| Contract | Manifest digest, 81-capability catalog digest, schemas, and implementation support map |\n| Cal.diy upstream | Commit, source tree, image ID, database migration set, and relevant API configuration |\n| Harness | Harness source digest, runner image, configuration digest, and test selection |\n| Runtime | Architecture, container engine, database versions, trust policy, and topology |\n| Run | UTC start and end, unique run ID, operator or CI identity, and evidence-root digest |\n\nA mutable tag, branch name, filename, or successful command exit is not an\nartifact identity. If the source was dirty, retain enough bytes to reconstruct\nit; a digest alone distinguishes the input but does not make it reproducible.\n\nEvaluate four independent gates\n\n| Gate | Source-owned entry point | What it can prove | What it cannot prove |\n\n| Q1: connector contracts | connectorcontract.rs and frozenconformance.rs | Deterministic connector semantics through public Rust boundaries | Container, fleet, or external Cal.diy behavior |\n| Q2: standalone image | verify-product-images.sh | Exact image identity, runtime user and entrypoint, labels, inspect, history, and SBOM | Signature, vulnerability policy, admission, or provider behavior |\n| Q3: controlled fleet | verify-product-fleet.sh | Standalone registration, routing, profile operations, fail-closed behavior, and recovery against fixtures | Actual Cal.diy compatibility or all 81 operations |\n| Q4: isolated live | livecaldiy.rs or examples/cal-diy-qualification/qualify.sh | Only the operations and topology observed against the identified Cal.diy deployment | Unobserved operations, arbitrary deployment, scale, or production readiness |\n\nRecord a result for each required gate. Q1 cannot replace Q3, and Q3 cannot\nreplace Q4. A release may omit Q4 only when its claim explicitly excludes\nexternal-product verification.\n\nReview deterministic connector evidence\n\nThe provider-boundary contract suite defines 11 integration tests. Its covered\nboundaries include:\n• correlated, versioned booking creation and exact idempotent reuse;\n• collision and ambiguous-provider failure fencing;\n• webhook secret injection, destination binding, and response redaction;\n• path, query, and body partitioning for calendar connection events;\n• schema rejection before dispatch and canonical input hashing;\n• private-link routing, reservation schema closure, and response-size bounds.\n\nThe frozen conformance driver evaluates identity and credentials, schemas,\nidempotency, retry, errors and uncertain outcomes, approvals, transactions,\naudit and redaction, webhook security, and restart or reconnect. Cancellation\nraces and streaming are explicitly not applicable because the published\nCal.diy surface claims neither. The source test requires a passing report with\n13 checks.\n\nRetain the actual test report, exact test binary or build identity, stdout and\nstderr, start and end times, and process status. Do not report the source-level\n13-check assertion as an observed pass when no result artifact exists.\n\nThese tests exercise behavior families and selected routes. They do not prove\nthat every provider path in the 81-operation catalog was invoked.\n\nReview the standalone image gate\n\nThe source-owned image verifier builds aip-host-cal-diy through the allowlisted\ncommon host Dockerfile and executes its help surface under read-only,\ncapability-dropped, no-new-privileges controls. It then requires:\n• an immutable sha256 image ID;\n• runtime user 10001:10001;\n• entrypoint /usr/local/bin/aip-connector-host;\n• exact source-revision, version, and component labels;\n• retained image inspect, full history, and SPDX JSON SBOM artifacts.\n\nReview those artifacts for the Cal.diy image rather than relying on the shared\nsix-host summary. An SBOM is an inventory, not a vulnerability scan, license\ndecision, signature, or provenance attestation. Supply those release controls\nthrough their own evidence roles.\n\nReview the controlled standalone-fleet gate\n\nThe product-fleet procedure uses deterministic provider fixtures. For Cal.diy,\nthe baseline requires:\n• exactly 81 admitted capabilities for the identified connector version;\n• one gateway-routed cap:caldiy:profile.get result;\n• one approval-governed cap:caldiy:profile.update using a stable action ID\n  and idempotency key;\n• provider audit entries for GET /v2/me and PATCH /v2/me, plus shared audit\n  assertions that authorization and idempotency markers are present;\n• rejection of a deliberately invalid fixture credential.\n\nThe outer matrix also includes the Cal.diy host in graceful restart,\nSIGKILL, expired-lease fail-closed, restart recovery, gateway outage, shared\nPostgreSQL outage, and database recovery cases. It captures registry, database,\nimage, process, event, response, stderr, and timestamped log evidence on both\nsuccess and failure.\n\nThis gate exercises two Cal.diy capability IDs against a controlled fixture.\nIt does not exercise the other 79 capability IDs, Cal.diy webhook ingress, a\nreal Cal.diy deployment, provider version drift, or production traffic. Call\nit controlled standalone-fleet qualification, not live Cal.diy qualification.\n\nReview isolated-live evidence\n\nThe ignored livecaldiy.rs test defines a small reversible gate against an\noperator-supplied deployment. It checks authenticated health, creates one\nfuture slot reservation, repeats the same key and compares the stored result,\nthen deletes the reservation with a new key. Because the test is ignored and\nenvironment-gated, it contributes no result until an exact run is retained.\n\nThe larger source-owned campaign under examples/cal-diy-qualification\ndeploys an actual pinned self-hosted Cal.diy revision and exercises discovery,\navailability, booking plan and approval, one booking, idempotent replay,\nwebhook cases, and restart recovery. Its AIP component uses the legacy bundled\ndaemon, not aip-host-cal-diy. A new standalone-host release claim therefore\nneeds a new live campaign through the fleet topology.\n\nFor every live campaign, prove that the provider is the identified Cal.diy\nsource and image, not a deterministic fixture with compatible routes. Use\nreversible future-dated data, dedicated accounts, independent requester and\napprover identities, isolated networks, and a verified cleanup record.\n\nInterpret the historical result narrowly\n\nThe retained 13 July 2026 JSON result records historical status passed. Its\nbytes have SHA-256 digest\n507c2136aa695a5e34efddd6fe5dc6b50e46de7d898c5ad39c3d5f7ebbbb82b3.\nIt identifies an actual Cal.diy commit and image and retains observations for\n81-capability admission, availability, approval-governed booking, one-effect\nidempotent replay, webhook authentication and duplicate handling, and restart\nrecovery.\n\nThat result does not apply to the current source revision because:\n• its AIP build used a different base commit plus uncommitted source identified\n  only by digest;\n• the unavailable changed bytes prevent exact reconstruction;\n• its AIP topology was the bundled daemon rather than the standalone host;\n• its retained artifact lacks the current standard's cleanup evidence;\n• it observed only the campaign's selected capability paths.\n\nPreserve the historical label and date. Do not rewrite it as a current pass.\nThe full identity and limitation record belongs to\nCal.diy isolated-live qualification (../../../testing/cal-diy-isolated-live.md).\n\nAccount for all 81 capabilities\n\nMaintain one generated or machine-validated coverage row per published\ncapability:\n\n| Field | Required value |\n\n| Capability ID | Exact admitted identifier |\n| Contract evidence | Schema, method, API version, route, risk, approval, retry, and transaction mapping |\n| Deterministic evidence | Test case and result artifact, or explicit gap |\n| Standalone-fleet evidence | Case and artifact, or notrun |\n| Isolated-live evidence | Provider revision, case and artifact, or notrun |\n| Failure evidence | Auth, validation, rejection, uncertainty, replay, or recovery cases exercised |\n| Side-effect control | Idempotency, approval, plan and commit, compensation, and cleanup as applicable |\n| Review decision | Accepted scope, limitation, owner, and review time |\n\nEvery row needs contract evidence. Live mutation of all 81 operations is not a\ndefault requirement and may be unsafe. Select reversible live cases by unique\nrisk, transport, state, idempotency, approval, and provider behavior, then\npublish every unobserved capability as a gap. Never turn sampling into an\nall-capabilities-live claim.\n\nRetain a complete evidence set\n\nA new qualification record should contain:\n1. immutable source, image, manifest, upstream, harness, dependency, topology,\n   and run identities;\n2. a gate manifest naming every required case and its expected invariant;\n3. raw exit records plus structured per-case results and redacted stderr;\n4. captured admission, catalog, implementation-support, and route snapshots;\n5. image inspect, history, SBOM, and separate supply-chain evidence;\n6. provider request and audit correlations without credentials or raw personal\n   data;\n7. durable action, approval, transaction, idempotency, reconciliation,\n   lifecycle, event, and webhook observations where applicable;\n8. failure and recovery ordering, including container and database events;\n9. a generated 81-row capability coverage matrix;\n10. checksums for every retained artifact and one evidence-root checksum;\n11. verified cleanup, residual-resource inventory, and any retained exception;\n12. a final summary that states scope, result, exclusions, reviewer, and time.\n\nA summary file's presence is not a pass. Review all referenced artifacts and\nensure no earlier failure was hidden by later recovery.\n\nAssign results without ambiguity\n\n| Result | Use when |\n\n| passed | Every required invariant passed for the exact identity set, artifacts are complete and redacted, gaps match the claim, and cleanup was verified |\n| failed | Any required invariant failed, identity mismatched, evidence was corrupted or leaked, or cleanup violated the campaign contract |\n| blocked | A required dependency or authority was unavailable before the invariant could be evaluated |\n| notrun | The gate was not executed for this identity set |\n| historical | A prior result is retained for a different source, artifact, topology, or evidence standard |\n\nDo not collapse blocked, notrun, or historical into passed. A gate can\npass while the broader release claim remains unestablished.\n\nPublish only the supported claim\n\nAcceptable result language names the evidence boundary:\n\nAt the recorded time, the identified AIP and Cal.diy artifacts passed the\nlisted deterministic, standalone-fleet, and selected isolated-live cases in\nthe retained topology. The coverage matrix lists all unobserved capabilities\nand excluded production properties.\n\nDo not publish fully compatible, all 81 operations live verified,\nexactly-once, or production-ready unless the retained campaign defines and\nproves each phrase under the stated deployment.\n\nReviewer checklist\n• [ ] Every source, artifact, manifest, upstream, harness, and run identity is\n  immutable and mutually consistent.\n• [ ] Required gates are explicit; no fixture result is labeled live.\n• [ ] The 81-row coverage matrix matches the admitted catalog.\n• [ ] Deterministic reports and standalone-fleet failure evidence are complete.\n• [ ] Live evidence names the real Cal.diy revision, topology, data, and\n  reversible cleanup.\n• [ ] Mutation results include approval, idempotency, provider effect, and\n  uncertainty or reconciliation evidence.\n• [ ] Image inventory is not presented as signature, scan, or provenance.\n• [ ] Artifacts are redacted, checksummed, access-controlled, and retained for\n  the claim lifetime.\n• [ ] Cleanup and residual resources are independently recorded.\n• [ ] The final wording states time, scope, result, gaps, and exclusions.\n\nRelated documentation\n• Conformance and qualification (../../../reference/conformance.md)\n• Connector fleet qualification (../../../testing/connector-fleet-qualification.md)\n• Live-product qualification (../../../testing/live-product-e2e.md)\n• Cal.diy capability index (../capabilities/README.md)\n• Release artifacts and verification (../../../reference/release-artifacts.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "22705c02f8db369b882fa1cde30e061704590124bb57635f495acfff71627018"
  }
}