Not all 'compatible with' claims are equal: only when five conditions — a closed boundary, testable conformance, independent custody, reversible state/operations, and quarantined extensions — hold does compatibility become a credible exit right; common infrastructure claims (S3, PostgreSQL, Kubernetes, OpenTelemetry) vary widely against this bar.

Main Finding

The paper introduces the Substitution Escrow Threshold (SET): a five-condition framework that determines when a vendor’s “compatible-with” claim actually functions as a credible, procurement-grade exit option (i.e., it escrow‑like reduces institutional vendor lock‑in) rather than merely lowering first‑integration cost. Applied to five infrastructure cases (OCI, Kubernetes, OpenTelemetry, S3, PostgreSQL), the framework shows that superficially similar compatibility claims have very different institutional value depending on where and how the portability boundary is defined, governed, tested, and operationalized. The paper argues AI infrastructure is the most urgent next application of this framework.

Key Points

• The SET comprises five conditions. The claim becomes a real exit option only when all are satisfied to a useful degree:
• Boundary closure — the compatibility spec actually covers the production behaviors the workload depends on.
• Executable conformance — independent, reproducible tests or certification exist that verify the claim.
• Custody independence — the compatibility contract/standard is governed outside the incumbent vendor’s unilateral control.
• State & operations reversibility — the buyer can move relevant state, configuration, policies, and operating procedures without bespoke reengineering.
• Extension quarantine — proprietary or implementation-specific features are identified and isolated so they don’t silently leak lock‑in.
• The first two conditions are gating: without them the claim is largely an assertion. Custody independence protects the contract from vendor capture; state/ops reversibility determines real migration cost; extension quarantine preserves the contract’s durability after adoption.
• Case results (summary):
  • OCI images: strong — narrow, well‑specified artifact boundary + executable certification → procurement‑grade.
  • Kubernetes: conformance exists for APIs but many managed‑service dependencies (IAM, storage, networking, addons, runbooks) remain outside the conformance boundary → partial escrow.
  • OpenTelemetry: strong at instrumentation/emission layer (decouples telemetry export) but doesn’t escrow backend workflows (dashboards, alert logic, retention).
  • S3 compatibility: practically valuable for object‑operation profiles, but often a “borrowed” compatibility tied to Amazon’s reference API rather than a neutral conformance regime.
  • PostgreSQL compatibility: accelerates developer onboarding but does not by itself assure production substitutability because of extensions, planner behavior, replication and operational semantics.
• Common procurement mistakes the framework corrects: (a) equating formal standardization or foundation governance with full portability; (b) treating API compatibility alone as substitutability; (c) conflating adoption/market share with escrowed compatibility.
• SET reframes compatibility as a buyer‑side option‑valuation problem: an escrowed claim is an unexercised switching right with quantifiable procurement value.

Data & Methods

• Method: conceptual framework development + comparative case analysis.
  • Synthesizes literature from standards/compatibility economics, software‑engineering studies on interface stability, IT sourcing/vendor lock‑in, and real‑options theory for IT investments.
  • Operationalizes five conditions into simple tests (e.g., list the top N production behaviors and check how many are inside the declared boundary; presence of versioned test suites/certification; who governs the spec; ability to move state and runbooks; presence of a quarantine ledger for proprietary extensions).
• Evidence basis: public documentation, conformance programs, vendor migration/matrix documentation for five concrete infrastructure families (OCI, Kubernetes, OpenTelemetry, S3, PostgreSQL).
• Intended output: diagnostics and procurement checklists (not a single numeric score) that permit architects, procurement teams, platform engineers, and investors to assign credible exit value to compatibility claims.
• Limitations:
  • Qualitative/conceptual rather than large‑n empirical testing.
  • Applied to infrastructure‑level compatibility claims; deliberately excludes many application‑level or SDK convenience cases.
  • Requires empirical validation (e.g., measuring realized switching costs or market outcomes conditional on SET satisfaction).

Implications for AI Economics

• Why this matters for AI markets
  • AI infrastructure and model‑service compatibility (e.g., “OpenAI‑compatible” inference APIs, model format interoperability, ONNX/IRs, model weights portability, S3-like storage for model artifacts, fine‑tuning APIs) are central to enterprise adoption decisions and vendor market power. Mischaracterized compatibility claims can generate hidden lock‑in and enable market power even where many vendors ostensibly support the same API.
• How the five conditions translate to AI infrastructure and models
  • Boundary closure: For models/APIs the key production behaviors include not just call signatures, but output distributions, latency/throughput envelopes, failure modes, determinism/stability across versions, and behavioral guarantees (safety filters, moderation). A superficial API match (same endpoints) may not capture these.
  • Executable conformance: AI needs reproducible behavioral tests (benchmarks/tests for output quality, robustness, safety, latency under load) and versioned certification to avoid vendor claims that are only marketing.
  • Custody independence: Governance of model formats, metadata schemas (e.g., provenance, licensing tags), and conformance suites should be independent (foundations, multi‑stakeholder consortia) to prevent incumbents from shifting the spec.
  • State & operations reversibility: For models this covers moving weights, fine‑tuned checkpoints, training datasets or embeddings, feature stores, telemetry for model monitoring, and operational artifacts (inferencing pipelines, caching, sharding strategies). Reversibility is more complex than for object storage because of large binary state, licensing, and retraining requirements.
  • Extension quarantine: Proprietary inference features (server‑side pre/post‑processing, special instruction prompts, proprietary tokenizers, latency optimizations tied to vendor runtime) must be identified and isolated; otherwise, using them creates hidden switching costs.
• Market structure and competition
  • Where SET conditions are unmet, vendors can extract rents via hidden switching costs even in ostensibly open ecosystems; where SET is met, switching rights reduce incumbency rents and lower barriers to entry.
  • Investors should discount compatibility claims that lack SET gates when valuing vendor lock‑in and pricing exit options. Conversely, firms offering genuinely escrowed compatibility (certified, governed formats, easy state migration) may command a market premium in adoption but face more price competition.
• Pricing, procurement, and investment consequences
  • Value of escrowed compatibility is an option (real‑option value). Buyers will pay a premium for services that clear SET because it reduces expected switching costs and risk; vendors providing genuine portability may trade higher adoption for lower per‑customer rent extraction.
  • Procurement teams should require the five conditions as part of RFPs for AI infra/services (e.g., conformance evidence for model API behavior, custody‑independent model artifacts, migration runbooks).
• Policy and regulation
  • SET provides an operational buyer‑side test that complements legal/regulatory portability requirements (e.g., EU Data Act). Regulators can use SET as a checklist to judge whether mandated “functional equivalence” or portability obligations are meaningfully delivered.
  • Standards and certification bodies for AI (model formats, evaluation suites, provenance metadata) that achieve custody independence and executable conformance will materially affect competition and consumer welfare.
• Empirical research directions
  • Measure how SET satisfaction correlates with: realized switching incidence and cost, vendor pricing power, time‑to‑migrate, adoption rates, and enterprise willingness to adopt.
  • Quantify premium buyers pay for escrowed compatibility vs borrowed compatibility; estimate effects on entry and innovation.
  • Design and evaluate executable conformance suites for AI behavioral guarantees (robustness, safety, provenance).
• Practical checklist for AI stakeholders (quick application of SET)
  • Boundary: enumerate critical model behaviors (quality, latency, failure modes, safety) and check whether the compatibility claim covers them.
  • Conformance: insist on reproducible behavioral test suites and published certification artifacts.
  • Custody: verify who controls the spec/tests and whether governance is multi‑stakeholder.
  • State/ops: map what must move (weights, checkpoints, datasets, monitoring data, configs, runbooks) and whether migration is bounded and automatable.
  • Extensions: identify proprietary runtime or API extensions and require isolation or explicit labeling.

Overall, the SET reframes compatibility claims from marketing statements into buyer‑side, option‑valued objects. For AI economics, applying the five conditions can materially change market assessment, procurement practice, regulatory design, and investment valuation by revealing whether compatibility actually curtails vendor lock‑in or simply lowers short‑term integration cost.