{
  "schemaVersion": "1.0",
  "title": "Qualify the Chatwoot connector",
  "description": "Use this page to decide whether one exact Chatwoot connector artifact supports a bounded release claim. It keeps source-defined tests, standalone-image checks, controlled provider fixtures, and actual Chatwoot observations as separate evide",
  "canonical": "https://getaip.org/docs/connectors/chatwoot/qualification",
  "route": "/docs/connectors/chatwoot/qualification",
  "source": "docs/connectors/chatwoot/qualification/README.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/chatwoot/qualification.md",
    "txt": "/docs/download/connectors/chatwoot/qualification.txt",
    "json": "/docs/download/connectors/chatwoot/qualification.json",
    "pdf": "/docs/download/connectors/chatwoot/qualification.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Qualify the Chatwoot connector\ndescription: >-\n  Evaluate connector, standalone-image, controlled-fleet, and live-provider\n  evidence for one exact Chatwoot connector artifact\nkind: qualification\naudience: evaluator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: chatwoot\n---\n\n# Qualify the Chatwoot connector\n\nUse this page to decide whether one exact Chatwoot connector artifact supports\na bounded release claim. It keeps source-defined tests, standalone-image\nchecks, controlled provider fixtures, and actual Chatwoot observations as\nseparate evidence classes.\n\n**Current exact-artifact result: not established by this page.** The reviewed\nsource defines qualification gates, but this documentation review did not run\nthem. No retained isolated-live Chatwoot result for the current standalone host\nwas found in the pinned tree.\n\n## Use evidence terms consistently\n\n| Term | Required evidence |\n|---|---|\n| Implemented | The behavior and contract exist in identified source |\n| Conformant | The exact artifact passed 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 identified Chatwoot artifacts |\n| Production-observed | Deployment records show the behavior under a stated production boundary |\n\nA test function proves that a gate exists. It does not prove that the gate ran\nor passed for the artifact under review.\n\n## Bind the claim to one identity set\n\nEvery result must bind the identities that can change its meaning:\n\n| Identity class | Required values |\n|---|---|\n| AIP source | Commit, tree or complete dirty-source snapshot, and clean or dirty status |\n| Connector artifact | Immutable image ID, component, version, source label, entrypoint, and architecture |\n| Contract | Manifest digest, 153-capability catalogue digest, schemas, and implementation-support map |\n| Chatwoot upstream | Commit `8818d276b954ac4f84cffd8915c99f40e43804ed`, tree or image, migrations, and API configuration |\n| Harness | Source digest, runner image, configuration digest, and selected cases |\n| Runtime | Container engine, databases, trust policy, account, and network topology |\n| Run | UTC interval, unique run ID, evaluator identity, and evidence-root digest |\n\nThe reviewed AIP commit is\n`97be86e9efedf07ecf1783b03800f683f107fb04`, with Git tree\n`2d83a382a312c601ecbbf5ed03f8af2b0218bdae`. These source identities do\nnot identify a built image or a completed run. A mutable tag, branch, or\nfilename is not an artifact identity.\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 | Focused tests in `aip-connector-chatwoot` | Deterministic connector semantics through public Rust boundaries | Container, fleet, or external Chatwoot behavior |\n| Q2: standalone image | `verify-product-images.sh` | Image identity, runtime user, entrypoint, labels, inspect, history, and SBOM | Provider compatibility, signature, vulnerability policy, or admission |\n| Q3: controlled product fleet | `run-product-qualification.sh` and `verify-product-fleet.sh` | Admission, selected operations, policy, isolation, fail-closed behavior, and recovery against fixtures | Actual Chatwoot compatibility or all capabilities |\n| Q4: isolated live | A reviewed campaign manifest and harness | Selected behavior against identified Chatwoot artifacts | Arbitrary deployments, every capability, scale, or production readiness |\n\nRecord a result for every gate required by the claim. A deterministic fixture\ncannot substitute for actual Chatwoot, and a provider observation cannot\nsubstitute for host admission or failure recovery.\n\n## Review focused connector evidence\n\nThe pinned connector crate contains nine focused tests. Together they cover:\n\n- outbound message authentication and Action identity propagation;\n- webhook signature verification, loop prevention, and deterministic duplicate\n  reconstruction after connector restart;\n- conservative retry contracts for non-idempotent mutations;\n- uniqueness and governance for 150 catalogue operations;\n- manifest bindings for all three composites and catalogue capabilities;\n- mutation path, body, authorization, and idempotency projection;\n- bounded multipart upload and allowed-operation filtering;\n- credential redaction from connector debug output.\n\nRetain the exact test selection, binary or build identity, process status,\ntimestamps, structured results, and redacted diagnostics. The source functions\nalone are implementation evidence. They are not an observed pass.\n\nThese focused tests do not form a complete frozen-conformance report. A release\nclaim that requires cross-connector conformance must retain the applicable\nglobal suite separately.\n\n## Review the standalone image gate\n\nThe image verifier builds `aip-host-chatwoot` with the common host Dockerfile.\nIt requires an immutable image ID, runtime user `10001:10001`, entrypoint\n`/usr/local/bin/aip-connector-host`, exact component labels, image inspect,\nfull history, and an SPDX JSON SBOM.\n\nReview the Chatwoot-specific artifacts rather than relying on a shared summary.\nAn SBOM is an inventory. It is not an image signature, vulnerability decision,\nlicense decision, provenance attestation, or provider qualification.\n\n## Review the controlled product-fleet gate\n\nThe controlled fixture publishes 153 Chatwoot capabilities: three AIP\ncomposites and 150 upstream-pinned account operations. The selected positive\ncases require:\n\n- `cap:chatwoot:account.get` and `cap:chatwoot:agent.list` through the gateway;\n- approval-governed `cap:chatwoot:conversation.create` with stable Action and\n  idempotency identities;\n- fixture audit entries for account read and conversation creation;\n- authorization and idempotency markers at the fixture boundary;\n- exclusion of `cap:chatwoot:account.get` from an unrelated tenant catalogue.\n\nThe fleet verifier also requires an independently owned Chatwoot runtime\ndatabase with all five runtime tables. It includes graceful restart, `SIGKILL`\nand expired-lease fail-closed recovery, dual-gateway failover, shared\nPostgreSQL outage and recovery, and final ready-lease checks.\n\nThis gate exercises three capability IDs against a deterministic provider\nfixture. It does not exercise the other 150 IDs, webhook ingress, multipart\nuploads, a real Chatwoot deployment, provider-version drift, or production\ntraffic. Label it controlled product-fleet qualification.\n\n## Define an isolated-live gate before running it\n\nThe pinned tree does not contain a source-owned isolated-live Chatwoot campaign\nor a retained current result. A new gate should use a dedicated account,\nreversible data, independent requester and approver identities, isolated\ncredentials, and explicit cleanup.\n\nSelect cases by distinct risk and transport behavior rather than operation\ncount. A bounded campaign should include authenticated account discovery, one\nread, one approval-governed mutation, same-key replay, one deliberate\nidempotency collision, authenticated webhook delivery, duplicate delivery,\nloop prevention, provider rejection, uncertain mutation handling, restart,\nand storage recovery.\n\nRecord the provider resource before and after each mutation. One successful\nHTTP exchange is insufficient when the provider effect, Action result, local\nEvent, and central Event delivery are separate boundaries.\n\n## Account for all 153 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 | Method, route, schemas, risk, approval, retry, and idempotency mapping |\n| Deterministic evidence | Test and result artifact, or an explicit gap |\n| Controlled-fleet evidence | Case and artifact, or `not_run` |\n| Isolated-live evidence | Provider identity, case, and artifact, or `not_run` |\n| Failure evidence | Auth, validation, rejection, uncertainty, replay, and recovery cases exercised |\n| Side-effect control | Approval, idempotency, provider-state check, and cleanup as applicable |\n| Review decision | Accepted scope, limitation, owner, reviewer, and time |\n\nEvery row needs contract evidence. Live mutation of all 90 mutation\ncapabilities is not a default requirement and may be unsafe. Select reversible\nlive cases by unique behavior, then publish every unobserved capability as a\ngap.\n\n## Retain a complete evidence set\n\nA qualification record should contain:\n\n1. immutable AIP, image, manifest, schema, Chatwoot, harness, dependency,\n   topology, and run identities;\n2. a gate manifest naming every required case and invariant;\n3. raw exits, structured per-case results, and redacted diagnostics;\n4. admission, catalogue, implementation-support, route, and lease snapshots;\n5. image inspect, history, SBOM, and separate supply-chain decisions;\n6. provider request and audit correlations without tokens or personal data;\n7. durable Action, approval, idempotency, webhook, Event, and outbox evidence;\n8. failure and recovery ordering for process, lease, database, and provider;\n9. a generated 153-row capability coverage matrix;\n10. checksums for every artifact and one evidence-root checksum;\n11. verified cleanup, residual-resource inventory, and retained exceptions;\n12. a summary stating scope, result, exclusions, reviewer, and UTC time.\n\nA summary file is not a pass by itself. Review every referenced artifact and\nensure later recovery did not hide an earlier failed invariant.\n\n## Assign an unambiguous result\n\n| Result | Use when |\n|---|---|\n| `passed` | Every required invariant passed for the exact identity set, artifacts are complete, and gaps match the claim |\n| `failed` | A required invariant failed, identity mismatched, evidence leaked or was corrupted, or cleanup failed |\n| `blocked` | A required dependency or authority was unavailable before evaluation |\n| `not_run` | The gate was not executed for this identity set |\n| `historical` | A retained result belongs to a different source, artifact, topology, or evidence standard |\n\nDo not collapse `blocked`, `not_run`, or `historical` into `passed`. One gate\ncan pass while a broader release claim remains unestablished.\n\n## Publish only the supported claim\n\nAcceptable wording binds the result to its evidence:\n\n> At the recorded time, the identified AIP and Chatwoot connector artifacts\n> passed the listed deterministic and controlled-fleet cases in the retained\n> topology. The coverage matrix identifies every unobserved capability and\n> excludes live-provider and production properties.\n\nDo not publish `fully compatible`, `all 153 capabilities live verified`,\n`exactly once`, or `production-ready` unless the retained campaign defines and\nproves each phrase.\n\n## Reviewer checklist\n\n- [ ] Source, image, manifest, upstream, harness, topology, and run identities\n  are immutable and mutually consistent.\n- [ ] Required gates are explicit and no fixture result is labeled live.\n- [ ] The 153-row coverage matrix matches the admitted catalogue.\n- [ ] Connector, image, and controlled-fleet results are retained and redacted.\n- [ ] Mutation evidence binds approval, idempotency, provider effect, Action\n  state, and uncertainty decisions.\n- [ ] Webhook evidence separates authentication, replay, local Event storage,\n  and central publication.\n- [ ] Image inventory is not presented as signature, scan, or provenance.\n- [ ] Cleanup and residual resources are independently recorded.\n- [ ] 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- [Chatwoot capability index](../capabilities/README.md)\n- [Release artifacts and verification](../../../reference/release-artifacts.md)\n",
    "text": "Qualify the Chatwoot connector\n\nUse this page to decide whether one exact Chatwoot connector artifact supports\na bounded release claim. It keeps source-defined tests, standalone-image\nchecks, controlled provider fixtures, and actual Chatwoot observations as\nseparate evidence classes.\n\nCurrent exact-artifact result: not established by this page. The reviewed\nsource defines qualification gates, but this documentation review did not run\nthem. No retained isolated-live Chatwoot result for the current standalone host\nwas found in the pinned tree.\n\nUse evidence terms consistently\n\n| Term | Required evidence |\n\n| Implemented | The behavior and contract exist in identified source |\n| Conformant | The exact artifact passed 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 identified Chatwoot artifacts |\n| Production-observed | Deployment records show the behavior under a stated production boundary |\n\nA test function proves that a gate exists. It does not prove that the gate ran\nor passed for the artifact under review.\n\nBind the claim to one identity set\n\nEvery result must bind the identities that can change its meaning:\n\n| Identity class | Required values |\n\n| AIP source | Commit, tree or complete dirty-source snapshot, and clean or dirty status |\n| Connector artifact | Immutable image ID, component, version, source label, entrypoint, and architecture |\n| Contract | Manifest digest, 153-capability catalogue digest, schemas, and implementation-support map |\n| Chatwoot upstream | Commit 8818d276b954ac4f84cffd8915c99f40e43804ed, tree or image, migrations, and API configuration |\n| Harness | Source digest, runner image, configuration digest, and selected cases |\n| Runtime | Container engine, databases, trust policy, account, and network topology |\n| Run | UTC interval, unique run ID, evaluator identity, and evidence-root digest |\n\nThe reviewed AIP commit is\n97be86e9efedf07ecf1783b03800f683f107fb04, with Git tree\n2d83a382a312c601ecbbf5ed03f8af2b0218bdae. These source identities do\nnot identify a built image or a completed run. A mutable tag, branch, or\nfilename is not an artifact identity.\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 | Focused tests in aip-connector-chatwoot | Deterministic connector semantics through public Rust boundaries | Container, fleet, or external Chatwoot behavior |\n| Q2: standalone image | verify-product-images.sh | Image identity, runtime user, entrypoint, labels, inspect, history, and SBOM | Provider compatibility, signature, vulnerability policy, or admission |\n| Q3: controlled product fleet | run-product-qualification.sh and verify-product-fleet.sh | Admission, selected operations, policy, isolation, fail-closed behavior, and recovery against fixtures | Actual Chatwoot compatibility or all capabilities |\n| Q4: isolated live | A reviewed campaign manifest and harness | Selected behavior against identified Chatwoot artifacts | Arbitrary deployments, every capability, scale, or production readiness |\n\nRecord a result for every gate required by the claim. A deterministic fixture\ncannot substitute for actual Chatwoot, and a provider observation cannot\nsubstitute for host admission or failure recovery.\n\nReview focused connector evidence\n\nThe pinned connector crate contains nine focused tests. Together they cover:\n• outbound message authentication and Action identity propagation;\n• webhook signature verification, loop prevention, and deterministic duplicate\n  reconstruction after connector restart;\n• conservative retry contracts for non-idempotent mutations;\n• uniqueness and governance for 150 catalogue operations;\n• manifest bindings for all three composites and catalogue capabilities;\n• mutation path, body, authorization, and idempotency projection;\n• bounded multipart upload and allowed-operation filtering;\n• credential redaction from connector debug output.\n\nRetain the exact test selection, binary or build identity, process status,\ntimestamps, structured results, and redacted diagnostics. The source functions\nalone are implementation evidence. They are not an observed pass.\n\nThese focused tests do not form a complete frozen-conformance report. A release\nclaim that requires cross-connector conformance must retain the applicable\nglobal suite separately.\n\nReview the standalone image gate\n\nThe image verifier builds aip-host-chatwoot with the common host Dockerfile.\nIt requires an immutable image ID, runtime user 10001:10001, entrypoint\n/usr/local/bin/aip-connector-host, exact component labels, image inspect,\nfull history, and an SPDX JSON SBOM.\n\nReview the Chatwoot-specific artifacts rather than relying on a shared summary.\nAn SBOM is an inventory. It is not an image signature, vulnerability decision,\nlicense decision, provenance attestation, or provider qualification.\n\nReview the controlled product-fleet gate\n\nThe controlled fixture publishes 153 Chatwoot capabilities: three AIP\ncomposites and 150 upstream-pinned account operations. The selected positive\ncases require:\n• cap:chatwoot:account.get and cap:chatwoot:agent.list through the gateway;\n• approval-governed cap:chatwoot:conversation.create with stable Action and\n  idempotency identities;\n• fixture audit entries for account read and conversation creation;\n• authorization and idempotency markers at the fixture boundary;\n• exclusion of cap:chatwoot:account.get from an unrelated tenant catalogue.\n\nThe fleet verifier also requires an independently owned Chatwoot runtime\ndatabase with all five runtime tables. It includes graceful restart, SIGKILL\nand expired-lease fail-closed recovery, dual-gateway failover, shared\nPostgreSQL outage and recovery, and final ready-lease checks.\n\nThis gate exercises three capability IDs against a deterministic provider\nfixture. It does not exercise the other 150 IDs, webhook ingress, multipart\nuploads, a real Chatwoot deployment, provider-version drift, or production\ntraffic. Label it controlled product-fleet qualification.\n\nDefine an isolated-live gate before running it\n\nThe pinned tree does not contain a source-owned isolated-live Chatwoot campaign\nor a retained current result. A new gate should use a dedicated account,\nreversible data, independent requester and approver identities, isolated\ncredentials, and explicit cleanup.\n\nSelect cases by distinct risk and transport behavior rather than operation\ncount. A bounded campaign should include authenticated account discovery, one\nread, one approval-governed mutation, same-key replay, one deliberate\nidempotency collision, authenticated webhook delivery, duplicate delivery,\nloop prevention, provider rejection, uncertain mutation handling, restart,\nand storage recovery.\n\nRecord the provider resource before and after each mutation. One successful\nHTTP exchange is insufficient when the provider effect, Action result, local\nEvent, and central Event delivery are separate boundaries.\n\nAccount for all 153 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 | Method, route, schemas, risk, approval, retry, and idempotency mapping |\n| Deterministic evidence | Test and result artifact, or an explicit gap |\n| Controlled-fleet evidence | Case and artifact, or notrun |\n| Isolated-live evidence | Provider identity, case, and artifact, or notrun |\n| Failure evidence | Auth, validation, rejection, uncertainty, replay, and recovery cases exercised |\n| Side-effect control | Approval, idempotency, provider-state check, and cleanup as applicable |\n| Review decision | Accepted scope, limitation, owner, reviewer, and time |\n\nEvery row needs contract evidence. Live mutation of all 90 mutation\ncapabilities is not a default requirement and may be unsafe. Select reversible\nlive cases by unique behavior, then publish every unobserved capability as a\ngap.\n\nRetain a complete evidence set\n\nA qualification record should contain:\n1. immutable AIP, image, manifest, schema, Chatwoot, harness, dependency,\n   topology, and run identities;\n2. a gate manifest naming every required case and invariant;\n3. raw exits, structured per-case results, and redacted diagnostics;\n4. admission, catalogue, implementation-support, route, and lease snapshots;\n5. image inspect, history, SBOM, and separate supply-chain decisions;\n6. provider request and audit correlations without tokens or personal data;\n7. durable Action, approval, idempotency, webhook, Event, and outbox evidence;\n8. failure and recovery ordering for process, lease, database, and provider;\n9. a generated 153-row capability coverage matrix;\n10. checksums for every artifact and one evidence-root checksum;\n11. verified cleanup, residual-resource inventory, and retained exceptions;\n12. a summary stating scope, result, exclusions, reviewer, and UTC time.\n\nA summary file is not a pass by itself. Review every referenced artifact and\nensure later recovery did not hide an earlier failed invariant.\n\nAssign an unambiguous result\n\n| Result | Use when |\n\n| passed | Every required invariant passed for the exact identity set, artifacts are complete, and gaps match the claim |\n| failed | A required invariant failed, identity mismatched, evidence leaked or was corrupted, or cleanup failed |\n| blocked | A required dependency or authority was unavailable before evaluation |\n| notrun | The gate was not executed for this identity set |\n| historical | A retained result belongs to a different source, artifact, topology, or evidence standard |\n\nDo not collapse blocked, notrun, or historical into passed. One gate\ncan pass while a broader release claim remains unestablished.\n\nPublish only the supported claim\n\nAcceptable wording binds the result to its evidence:\n\nAt the recorded time, the identified AIP and Chatwoot connector artifacts\npassed the listed deterministic and controlled-fleet cases in the retained\ntopology. The coverage matrix identifies every unobserved capability and\nexcludes live-provider and production properties.\n\nDo not publish fully compatible, all 153 capabilities live verified,\nexactly once, or production-ready unless the retained campaign defines and\nproves each phrase.\n\nReviewer checklist\n• [ ] Source, image, manifest, upstream, harness, topology, and run identities\n  are immutable and mutually consistent.\n• [ ] Required gates are explicit and no fixture result is labeled live.\n• [ ] The 153-row coverage matrix matches the admitted catalogue.\n• [ ] Connector, image, and controlled-fleet results are retained and redacted.\n• [ ] Mutation evidence binds approval, idempotency, provider effect, Action\n  state, and uncertainty decisions.\n• [ ] Webhook evidence separates authentication, replay, local Event storage,\n  and central publication.\n• [ ] Image inventory is not presented as signature, scan, or provenance.\n• [ ] Cleanup and residual resources are independently recorded.\n• [ ] 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• Chatwoot capability index (../capabilities/README.md)\n• Release artifacts and verification (../../../reference/release-artifacts.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "9553ba00b3c3f0f6931b2865dddef9d687fd282c0d7ccb99c0b23d5db9247600"
  }
}