{
  "schemaVersion": "1.0",
  "title": "Qualify the Dify connector",
  "description": "Use this page to decide whether one exact Dify connector artifact supports a bounded release claim. Keep source tests, image checks, controlled fixtures, and actual Dify observations as separate evidence classes.",
  "canonical": "https://getaip.org/docs/connectors/dify/qualification",
  "route": "/docs/connectors/dify/qualification",
  "source": "docs/connectors/dify/qualification/README.md",
  "protocol": "Agent Interoperability Protocol",
  "protocolVersion": "1.0",
  "section": "Connectors",
  "documentType": "Connector",
  "language": "en",
  "downloads": {
    "md": "/docs/download/connectors/dify/qualification.md",
    "txt": "/docs/download/connectors/dify/qualification.txt",
    "json": "/docs/download/connectors/dify/qualification.json",
    "pdf": "/docs/download/connectors/dify/qualification.pdf"
  },
  "content": {
    "format": "text/markdown",
    "markdown": "---\ntitle: Qualify the Dify connector\ndescription: >-\n  Evaluate source contracts, standalone images, controlled fleet behavior, and\n  isolated Dify evidence for one exact connector artifact\nkind: qualification\naudience: evaluator\nappliesTo: \"1.x\"\nwritingStandard: \"aip-docs/1.0\"\nlastReviewedRevision: \"97be86e9efedf07ecf1783b03800f683f107fb04\"\nconnector: dify\n---\n\n# Qualify the Dify connector\n\nUse this page to decide whether one exact Dify connector artifact supports a\nbounded release claim. Keep source tests, image checks, controlled fixtures,\nand actual Dify observations as separate 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.\n\nNo retained isolated-live Dify result for the reviewed standalone host was\nfound in the pinned source tree.\n\n## Use evidence terms consistently\n\n| Term | Required evidence |\n|---|---|\n| Implemented | Behavior and contract exist in identified source |\n| Conformant | Exact artifact passed applicable conformance cases with retained results |\n| Controlled-qualified | Exact artifact passed a named deterministic topology and failure matrix |\n| Isolated-live verified | Exact artifact produced reviewed observations against identified Dify artifacts |\n| Production-observed | Deployment records show 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 one immutable identity set\n\nEvery result must bind identities that can change its meaning:\n\n| Identity class | Required values |\n|---|---|\n| AIP source | Commit, tree, dirty-source snapshot when applicable, and status |\n| Connector artifact | Immutable image ID, component, version, labels, entrypoint, and architecture |\n| Contract | Manifest digest, descriptor hashes, operation asset, schemas, and implementation support |\n| Dify upstream | Commit, tree or image, migrations, feature configuration, and API mode |\n| Harness | Source digest, runner image, configuration digest, and selected cases |\n| Runtime | Engine, databases, trust policy, descriptors, credentials, and network topology |\n| Run | UTC interval, unique run ID, evaluator, and evidence-root digest |\n\nThe reviewed AIP commit is\n`97be86e9efedf07ecf1783b03800f683f107fb04`, with Git tree\n`2d83a382a312c601ecbbf5ed03f8af2b0218bdae`.\n\nThe reviewed Dify source commit is\n`f8d47616c15d0959f604f6a5e2e1d32d3108991b`, with Git tree\n`253bd2797b388544d8343d9cb8cd62185abce795`.\n\nThese identities do not identify a built image or completed run. A mutable\ntag, branch, filename, or documentation date is not 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-dify` | Deterministic connector semantics through Rust boundaries | Container, fleet, or external Dify behavior |\n| Q2: standalone image | `verify-product-images.sh` | Image identity, user, entrypoint, labels, inspect, history, and SBOM | Provider compatibility, signature, vulnerability policy, or admission |\n| Q3: controlled product fleet | Product qualification and fleet verification scripts | Admission, selected operations, policy, isolation, failure closure, and recovery against fixtures | Actual Dify compatibility or complete catalogue behavior |\n| Q4: isolated live | Reviewed campaign manifest and harness | Selected behavior against identified Dify artifacts | Arbitrary deployments, every capability, scale, or production readiness |\n\nRecord every gate required by the claim. A deterministic fixture cannot\nsubstitute for actual Dify, and a provider observation cannot substitute for\nhost admission or failure recovery.\n\n## Review focused connector evidence\n\nThe pinned Dify connector crate defines 18 focused tests. Together they cover:\n\n- completeness, uniqueness, governance, and mode projection of 79 operations;\n- distinction between stop commands and cancellable runs;\n- all 46 Knowledge capabilities in a manifest;\n- canonical path construction and bounded query encoding;\n- request-size and query-value limits before dispatch;\n- scoped Knowledge mutation, key, path, body, and idempotency projection;\n- multipart upload fields and decoded-file bounds;\n- bounded base64 projection for Knowledge binary output;\n- fail-closed mutation behavior without an idempotency key;\n- typed retry and uncertainty mapping;\n- incremental native SSE publication;\n- mode-specific provider stop and cancelled terminal state;\n- cleanup after a malformed admitted stream;\n- durable task recovery across restart;\n- unconfirmed cancellation without durable task identity;\n- completion-family routing and request-field preservation;\n- CRLF parsing, missing event rejection, and frame bounds.\n\nRetain the exact test selection, build identity, exit status, timestamps,\nstructured results, and redacted diagnostics. Source definitions alone are\nimplementation evidence.\n\nThese tests do not establish Dify version compatibility, container packaging,\nfleet admission, database recovery, or live provider behavior.\n\n## Review the standalone image gate\n\nThe image verifier builds `aip-host-dify` with the common host Dockerfile. It\nrequires:\n\n- an immutable SHA-256 image ID;\n- runtime user `10001:10001`;\n- entrypoint `/usr/local/bin/aip-connector-host`;\n- exact source revision, version, and component labels;\n- a successful read-only, capability-dropped `--help` invocation;\n- retained image inspect and full history;\n- an SPDX JSON SBOM.\n\nReview Dify-specific output rather than relying on a shared summary. An SBOM\nis inventory, not a signature, vulnerability decision, license decision, or\nprovider qualification.\n\n## Review the controlled product-fleet gate\n\nThe controlled fixture configures one chat app and one Knowledge credential.\nIt admits exactly 74 Dify capabilities:\n\n```text\n28 chat-app capabilities + 46 Knowledge capabilities\n```\n\nThe selected positive cases are:\n\n| Case | Capability | Required evidence |\n|---|---|---|\n| App read | `cap:dify:qualification-app:parameters.get` | Completed signed Action and provider GET |\n| Knowledge read | `cap:dify:knowledge:qualification-kb:dataset.list` | Completed signed Action with bounded query |\n| Knowledge mutation | `cap:dify:knowledge:qualification-kb:dataset.create` | Pending approval, separate decision, resumed completion, stable key |\n\nThe provider fixture audit requires authorization on Dify requests and an\nidempotency marker on the dataset mutation. The fleet also checks the admitted\ncapability count and an independently owned migrated runtime database.\n\nShared failure cases cover graceful host restart, `SIGKILL` and expired-lease\nfail-closed behavior, gateway failover, PostgreSQL outage, route recovery, and\nfinal ready leases.\n\nThis gate does not exercise a real Dify instance, app alias execution,\nstreaming, cancellation, binary data, uploads, indexing, pipelines, audio,\nannotations, or most operation suffixes.\n\nLabel its result controlled product-fleet qualification, not live Dify\ncompatibility.\n\n## Define isolated-live qualification\n\nAn isolated-live campaign needs a dedicated Dify deployment, disposable apps\nand Knowledge data, separate requester and approver identities, scoped keys,\nand explicit cleanup.\n\nSelect cases by unique behavior:\n\n1. health for every app and Knowledge credential;\n2. exact manifest projection for all configured modes;\n3. one safe app read and one safe Knowledge read;\n4. blocking completion, chat, workflow, and agent-family aliases as configured;\n5. incremental SSE with terminal result and ordered chunks;\n6. confirmed cancellation after task-ID capture;\n7. cancellation before task-ID capture with preserved uncertainty;\n8. binary preview, audio, and document archive envelopes;\n9. bounded multipart app and Knowledge uploads;\n10. async document indexing with provider batch reconciliation;\n11. segment update with embedded failure detection;\n12. multi-document metadata partial-commit handling;\n13. pipeline and node runs through the frozen buffered contract;\n14. authentication, provider rejection, rate limit, malformed SSE, and bounds;\n15. restart, task-store recovery, lease fencing, and storage outage.\n\nRecord provider resources before and after every mutation. One successful HTTP\nexchange cannot establish provider effect, Action result, stream terminal\nstate, and cleanup together.\n\n## Account for every admitted capability\n\nGenerate one coverage row per capability in the admitted manifest. The row\ncount depends on descriptors and modes; 74 is only the controlled fixture.\n\n| Field | Required value |\n|---|---|\n| Capability ID | Exact admitted identifier |\n| Descriptor binding | App or Knowledge ID, mode, and credential revision |\n| Contract evidence | Route, schemas, risk, approval, key, retry, and response mapping |\n| Deterministic evidence | Test and result artifact, or explicit gap |\n| Controlled-fleet evidence | Case and artifact, or `not_run` |\n| Isolated-live evidence | Provider identity, case, artifact, or `not_run` |\n| Failure evidence | Auth, validation, rejection, uncertainty, bounds, and recovery cases |\n| Side-effect control | Approval, key, provider-state check, and cleanup where applicable |\n| Review decision | Accepted scope, limitation, owner, reviewer, and time |\n\nEvery row needs contract evidence. Live mutation of every writable capability\nis unsafe and unnecessary by default.\n\nSelect reversible live cases by distinct transport and state behavior. Publish\nall unobserved capabilities as explicit gaps.\n\n## Retain a complete evidence set\n\nA qualification record should contain:\n\n1. immutable source, image, manifest, schema, Dify, harness, topology, and run\n   identities;\n2. a gate manifest naming every case and invariant;\n3. raw exits, structured 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, task, workflow, document, and batch correlations;\n7. durable Action, approval, idempotency, stream, and cancellation evidence;\n8. failure and recovery ordering for process, lease, storage, and provider;\n9. a generated admitted-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 is not a pass by itself. Review every referenced artifact and ensure\nlater 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 and gaps match the claim |\n| `failed` | An invariant failed, identity mismatched, evidence leaked, 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` | Retained evidence belongs to another source, artifact, topology, or 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 result and exclusions:\n\n> At the recorded time, the identified AIP and Dify connector artifacts passed\n> the listed deterministic and controlled-fleet cases in the retained\n> topology. The coverage matrix identifies unobserved capabilities and\n> excludes live-provider and production properties.\n\nDo not publish `fully compatible`, `all capabilities live verified`, `exactly\nonce`, or `production-ready` unless the retained campaign defines and proves\neach phrase.\n\n## Reviewer checklist\n\n- [ ] Source, image, manifest, Dify, harness, topology, and run identities are\n  immutable and mutually consistent.\n- [ ] Required gates are explicit and fixture results are not labeled live.\n- [ ] Coverage rows match the exact admitted manifest, not a universal count.\n- [ ] Focused, image, and controlled-fleet artifacts are retained and redacted.\n- [ ] Mutation evidence binds approval, key, provider effect, and uncertainty.\n- [ ] Stream evidence binds ordered chunks, terminal state, and cleanup.\n- [ ] Durable task evidence covers restart and missing-identity uncertainty.\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- [Dify capability index](../capabilities/README.md)\n- [Release artifacts and verification](../../../reference/release-artifacts.md)\n",
    "text": "Qualify the Dify connector\n\nUse this page to decide whether one exact Dify connector artifact supports a\nbounded release claim. Keep source tests, image checks, controlled fixtures,\nand actual Dify observations as separate 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.\n\nNo retained isolated-live Dify result for the reviewed standalone host was\nfound in the pinned source tree.\n\nUse evidence terms consistently\n\n| Term | Required evidence |\n\n| Implemented | Behavior and contract exist in identified source |\n| Conformant | Exact artifact passed applicable conformance cases with retained results |\n| Controlled-qualified | Exact artifact passed a named deterministic topology and failure matrix |\n| Isolated-live verified | Exact artifact produced reviewed observations against identified Dify artifacts |\n| Production-observed | Deployment records show 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 one immutable identity set\n\nEvery result must bind identities that can change its meaning:\n\n| Identity class | Required values |\n\n| AIP source | Commit, tree, dirty-source snapshot when applicable, and status |\n| Connector artifact | Immutable image ID, component, version, labels, entrypoint, and architecture |\n| Contract | Manifest digest, descriptor hashes, operation asset, schemas, and implementation support |\n| Dify upstream | Commit, tree or image, migrations, feature configuration, and API mode |\n| Harness | Source digest, runner image, configuration digest, and selected cases |\n| Runtime | Engine, databases, trust policy, descriptors, credentials, and network topology |\n| Run | UTC interval, unique run ID, evaluator, and evidence-root digest |\n\nThe reviewed AIP commit is\n97be86e9efedf07ecf1783b03800f683f107fb04, with Git tree\n2d83a382a312c601ecbbf5ed03f8af2b0218bdae.\n\nThe reviewed Dify source commit is\nf8d47616c15d0959f604f6a5e2e1d32d3108991b, with Git tree\n253bd2797b388544d8343d9cb8cd62185abce795.\n\nThese identities do not identify a built image or completed run. A mutable\ntag, branch, filename, or documentation date is not 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-dify | Deterministic connector semantics through Rust boundaries | Container, fleet, or external Dify behavior |\n| Q2: standalone image | verify-product-images.sh | Image identity, user, entrypoint, labels, inspect, history, and SBOM | Provider compatibility, signature, vulnerability policy, or admission |\n| Q3: controlled product fleet | Product qualification and fleet verification scripts | Admission, selected operations, policy, isolation, failure closure, and recovery against fixtures | Actual Dify compatibility or complete catalogue behavior |\n| Q4: isolated live | Reviewed campaign manifest and harness | Selected behavior against identified Dify artifacts | Arbitrary deployments, every capability, scale, or production readiness |\n\nRecord every gate required by the claim. A deterministic fixture cannot\nsubstitute for actual Dify, and a provider observation cannot substitute for\nhost admission or failure recovery.\n\nReview focused connector evidence\n\nThe pinned Dify connector crate defines 18 focused tests. Together they cover:\n• completeness, uniqueness, governance, and mode projection of 79 operations;\n• distinction between stop commands and cancellable runs;\n• all 46 Knowledge capabilities in a manifest;\n• canonical path construction and bounded query encoding;\n• request-size and query-value limits before dispatch;\n• scoped Knowledge mutation, key, path, body, and idempotency projection;\n• multipart upload fields and decoded-file bounds;\n• bounded base64 projection for Knowledge binary output;\n• fail-closed mutation behavior without an idempotency key;\n• typed retry and uncertainty mapping;\n• incremental native SSE publication;\n• mode-specific provider stop and cancelled terminal state;\n• cleanup after a malformed admitted stream;\n• durable task recovery across restart;\n• unconfirmed cancellation without durable task identity;\n• completion-family routing and request-field preservation;\n• CRLF parsing, missing event rejection, and frame bounds.\n\nRetain the exact test selection, build identity, exit status, timestamps,\nstructured results, and redacted diagnostics. Source definitions alone are\nimplementation evidence.\n\nThese tests do not establish Dify version compatibility, container packaging,\nfleet admission, database recovery, or live provider behavior.\n\nReview the standalone image gate\n\nThe image verifier builds aip-host-dify with the common host Dockerfile. It\nrequires:\n• an immutable SHA-256 image ID;\n• runtime user 10001:10001;\n• entrypoint /usr/local/bin/aip-connector-host;\n• exact source revision, version, and component labels;\n• a successful read-only, capability-dropped --help invocation;\n• retained image inspect and full history;\n• an SPDX JSON SBOM.\n\nReview Dify-specific output rather than relying on a shared summary. An SBOM\nis inventory, not a signature, vulnerability decision, license decision, or\nprovider qualification.\n\nReview the controlled product-fleet gate\n\nThe controlled fixture configures one chat app and one Knowledge credential.\nIt admits exactly 74 Dify capabilities:\n\n28 chat-app capabilities + 46 Knowledge capabilities\n\nThe selected positive cases are:\n\n| Case | Capability | Required evidence |\n\n| App read | cap:dify:qualification-app:parameters.get | Completed signed Action and provider GET |\n| Knowledge read | cap:dify:knowledge:qualification-kb:dataset.list | Completed signed Action with bounded query |\n| Knowledge mutation | cap:dify:knowledge:qualification-kb:dataset.create | Pending approval, separate decision, resumed completion, stable key |\n\nThe provider fixture audit requires authorization on Dify requests and an\nidempotency marker on the dataset mutation. The fleet also checks the admitted\ncapability count and an independently owned migrated runtime database.\n\nShared failure cases cover graceful host restart, SIGKILL and expired-lease\nfail-closed behavior, gateway failover, PostgreSQL outage, route recovery, and\nfinal ready leases.\n\nThis gate does not exercise a real Dify instance, app alias execution,\nstreaming, cancellation, binary data, uploads, indexing, pipelines, audio,\nannotations, or most operation suffixes.\n\nLabel its result controlled product-fleet qualification, not live Dify\ncompatibility.\n\nDefine isolated-live qualification\n\nAn isolated-live campaign needs a dedicated Dify deployment, disposable apps\nand Knowledge data, separate requester and approver identities, scoped keys,\nand explicit cleanup.\n\nSelect cases by unique behavior:\n1. health for every app and Knowledge credential;\n2. exact manifest projection for all configured modes;\n3. one safe app read and one safe Knowledge read;\n4. blocking completion, chat, workflow, and agent-family aliases as configured;\n5. incremental SSE with terminal result and ordered chunks;\n6. confirmed cancellation after task-ID capture;\n7. cancellation before task-ID capture with preserved uncertainty;\n8. binary preview, audio, and document archive envelopes;\n9. bounded multipart app and Knowledge uploads;\n10. async document indexing with provider batch reconciliation;\n11. segment update with embedded failure detection;\n12. multi-document metadata partial-commit handling;\n13. pipeline and node runs through the frozen buffered contract;\n14. authentication, provider rejection, rate limit, malformed SSE, and bounds;\n15. restart, task-store recovery, lease fencing, and storage outage.\n\nRecord provider resources before and after every mutation. One successful HTTP\nexchange cannot establish provider effect, Action result, stream terminal\nstate, and cleanup together.\n\nAccount for every admitted capability\n\nGenerate one coverage row per capability in the admitted manifest. The row\ncount depends on descriptors and modes; 74 is only the controlled fixture.\n\n| Field | Required value |\n\n| Capability ID | Exact admitted identifier |\n| Descriptor binding | App or Knowledge ID, mode, and credential revision |\n| Contract evidence | Route, schemas, risk, approval, key, retry, and response mapping |\n| Deterministic evidence | Test and result artifact, or explicit gap |\n| Controlled-fleet evidence | Case and artifact, or notrun |\n| Isolated-live evidence | Provider identity, case, artifact, or notrun |\n| Failure evidence | Auth, validation, rejection, uncertainty, bounds, and recovery cases |\n| Side-effect control | Approval, key, provider-state check, and cleanup where applicable |\n| Review decision | Accepted scope, limitation, owner, reviewer, and time |\n\nEvery row needs contract evidence. Live mutation of every writable capability\nis unsafe and unnecessary by default.\n\nSelect reversible live cases by distinct transport and state behavior. Publish\nall unobserved capabilities as explicit gaps.\n\nRetain a complete evidence set\n\nA qualification record should contain:\n1. immutable source, image, manifest, schema, Dify, harness, topology, and run\n   identities;\n2. a gate manifest naming every case and invariant;\n3. raw exits, structured 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, task, workflow, document, and batch correlations;\n7. durable Action, approval, idempotency, stream, and cancellation evidence;\n8. failure and recovery ordering for process, lease, storage, and provider;\n9. a generated admitted-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 is not a pass by itself. Review every referenced artifact and ensure\nlater 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 and gaps match the claim |\n| failed | An invariant failed, identity mismatched, evidence leaked, 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 | Retained evidence belongs to another source, artifact, topology, or 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 result and exclusions:\n\nAt the recorded time, the identified AIP and Dify connector artifacts passed\nthe listed deterministic and controlled-fleet cases in the retained\ntopology. The coverage matrix identifies unobserved capabilities and\nexcludes live-provider and production properties.\n\nDo not publish fully compatible, all capabilities live verified, exactly\nonce, or production-ready unless the retained campaign defines and proves\neach phrase.\n\nReviewer checklist\n• [ ] Source, image, manifest, Dify, harness, topology, and run identities are\n  immutable and mutually consistent.\n• [ ] Required gates are explicit and fixture results are not labeled live.\n• [ ] Coverage rows match the exact admitted manifest, not a universal count.\n• [ ] Focused, image, and controlled-fleet artifacts are retained and redacted.\n• [ ] Mutation evidence binds approval, key, provider effect, and uncertainty.\n• [ ] Stream evidence binds ordered chunks, terminal state, and cleanup.\n• [ ] Durable task evidence covers restart and missing-identity uncertainty.\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• Dify capability index (../capabilities/README.md)\n• Release artifacts and verification (../../../reference/release-artifacts.md)\n"
  },
  "integrity": {
    "algorithm": "sha256",
    "sourceDigest": "962f639013b7af2b63fbc1290d3433fc0c3116862944fdd25ce2a6e099fd7d74"
  }
}