{
  "schemaVersion": "1.0",
  "title": "Pinned upstream baselines",
  "description": "Use this reference to identify the official product source revision against which each maintained connector mapping was reviewed. A baseline freezes the route and behavior audit. It does not vendor the product, add it to the AIP build, or i",
  "canonical": "https://getaip.org/docs/connectors/upstream-baselines",
  "route": "/docs/connectors/upstream-baselines",
  "source": "docs/connectors/upstream-baselines.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Qualification and Evidence",
  "documentType": "Connector",
  "language": "en",
  "revision": {
    "lastReviewedRevision": "97be86e9efedf07ecf1783b03800f683f107fb04",
    "documentationSourceRevision": "9192fef3695ad294994f2712f6d156241e5e92fb",
    "basis": "frontmatter"
  },
  "downloads": {
    "md": "/docs/download/connectors/upstream-baselines.md",
    "txt": "/docs/download/connectors/upstream-baselines.txt",
    "json": "/docs/download/connectors/upstream-baselines.json",
    "pdf": "/docs/download/connectors/upstream-baselines.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Pinned upstream baselines\ndescription: Record and advance the exact official source revision used by each maintained AIP product connector\nkind: reference\naudience: integrator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\n---\n\n# Pinned upstream baselines\n\nUse this reference to identify the official product source revision against\nwhich each maintained connector mapping was reviewed. A baseline freezes the\nroute and behavior audit. It does not vendor the product, add it to the AIP\nbuild, or identify a running provider deployment.\n\nAt AIP source revision\n`97be86e9efedf07ecf1783b03800f683f107fb04`, the root implementation table and\nall six connector constants agree on the pins below.\n\n## Use the connector constant as the source of truth\n\n| Product | Official repository | Upstream revision | Connector constant | Reference manifest shape |\n|---|---|---|---|---:|\n| Cal.diy | [calcom/cal.diy](https://github.com/calcom/cal.diy) | `f00434927386c9ecdcbd7e6c5f82d22044a245bc` | `aip-connector-cal-diy/src/lib.rs` | 81 capabilities |\n| Hermes Agent | [nousresearch/hermes-agent](https://github.com/nousresearch/hermes-agent) | `7426c09beee73bdff94d916015bac71384f6bc92` | `aip-connector-hermes-agent/src/lib.rs` | 35 capabilities per endpoint |\n| Chatwoot | [chatwoot/chatwoot](https://github.com/chatwoot/chatwoot) | `8818d276b954ac4f84cffd8915c99f40e43804ed` | `aip-connector-chatwoot/src/operations.rs` | 153 capabilities |\n| Dify | [langgenius/dify](https://github.com/langgenius/dify) | `f8d47616c15d0959f604f6a5e2e1d32d3108991b` | `aip-connector-dify/src/operations.rs` | 74 capabilities in the reference app-plus-knowledge topology |\n| CrewAI | [crewAIInc/crewAI](https://github.com/crewAIInc/crewAI) | `bfa652a7be8637562cc9b0833f75d927a64552d1` | `aip-connector-crewai/src/operations.rs` | 10 capabilities per crew |\n| Twenty | [twentyhq/twenty](https://github.com/twentyhq/twenty) | `96a24563674313a3071d359bfccaf33d5e130ab8` | `aip-connector-twenty/src/lib.rs` | 22 capabilities per workspace |\n\nWith one endpoint, crew, and workspace, the six reference manifests contain\n375 capabilities. That total is a catalogue identity, not a statement that\nevery capability was exercised against a live product.\n\nEach connector also includes its upstream revision in manifest compatibility\nmetadata. Treat a mismatch among the source constant, generated manifest,\ndocumentation, and retained report as a release blocker.\n\n## Keep five identities separate\n\nAn upstream commit is only one part of reproducible connector evidence.\n\n| Identity | What it answers |\n|---|---|\n| Upstream source revision | Which official product code defined the audited contract? |\n| Runtime dependency version | Which package or library did an adapter load? |\n| Provider deployment identity | Which source tree, image, configuration, and migration state was running? |\n| AIP connector artifact | Which connector source, image, manifest, and admission package was used? |\n| Qualification report | Which topology and assertions were observed, and when? |\n\nThese identities cannot substitute for one another. A provider image may be\nbuilt from a dirty tree despite carrying an upstream tag. A connector constant\nmay still point to the correct commit while the deployed product has advanced.\nA historical report may name both correctly but cover an older AIP image.\n\nCrewAI has an additional distinction: the sidecar pins the `crewai` Python\npackage to `1.15.5` in `pyproject.toml` and locks its dependency graph in\n`uv.lock`. That package version is a runtime identity. The upstream commit in\nthe table remains the source-audit identity.\n\nThe other five connectors call product HTTP surfaces and do not compile the\nupstream source into their Rust crates. Their provider build identity must be\ncaptured by the product campaign.\n\n## Re-audit the right contract surface\n\nWhen a pin changes, review the behavior that the connector actually depends\non, not the product's release notes alone.\n\n| Product | Contract surfaces to re-audit |\n|---|---|\n| Cal.diy | Versioned business controllers; scheduling request and response types; booking, slot, schedule, event-type, team, routing, conferencing, OAuth-client, and webhook behavior; exact raw-body signing; trigger names; removed or operator-only routes |\n| Hermes Agent | Health and discovery; model, skill, and toolset catalogues; chat and response streaming; durable runs and events; approvals; stop and polling behavior; sessions; schedules; MCP configuration and tool filtering |\n| Chatwoot | Account-scoped REST routes; conversations, messages, assignments, labels, contacts, and attachments; multipart rules; mutation idempotency expectations; webhook signature input, headers, event identity, and loop prevention |\n| Dify | Application mode detection; completion, chat, workflow, task, and cancellation routes; Service and Knowledge APIs; JSON, multipart, binary, and SSE responses; human-input and paused-workflow events |\n| CrewAI | Async kickoff; ordered stream events; cancellation and close behavior; terminal output; batch, replay, training, testing, knowledge, and memory APIs; sidecar authentication and persistent job semantics |\n| Twenty | Core-record paths for standard and custom objects; filters, cursors, batch actions, duplicates, group-by, merge, deletion, and restore; metadata resources; workspace OpenAPI paths; webhook HMAC input, timestamp, nonce, and secret handling |\n\nFor every product, also compare:\n\n- HTTP methods, paths, status codes, redirects, and content types;\n- authentication placement, scope, rotation, and tenant or workspace binding;\n- required and optional request fields plus provider defaults;\n- response, pagination, stream, event, and terminal-state shapes;\n- retry, cancellation, idempotency, and uncertain-outcome semantics;\n- webhook raw bytes, signature construction, time window, and replay identity;\n- error categories, rate limits, body limits, and deprecated surfaces.\n\nAn unchanged route name does not prove an unchanged contract.\n\n## Verify an exact local checkout\n\nSet the expected repository, revision, and clean checkout, then perform only\nread-only checks:\n\n```sh\nupstream=/absolute/path/to/product-checkout\nexpected_remote=https://github.com/owner/repository.git\nexpected_revision=0123456789abcdef0123456789abcdef01234567\n\ntest \"$(git -C \"$upstream\" remote get-url origin)\" = \"$expected_remote\"\ntest \"$(git -C \"$upstream\" rev-parse HEAD)\" = \"$expected_revision\"\ngit -C \"$upstream\" cat-file -e \"$expected_revision^{commit}\"\ntest -z \"$(git -C \"$upstream\" status --porcelain)\"\ngit -C \"$upstream\" show -s --format='%H %T %cI %s' \"$expected_revision\"\n```\n\nRecord the commit and tree IDs in the audit. For a provider build, also record\nthe deterministic source archive digest and resulting image digest. A local\ncheckout path is not part of the public contract and must not appear in the\nqualification claim.\n\nIf the expected commit object is unavailable, fetch it from the verified\nofficial remote in a controlled preparation step. Do not audit a nearby branch\nor newer checkout and describe it as the pin.\n\n## Advance a baseline deliberately\n\nTreat any pin change as a connector compatibility change, even when native AIP\nmessages do not change.\n\n1. select one full commit from the official repository;\n2. verify the remote, commit, tree, and clean source state;\n3. diff every product-specific surface listed above against the previous pin;\n4. classify additions, removals, defaults, deprecations, and semantic changes;\n5. update the connector's `UPSTREAM_REVISION` constant and only the reviewed\n   operation mappings;\n6. update request, response, event, error, schema, approval, retry,\n   cancellation, webhook, and exclusion tests as affected;\n7. regenerate the connector manifest and verify its capability count and\n   upstream metadata;\n8. run the complete applicable connector conformance matrix;\n9. rebuild immutable connector and provider artifacts and run the required\n   isolated-live campaign;\n10. retain the old and new pins, artifact digests, diff review, reports, and\n    explicit limitations in release evidence.\n\nDo not silently move the documentation table ahead of the source constant.\nDo not remove an older baseline from a historical report; that report must\ncontinue to identify what it actually tested.\n\n## State compatibility narrowly\n\nUse wording such as:\n\n> Connector artifact `<digest>` was reviewed and qualified against provider\n> artifact `<digest>` built from upstream commit `<full-commit>`.\n\nDo not say `supports the latest version`, `supports all product APIs`, or\n`compatible with commit X and later`. Those claims require evidence beyond a\nsingle frozen mapping.\n\n## Related documentation\n\n- [Connector documentation](README.md)\n- [Implementation status](../reference/implementation-status.md)\n- [Conformance and qualification](../reference/conformance.md)\n- [Live product E2E](../testing/live-product-e2e.md)\n",
    "text": "Pinned upstream baselines\n\nUse this reference to identify the official product source revision against\nwhich each maintained connector mapping was reviewed. A baseline freezes the\nroute and behavior audit. It does not vendor the product, add it to the AIP\nbuild, or identify a running provider deployment.\n\nAt AIP source revision\n97be86e9efedf07ecf1783b03800f683f107fb04, the root implementation table and\nall six connector constants agree on the pins below.\n\nUse the connector constant as the source of truth\n\n| Product | Official repository | Upstream revision | Connector constant | Reference manifest shape |\n\n| Cal.diy | calcom/cal.diy (https://github.com/calcom/cal.diy) | f00434927386c9ecdcbd7e6c5f82d22044a245bc | aip-connector-cal-diy/src/lib.rs | 81 capabilities |\n| Hermes Agent | nousresearch/hermes-agent (https://github.com/nousresearch/hermes-agent) | 7426c09beee73bdff94d916015bac71384f6bc92 | aip-connector-hermes-agent/src/lib.rs | 35 capabilities per endpoint |\n| Chatwoot | chatwoot/chatwoot (https://github.com/chatwoot/chatwoot) | 8818d276b954ac4f84cffd8915c99f40e43804ed | aip-connector-chatwoot/src/operations.rs | 153 capabilities |\n| Dify | langgenius/dify (https://github.com/langgenius/dify) | f8d47616c15d0959f604f6a5e2e1d32d3108991b | aip-connector-dify/src/operations.rs | 74 capabilities in the reference app-plus-knowledge topology |\n| CrewAI | crewAIInc/crewAI (https://github.com/crewAIInc/crewAI) | bfa652a7be8637562cc9b0833f75d927a64552d1 | aip-connector-crewai/src/operations.rs | 10 capabilities per crew |\n| Twenty | twentyhq/twenty (https://github.com/twentyhq/twenty) | 96a24563674313a3071d359bfccaf33d5e130ab8 | aip-connector-twenty/src/lib.rs | 22 capabilities per workspace |\n\nWith one endpoint, crew, and workspace, the six reference manifests contain\n375 capabilities. That total is a catalogue identity, not a statement that\nevery capability was exercised against a live product.\n\nEach connector also includes its upstream revision in manifest compatibility\nmetadata. Treat a mismatch among the source constant, generated manifest,\ndocumentation, and retained report as a release blocker.\n\nKeep five identities separate\n\nAn upstream commit is only one part of reproducible connector evidence.\n\n| Identity | What it answers |\n\n| Upstream source revision | Which official product code defined the audited contract? |\n| Runtime dependency version | Which package or library did an adapter load? |\n| Provider deployment identity | Which source tree, image, configuration, and migration state was running? |\n| AIP connector artifact | Which connector source, image, manifest, and admission package was used? |\n| Qualification report | Which topology and assertions were observed, and when? |\n\nThese identities cannot substitute for one another. A provider image may be\nbuilt from a dirty tree despite carrying an upstream tag. A connector constant\nmay still point to the correct commit while the deployed product has advanced.\nA historical report may name both correctly but cover an older AIP image.\n\nCrewAI has an additional distinction: the sidecar pins the crewai Python\npackage to 1.15.5 in pyproject.toml and locks its dependency graph in\nuv.lock. That package version is a runtime identity. The upstream commit in\nthe table remains the source-audit identity.\n\nThe other five connectors call product HTTP surfaces and do not compile the\nupstream source into their Rust crates. Their provider build identity must be\ncaptured by the product campaign.\n\nRe-audit the right contract surface\n\nWhen a pin changes, review the behavior that the connector actually depends\non, not the product's release notes alone.\n\n| Product | Contract surfaces to re-audit |\n\n| Cal.diy | Versioned business controllers; scheduling request and response types; booking, slot, schedule, event-type, team, routing, conferencing, OAuth-client, and webhook behavior; exact raw-body signing; trigger names; removed or operator-only routes |\n| Hermes Agent | Health and discovery; model, skill, and toolset catalogues; chat and response streaming; durable runs and events; approvals; stop and polling behavior; sessions; schedules; MCP configuration and tool filtering |\n| Chatwoot | Account-scoped REST routes; conversations, messages, assignments, labels, contacts, and attachments; multipart rules; mutation idempotency expectations; webhook signature input, headers, event identity, and loop prevention |\n| Dify | Application mode detection; completion, chat, workflow, task, and cancellation routes; Service and Knowledge APIs; JSON, multipart, binary, and SSE responses; human-input and paused-workflow events |\n| CrewAI | Async kickoff; ordered stream events; cancellation and close behavior; terminal output; batch, replay, training, testing, knowledge, and memory APIs; sidecar authentication and persistent job semantics |\n| Twenty | Core-record paths for standard and custom objects; filters, cursors, batch actions, duplicates, group-by, merge, deletion, and restore; metadata resources; workspace OpenAPI paths; webhook HMAC input, timestamp, nonce, and secret handling |\n\nFor every product, also compare:\n• HTTP methods, paths, status codes, redirects, and content types;\n• authentication placement, scope, rotation, and tenant or workspace binding;\n• required and optional request fields plus provider defaults;\n• response, pagination, stream, event, and terminal-state shapes;\n• retry, cancellation, idempotency, and uncertain-outcome semantics;\n• webhook raw bytes, signature construction, time window, and replay identity;\n• error categories, rate limits, body limits, and deprecated surfaces.\n\nAn unchanged route name does not prove an unchanged contract.\n\nVerify an exact local checkout\n\nSet the expected repository, revision, and clean checkout, then perform only\nread-only checks:\n\nupstream=/absolute/path/to/product-checkout\nexpectedremote=https://github.com/owner/repository.git\nexpectedrevision=0123456789abcdef0123456789abcdef01234567\n\ntest \"$(git -C \"$upstream\" remote get-url origin)\" = \"$expectedremote\"\ntest \"$(git -C \"$upstream\" rev-parse HEAD)\" = \"$expectedrevision\"\ngit -C \"$upstream\" cat-file -e \"$expectedrevision^{commit}\"\ntest -z \"$(git -C \"$upstream\" status --porcelain)\"\ngit -C \"$upstream\" show -s --format='%H %T %cI %s' \"$expectedrevision\"\n\nRecord the commit and tree IDs in the audit. For a provider build, also record\nthe deterministic source archive digest and resulting image digest. A local\ncheckout path is not part of the public contract and must not appear in the\nqualification claim.\n\nIf the expected commit object is unavailable, fetch it from the verified\nofficial remote in a controlled preparation step. Do not audit a nearby branch\nor newer checkout and describe it as the pin.\n\nAdvance a baseline deliberately\n\nTreat any pin change as a connector compatibility change, even when native AIP\nmessages do not change.\n1. select one full commit from the official repository;\n2. verify the remote, commit, tree, and clean source state;\n3. diff every product-specific surface listed above against the previous pin;\n4. classify additions, removals, defaults, deprecations, and semantic changes;\n5. update the connector's UPSTREAMREVISION constant and only the reviewed\n   operation mappings;\n6. update request, response, event, error, schema, approval, retry,\n   cancellation, webhook, and exclusion tests as affected;\n7. regenerate the connector manifest and verify its capability count and\n   upstream metadata;\n8. run the complete applicable connector conformance matrix;\n9. rebuild immutable connector and provider artifacts and run the required\n   isolated-live campaign;\n10. retain the old and new pins, artifact digests, diff review, reports, and\n    explicit limitations in release evidence.\n\nDo not silently move the documentation table ahead of the source constant.\nDo not remove an older baseline from a historical report; that report must\ncontinue to identify what it actually tested.\n\nState compatibility narrowly\n\nUse wording such as:\n\nConnector artifact  was reviewed and qualified against provider\nartifact  built from upstream commit .\n\nDo not say supports the latest version, supports all product APIs, or\ncompatible with commit X and later. Those claims require evidence beyond a\nsingle frozen mapping.\n\nRelated documentation\n• Connector documentation (README.md)\n• Implementation status (../reference/implementation-status.md)\n• Conformance and qualification (../reference/conformance.md)\n• Live product E2E (../testing/live-product-e2e.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "7df67ad36c379f0fcf423c96fb0676154d1abbe99abb0c7fd2a5f8c5b9eff4d1"
  }
}