{
  "format": "agent-article-v0",
  "article_id": "EA-060",
  "canonical_url": "/tools/ea-060-ai-dependency-compatibility-matrix",
  "page_type": "reference",
  "claim_ids": [],
  "evidence_ids": [
    "EVD-EA-060-URL-4CD5EB117CDF",
    "EVD-EA-060-URL-44399078C55F",
    "EVD-EA-060-URL-B6F8ACAC187A",
    "EVD-EA-060-URL-D5725AFE66DD",
    "EVD-EA-060-URL-0D95FA0076F1",
    "EVD-EA-060-URL-FAAB38298E22",
    "EVD-EA-060-URL-4C12FA76FA7E",
    "EVD-EA-060-URL-0E681667EFBA",
    "EA-060-R11-RESEARCH",
    "EA-060-R11-WEB-READBACK"
  ],
  "unknown_ids": [
    "EA-060-UNKNOWN-01",
    "EA-060-UNKNOWN-CURRENTNESS"
  ],
  "operational_object_ids": [],
  "provider": [
    "Anthropic"
  ],
  "models": [],
  "plans": [],
  "surfaces": [],
  "regions": [],
  "current_status": "UNKNOWN",
  "observation_status": "SPEC_ONLY",
  "freshness": "UNKNOWN",
  "last_verified": null,
  "supersedes": [],
  "superseded_by": [],
  "provenance": [
    "COMM-056-EA0060",
    "SRC-EA-060-URL-4CD5EB117CDF",
    "SRC-EA-060-URL-44399078C55F",
    "SRC-EA-060-URL-B6F8ACAC187A",
    "SRC-EA-060-URL-D5725AFE66DD",
    "SRC-EA-060-URL-0D95FA0076F1",
    "SRC-EA-060-URL-FAAB38298E22",
    "SRC-EA-060-URL-4C12FA76FA7E",
    "SRC-EA-060-URL-0E681667EFBA",
    "WEBBODY-EA0060-R8-CB347A2B"
  ],
  "article_sources": [
    {
      "id": "EVD-EA-060-URL-4CD5EB117CDF",
      "evidence_class": "RESEARCH",
      "title": "E1 | class: provider official lifecycle documentation | title: Model deprecations | author/org: Anthropic | canonical URL:",
      "href": "https://docs.anthropic.com/en/docs/about-claude/model-deprecations",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-060-URL-4CD5EB117CDF"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "E1 | class: provider official lifecycle documentation | title: Model deprecations | author/org: Anthropic | canonical URL: https://docs.anthropic.com/en/docs/about-claude/model-deprecations"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-060-URL-44399078C55F",
      "evidence_class": "RESEARCH",
      "title": "E2 | class: interoperability specification | title: Lifecycle — MCP specification 2025-11-25 | author/org: Model Context Protocol | canonical URL:",
      "href": "https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-060-URL-44399078C55F"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "E2 | class: interoperability specification | title: Lifecycle — MCP specification 2025-11-25 | author/org: Model Context Protocol | canonical URL: https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-060-URL-B6F8ACAC187A",
      "evidence_class": "RESEARCH",
      "title": "E3 | class: official SDK documentation | title: Protocol Versions | author/org: MCP Ruby SDK | canonical URL:",
      "href": "https://ruby.sdk.modelcontextprotocol.io/protocol-versions/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-060-URL-B6F8ACAC187A"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "E3 | class: official SDK documentation | title: Protocol Versions | author/org: MCP Ruby SDK | canonical URL: https://ruby.sdk.modelcontextprotocol.io/protocol-versions/"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-060-URL-D5725AFE66DD",
      "evidence_class": "RESEARCH",
      "title": "E4 | class: official SDK documentation | title: LifeCycle | author/org: MCP Go SDK | canonical URL:",
      "href": "https://go.sdk.modelcontextprotocol.io/protocol/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-060-URL-D5725AFE66DD"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "E4 | class: official SDK documentation | title: LifeCycle | author/org: MCP Go SDK | canonical URL: https://go.sdk.modelcontextprotocol.io/protocol/"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-060-URL-0D95FA0076F1",
      "evidence_class": "RESEARCH",
      "title": "E5 | class: project release note | title: The 2026-07-28 MCP Specification Release Candidate | author/org: Model Context Protocol | canonical URL:",
      "href": "https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-060-URL-0D95FA0076F1"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "E5 | class: project release note | title: The 2026-07-28 MCP Specification Release Candidate | author/org: Model Context Protocol | canonical URL: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-060-URL-FAAB38298E22",
      "evidence_class": "RESEARCH",
      "title": "E6 | class: author-maintained SDK release | title: The Official Ruby SDK for MCP Reaches 1.0 | author/org: Model Context Protocol / Ruby SDK maintainer Koichi Ito | canonical URL:",
      "href": "https://blog.modelcontextprotocol.io/posts/ruby-sdk-1-0/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-060-URL-FAAB38298E22"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "E6 | class: author-maintained SDK release | title: The Official Ruby SDK for MCP Reaches 1.0 | author/org: Model Context Protocol / Ruby SDK maintainer Koichi Ito | canonical URL: https://blog.modelcontextprotocol.io/posts/ruby-sdk-1-0/"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-060-URL-4C12FA76FA7E",
      "evidence_class": "RESEARCH",
      "title": "E7 | class: standard/project release update | title: OpenFeature Mid-2026 Update: Platform-Native Feature Flags, a New TC Member, and Spec v0.9.0 | author/org: OpenFeature | canoni",
      "href": "https://openfeature.dev/blog/openfeature-mid-2026-update/",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-060-URL-4C12FA76FA7E"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "E7 | class: standard/project release update | title: OpenFeature Mid-2026 Update: Platform-Native Feature Flags, a New TC Member, and Spec v0.9.0 | author/org: OpenFeature | canonical URL: https://openfeature.dev/blog/openfeature-mid-2026-update/"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EVD-EA-060-URL-0E681667EFBA",
      "evidence_class": "RESEARCH",
      "title": "E8 | class: provider official configuration documentation | title: Deploy a prompt to your application using versions in Prompt management | author/org: AWS | canonical URL:",
      "href": "https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-management-deploy.html",
      "supports": [],
      "limit": "元の監査済み資料に記載された参照先です。URLの復元は、資料の最新性や全主張の支持を新たに検証したことを意味しません。",
      "origin_class": "SOURCE_PACKET_REFERENCE",
      "source_or_experiment_ids": [
        "SRC-EA-060-URL-0E681667EFBA"
      ],
      "supporting_locators": [
        "EVIDENCE TABLE",
        "E8 | class: provider official configuration documentation | title: Deploy a prompt to your application using versions in Prompt management | author/org: AWS | canonical URL: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-management-deploy.html"
      ],
      "scope": "EVIDENCE TABLE",
      "provenance_status": "SOURCE_PACKET_REFERENCE_PROJECTED"
    },
    {
      "id": "EA-060-R11-RESEARCH",
      "evidence_class": "RESEARCH",
      "title": "EA-060 監査済みresearch / canonical revision binding",
      "supports": [
        "F1 [SOURCE_REPORT / INFERENCE]: AI dependency compatibility is multidimensional. At minimum the matrix should be able to identify: application/build revision; provider + immutable model ID/revision/lifecycle; provider API revision/beta contract; client SDK/library version; agent framework version; MCP protocol revision/era + negotiated capabilities; tool schema revision; prompt/instruction revision; response schema; embedding model; retrieval/index/vector schema or snapshot; policy/guardrail revision; evaluator version.\nF2 [VERIFIED_SPEC]: MCP proves why protocol revision and capabilities must be recorded separately from SDK version. 2025-11-25 and earlier use handshake/session negotiation, while 2026-07-28 introduces a stateless lifecycle with version/capabilities per request. A nominally “MCP-compatible” client/server pair can therefore differ materially in lifecycle and feature semantics.\nF3 [PRODUCT_VOLATILE]: Provider model lifecycle is a hard compatibility axis. Anthropic explicitly defines Retired models as unavailable and requests fail. A previously valid tuple can stop functioning without an application code change.\nF4 [INFERENCE]: Compatibility has at least two layers. Syntactic/contract compatibility asks whether authentication, protocol negotiation, API/schema/tool invocation succeeds. Semantic compatibility asks whether the same task still achieves acceptable quality, policy compliance, tool behavior and cost/latency. Passing the first does not prove the second.\nF5 [OSS_PRACTICE / INFERENCE]: Standard revision and SDK conformance/version are distinct. MCP SDK tier/conformance and OpenFeature spec/SDK evolution illustrate that “spec latest” and “SDK latest” are not a guaranteed tested pair.\nF6 [PROPOSAL]: Do not build a full Cartesian product. Maintain known-good, tested tuples for deployed paths, planned upgrades, supported rollback paths and security-critical fallbacks. This converts the matrix from documentation inventory into an actionable change gate.\nF7 [PROPOSAL]: Every dependency update should run two suites: (A) contract tests — auth, endpoint/API revision, protocol/capabilities, structured output, tool schema, limits; (B) behavioral regression eval — representative tasks, policy, retrieval/tool outcomes, stochastic repeatability, latency/cost. Record exact tuple and eval revision with the result."
      ],
      "limit": "canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。",
      "origin_class": "AUDITED_CANONICAL_RESEARCH_PACKET",
      "source_or_experiment_ids": [
        "COMM-056-EA0060"
      ],
      "supporting_locators": [
        "COMM-056-EA0060",
        "EA-060-R5-LEGACY-MIGRATION-20261008-R1",
        "content/staging/EA-060.md"
      ],
      "scope": "監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。",
      "provenance_status": "AUDIT_PASS_CANONICAL_BINDING"
    },
    {
      "id": "EA-060-R11-WEB-READBACK",
      "evidence_class": "IMPL",
      "title": "EA-060 Web body identity / canonical readback",
      "supports": [
        "canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。"
      ],
      "limit": "body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。",
      "checked_at": null,
      "origin_class": "IMPLEMENTATION_READBACK",
      "source_or_experiment_ids": [
        "WEBBODY-EA0060-R8-CB347A2B"
      ],
      "supporting_locators": [
        "WEBBODY-EA0060-R8-CB347A2B",
        "content/staging/EA-060.md",
        "EA-060-R5-LEGACY-MIGRATION-20261008-R1"
      ],
      "scope": "R9/R10 canonical readback後のProduction生成時body identity。",
      "provenance_status": "CANONICAL_READBACK_BODY_HASH_MATCH"
    }
  ],
  "research_sections": [
    {
      "heading": "WHY_THIS_MATTERS_TO_UPDATE",
      "text": "Enterprise AIの実行結果は単一アプリversionでは決まらない。provider model lifecycle、API revision、SDK、agent framework、MCP protocol/capabilities、tool schema、prompt、embedding/index、policy/eval等が独立に更新される。requestがHTTP上成功しても意味論・品質が壊れる場合があり、逆にmodel retirementやprotocol breakはhard failureを起こす。公開後アップデートでは「latest同士なら互換」という暗黙仮定を捨て、実際に検証済みの組合せをCompatibility Matrixとして管理する必要がある。"
    },
    {
      "heading": "SCOPE_ROUTING",
      "text": "Enterprise AI Core: dependency lifecycle / change management / configuration provenance\nProvider mapping: model/API lifecycle\nInteroperability: MCP protocol revision/capability negotiation\nImplementation: SDK/framework/spec conformance\nGovernance: supported tuple / upgrade gate / deprecation response\nBenchmark/Eval: contract test + behavioral regression evaluation"
    },
    {
      "heading": "CLAIM_OR_RESEARCH_QUESTION",
      "text": "1. AI stackの互換性を単一semverや「最新version」で管理できるか。\n2. Protocol/APIが接続できるsyntactic compatibilityと、AI taskの意味・品質が維持されるsemantic compatibilityを分離すべきか。\n3. matrixには何のrevision/capabilityを含めるべきか。\n4. provider retirement、protocol revision、SDK conformance lagを変更前にどう検知するか。"
    },
    {
      "heading": "EVIDENCE TABLE",
      "text": "E1 | class: provider official lifecycle documentation | title: Model deprecations | author/org: Anthropic | canonical URL: https://docs.anthropic.com/en/docs/about-claude/model-deprecations | accessed: 2026-09-14 | lifecycle: Active / Legacy / Deprecated / Retired | locator: Overview | label: PRODUCT_VOLATILE / SOURCE_REPORT | relation: support | Evidence: retired model requests fail; deprecated models receive replacement and retirement date. Model availability is an independently moving runtime dependency.\nE2 | class: interoperability specification | title: Lifecycle — MCP specification 2025-11-25 | author/org: Model Context Protocol | canonical URL: https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle | protocol revision: 2025-11-25 | accessed: 2026-09-14 | locator: initialization/version negotiation | label: VERIFIED_SPEC | relation: support/context | Evidence: handshake-era MCP negotiates protocol version and capabilities; unsupported negotiated version can prevent connection.\nE3 | class: official SDK documentation | title: Protocol Versions | author/org: MCP Ruby SDK | canonical URL: https://ruby.sdk.modelcontextprotocol.io/protocol-versions/ | accessed: 2026-09-14 | SDK docs: mcp 1.5.1 | protocol revisions: 2024-11-05, 2025-03-26, 2025-06-18, 2025-11-25, 2026-07-28 | locator: version/era table | label: OSS_PRACTICE / VERIFIED_SPEC-context | relation: support/limit | Evidence: 2026-07-28 is a Modern stateless era with no handshake, whereas older revisions use session handshake; protocol revision changes lifecycle semantics materially.\nE4 | class: official SDK documentation | title: LifeCycle | author/org: MCP Go SDK | canonical URL: https://go.sdk.modelcontextprotocol.io/protocol/ | accessed: 2026-09-14 | protocol modern revision: 2026-07-28 | locator: two lifecycle models | label: OSS_PRACTICE | relation: support | Evidence: SDK supports legacy initialize handshake through 2025-11-25 and stateless 2026-07-28 with version/capabilities carried per request.\nE5 | class: project release note | title: The 2026-07-28 MCP Specification Release Candidate | author/org: Model Context Protocol | canonical URL: https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/ | publication context: final targeted/published 2026-07-28; accessed 2026-09-14 | revision: 2026-07-28 | locator: breaking changes; release timeline | label: SOURCE_REPORT / VERIFIED_SPEC-context | relation: support/counter | Evidence: revision contains breaking changes, including foundational stateless rework and other semantic changes; explicitly demonstrates that compatibility cannot be inferred from package name alone.\nE6 | class: author-maintained SDK release | title: The Official Ruby SDK for MCP Reaches 1.0 | author/org: Model Context Protocol / Ruby SDK maintainer Koichi Ito | canonical URL: https://blog.modelcontextprotocol.io/posts/ruby-sdk-1-0/ | publication: 2026-07-27 | release: mcp gem v1.0.0 | locator: release announcement | label: OSS_PRACTICE / SOURCE_REPORT | relation: context | Evidence: SDK public API reached stable 1.0 and Tier 2 conformance, showing SDK lifecycle/conformance is a distinct dimension from protocol revision.\nE7 | class: standard/project release update | title: OpenFeature Mid-2026 Update: Platform-Native Feature Flags, a New TC Member, and Spec v0.9.0 | author/org: OpenFeature | canonical URL: https://openfeature.dev/blog/openfeature-mid-2026-update/ | publication: 2026-08-12 | spec: v0.9.0 | locator: Specification v0.9.0 | label: SOURCE_REPORT / OSS_PRACTICE | relation: support/limit | Evidence: specification moved from v0.8.0 to v0.9.0 with consequential stabilization/change; ecosystem SDK/provider conformance must be checked rather than assumed from the spec number.\nE8 | class: provider official configuration documentation | title: Deploy a prompt to your application using versions in Prompt management | author/org: AWS | canonical URL: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-management-deploy.html | accessed: 2026-09-14 | service current docs | locator: version as point-in-time snapshot | label: PRODUCT_VOLATILE / SOURCE_REPORT | relation: context | Evidence: prompt configuration has its own version lifecycle independent of application/model SDK versions."
    },
    {
      "heading": "FINDINGS",
      "text": "F1 [SOURCE_REPORT / INFERENCE]: AI dependency compatibility is multidimensional. At minimum the matrix should be able to identify: application/build revision; provider + immutable model ID/revision/lifecycle; provider API revision/beta contract; client SDK/library version; agent framework version; MCP protocol revision/era + negotiated capabilities; tool schema revision; prompt/instruction revision; response schema; embedding model; retrieval/index/vector schema or snapshot; policy/guardrail revision; evaluator version.\nF2 [VERIFIED_SPEC]: MCP proves why protocol revision and capabilities must be recorded separately from SDK version. 2025-11-25 and earlier use handshake/session negotiation, while 2026-07-28 introduces a stateless lifecycle with version/capabilities per request. A nominally “MCP-compatible” client/server pair can therefore differ materially in lifecycle and feature semantics.\nF3 [PRODUCT_VOLATILE]: Provider model lifecycle is a hard compatibility axis. Anthropic explicitly defines Retired models as unavailable and requests fail. A previously valid tuple can stop functioning without an application code change.\nF4 [INFERENCE]: Compatibility has at least two layers. Syntactic/contract compatibility asks whether authentication, protocol negotiation, API/schema/tool invocation succeeds. Semantic compatibility asks whether the same task still achieves acceptable quality, policy compliance, tool behavior and cost/latency. Passing the first does not prove the second.\nF5 [OSS_PRACTICE / INFERENCE]: Standard revision and SDK conformance/version are distinct. MCP SDK tier/conformance and OpenFeature spec/SDK evolution illustrate that “spec latest” and “SDK latest” are not a guaranteed tested pair.\nF6 [PROPOSAL]: Do not build a full Cartesian product. Maintain known-good, tested tuples for deployed paths, planned upgrades, supported rollback paths and security-critical fallbacks. This converts the matrix from documentation inventory into an actionable change gate.\nF7 [PROPOSAL]: Every dependency update should run two suites: (A) contract tests — auth, endpoint/API revision, protocol/capabilities, structured output, tool schema, limits; (B) behavioral regression eval — representative tasks, policy, retrieval/tool outcomes, stochastic repeatability, latency/cost. Record exact tuple and eval revision with the result."
    },
    {
      "heading": "LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE",
      "text": "- Semantic Versioning at one component does not guarantee end-to-end semantic compatibility across providers and AI outputs.\n- Successful MCP handshake/modern request validation establishes protocol compatibility for negotiated capabilities, not task-quality equivalence.\n- Provider docs can describe lifecycle policy but do not prove a specific tenant/region supports a replacement model/API at the required date.\n- Model aliases may be convenient but can hide underlying revision movement; compatibility evidence should prefer immutable/resolved model IDs where supported. This is INFERENCE and must be provider-mapped before asserting alias behavior.\n- Prompt/model/tool/retrieval changes can interact. Testing each component independently can miss combination failures.\n- Matrix staleness is itself a failure mode: an untested tuple should not inherit “supported” status merely because all components are individually supported."
    },
    {
      "heading": "AVAILABILITY_GATES",
      "text": "- Provider model availability depends on provider lifecycle, region, account/plan and endpoint/API path.\n- MCP feature availability depends on protocol revision/era and capability set, not only “MCP support.”\n- SDK implementation/conformance may lag or differ from the latest specification revision.\n- Tool/provider beta headers and API revisions must be captured where relevant.\n- All current lifecycle/release claims require revalidation at future publication/update time."
    },
    {
      "heading": "IMPLEMENTATION_STATE",
      "text": "Industry components already expose pieces needed for the matrix: provider model lifecycle/deprecation tables, MCP explicit version/capability semantics, SDK release/conformance state, prompt version registries. What remains organization-specific is the registry that joins these into tested runtime tuples and associates each tuple with contract/eval evidence.\nSuggested Core record (PROPOSAL): COMPAT_TUPLE_ID; app/build; provider/model resolved ID; API revision; SDK; agent framework; MCP revision/era/capabilities; tool schema; prompt/instruction; response schema; embedding/retrieval/index; policy; evaluator; tested_at; test suite revision; result; known limitations; rollback tuple; owner; expiry/retest date."
    },
    {
      "heading": "BENCHMARK_OR_EVAL",
      "text": "No universal compatibility benchmark was established. A reproducible organization-specific contract suite plus representative behavioral eval is the appropriate first-pass evidence. Compatibility evidence should be scoped to the exact tuple tested and must not be generalized to untested versions or all deployments. Long-lived matrices require periodic revalidation and event-driven retest on dependency change/deprecation notices."
    },
    {
      "heading": "SECURITY / PRIVACY / AUDIT / COST / OPERABILITY",
      "text": "Security: compatibility updates can include security-driven upgrades. Pinning an old “known good” tuple indefinitely can preserve known vulnerabilities; matrix policy needs both functional compatibility and security support status.\nPrivacy: compatibility testing should use synthetic/redacted data unless production-like sensitive data is explicitly authorized under a governed test profile.\nAudit: store the exact resolved tuple and test evidence used to approve an upgrade; mutable aliases alone are insufficient provenance.\nCost: new model/API versions can change token pricing, latency or tool-call patterns even when functionally compatible; cost regression belongs in behavioral gates.\nOperability: deprecation/retirement notices should create planned migration work before retirement, with a verified rollback/fallback path that itself remains available."
    },
    {
      "heading": "SAFE_WORDING_FOR_FUTURE_BOOK",
      "text": "「Enterprise AIの互換性は、単一のアプリversionやSDKのsemverだけでは管理できない。model IDとlifecycle、provider API revision、SDK／Agent framework、MCP protocol revisionとcapability、tool schema、prompt、retrieval、policy、evalなどが独立に変化するため、運用上は実際に検証した組合せをCompatibility Matrixとして持つ。接続・schemaが通る“contract互換”と、task品質・policy・costまで維持される“behavior互換”は分けて検証する。『各部品が最新』『各部品が単体でsupported』は、その組合せが互換であることの証明ではない。」"
    },
    {
      "heading": "UPDATE_WORK_HANDOFF",
      "text": "- EA-058 Prompt/Instruction Configuration Management、EA-059 progressive deliveryと接続し、「変更対象tuple固定 -> contract/eval -> canary -> promotion」のupdate workflow候補へ統合する。\n- provider mappingでは各社のmodel lifecycle/deprecation、immutable ID/alias semantics、API revision/beta contractを個別採集する。\n- MCP mappingでは2026-07-28 modern eraと2025-11-25以前のhandshake eraを別compatibility classとして扱い、capability negotiationまで記録する。\n- OpenFeature等の標準についてもspec revisionと各言語SDK/provider conformanceを別欄にする。\n- TEST_PROFILE（未実施）: synthetic fixtureで既知good tupleを固定し、model replacement、MCP protocol era差、tool schema破壊、prompt version差を1軸ずつ変更。contract testとbehavior evalを別結果として記録し、意図したincompatibilityを検出できるか確認する。"
    },
    {
      "heading": "OPEN_UNKNOWN",
      "text": "各providerのalias更新保証・事前通知・replacement availability SLAはproviderごとに異なり、本Packetでは横断確定していない。特定organization tenantのAPI/model availabilityも未確認。Agent framework群の具体的compatibility tableは後続実装比較で採集余地あり。"
    },
    {
      "heading": "STOP_CONDITION",
      "text": "provider model lifecycle、interoperability protocolのbreaking era、SDK/spec lifecycleという3独立軸の一次証拠が揃い、「単一versionでは管理不能」「contractとbehaviorを分離する」という初回Matrix設計判断が可能になった。provider/tenant固有tupleは後続Workで再検証する。\n\n---"
    },
    {
      "heading": "CURRENTNESS_AUDIT",
      "text": "Anthropic Active/Legacy/Deprecated/Retired lifecycle remains current and retired model requests fail. MCP 2026-07-28 is Final/stateless with no initialize handshake; 2025-11-25 and earlier are handshake-era. SDK support remains version/implementation-specific, including TypeScript v2 explicit opt-in for the 2026-07-28 wire revision."
    }
  ],
  "human_url": "/tools/ea-060-ai-dependency-compatibility-matrix",
  "markdown_url": "/agent/article.md?path=%2Ftools%2Fea-060-ai-dependency-compatibility-matrix",
  "json_url": "/agent/article.json?path=%2Ftools%2Fea-060-ai-dependency-compatibility-matrix"
}