Source-linked AI summary
The Substitution Escrow Threshold: When "Compatible With" Becomes Safe Enough to Buy
Amadeus Brandes
TL;DR
Enterprise buyers need to know when a compatibility claim creates a credible future substitution option rather than merely lowering integration cost. The paper introduces the Substitution Escrow Threshold, applies it to infrastructure cases, and concludes that compatibility reduces institutional risk only when the substitution path is bounded, testable, governed, reversible, and protected from extension drift.
Problem
Compatibility claims can reduce integration cost without establishing a credible production exit option for institutions evaluating vendor exposure.
Method
The paper introduces a five-condition Substitution Escrow Threshold and applies it to infrastructure compatibility cases using independently testable, governed, and operationally reversible boundaries.
Results
OCI provides the strongest procurement-grade case, while Kubernetes, OpenTelemetry, S3, and PostgreSQL compatibility escrow narrower or exposed substitution boundaries.
Takeaways & Limitations
Compatibility should receive procurement credit as future exit protection only when the claim can be bounded, tested, governed, operationally reversed, and protected from extension drift.
Takeaways & Limitations
The framework does not establish production substitution when workload-specific schema, extensions, behavior, operations, performance, and failure semantics remain unvalidated.
Abstract
from arXiv · showhide
Enterprise infrastructure buyers routinely evaluate compatibility claims--"S3-compatible," "PostgreSQL-compatible," "OpenAI compatible"--as proxies for future substitution options. Yet most compatibility claims do not escrow the substitution path they imply. This paper introduces the Substitution Escrow Threshold, a five-condition framework that determines when a compatibility claim genuinely reduces institutional risk versus merely reducing first-integration cost. The five conditions--boundary closure, executable conformance, custody independence, state and operations reversibility, and extension quarantine--are applied to five infrastructure cases (OCI, Kubernetes, OpenTelemetry, S3, PostgreSQL) that populate five distinct outcome cells. The framework produces actionable diagnostics for enterprise architects, platform engineers, procurement teams, and investors evaluating compatibility-dependent infrastructure decisions, and identifies AI infrastructure as the framework's most urgent next application.
1. The Observed Puzzle: Same Promise, Different Institutional Weight
Compatibility claims address the same demand for reduced vendor exposure, but their institutional value diverges because each governs a different boundary and supports a different degree of substitution. The paper therefore distinguishes integration convenience from procurement-grade portability.
- OCI: OCI compatibility is procurement-grade because open governance and certification make its artifact and runtime boundary narrow, testable, and evidence-producing.Certification requires product testing, published test processes and results, peer verification, and passing certification.
- Kubernetes: Kubernetes conformance supports interoperability at the required API core but does not establish portability across managed-service dependencies.Identity, storage, networking, ingress, add-ons, observability, upgrades, and operating models remain outside the conformance claim.
- OpenTelemetry: OpenTelemetry creates a narrow escape hatch for instrumentation and telemetry export, while dashboards, queries, alerts, retention, workflows, and historical data remain non-portable.The vendor-neutral boundary covers APIs, SDKs, OTLP, semantic conventions, and Collector-based export, not the full observability operating model.
- S3: S3 compatibility is operationally valuable but remains borrowed compatibility because implementations rely on a vendor-controlled reference interface and document feature differences.Procurement-grade portability still requires workload-specific validation and a known boundary.
- PostgreSQL: PostgreSQL compatibility accelerates evaluation or onboarding without proving production substitutability across schema, extensions, behavior, operations, performance, and failure semantics.Protocol and syntax compatibility are only parts of the production dependency.
- Institutional meaning: Compatibility is a property of a future supplier or platform decision, not merely a property of software or an API.The relevant question is whether changing supplier, runtime, backend, region, deployment model, or operating team avoids a bespoke migration program.
3. Scope
The framework applies to infrastructure compatibility claims used to reduce institutional exposure, while excluding ordinary convenience integrations and cases where compatibility is not being used as a risk-reduction argument.
- Scope: The Substitution Escrow Threshold evaluates compatibility claims across infrastructure control points such as container artifacts, orchestration APIs, telemetry pipelines, storage APIs, databases, and AI-serving APIs.Its object is compatibility used to reduce exposure across vendors, implementations, deployment models, or managed services.
- Exclusions: The framework excludes ordinary SDK convenience, one-off adapters, UI-level import/export, application file exchange, generic benchmark claims, and non-risk-reduction uses of compatibility.These cases fall outside the framework’s stated decision problem.
- Decision boundary: The framework does not claim compatibility is the only reason to adopt a system, since buyers may rationally prefer proprietary services for operational, economic, safety, strategic, or commercial reasons.Its narrower question is how much procurement credit a compatibility claim should receive as a future exit right.
4. The Parent Mechanism
A technical interface becomes procurement-relevant when it places part of the buyer’s future substitution path outside the vendor’s discretionary control. This turns compatibility from a vendor promise into an inspectable institutional option.
- Mechanism: Stable interfaces reduce dependency by separating one infrastructure layer from another through modularity, standards, conformance testing, and interface discipline.The paper treats the institutional version as more specific than technical modularity alone.
- Mechanism: A compatibility boundary becomes procurement-relevant when buyers can identify governed boundaries and evidence that supports future substitution without relying solely on the vendor’s claim.The mechanism moves part of the substitution path outside vendor discretion.
5. Related Work
The paper combines standards economics, software-interface stability, sourcing research, and portability regulation to formulate a buyer-side decision rule for compatibility claims. Its contribution is to score an individual claim as an exit option rather than merely describe lock-in or migration difficulty.
- Compatibility economics: Compatibility and standards economics explains network effects, path dependence, de jure versus de facto standards, and switching costs, but not when procurement should credit a vendor claim as an exit option.The framework recasts governed versus dominant-implementation compatibility in procurement terms.
- Interface stability: Software-engineering research shows that declared version semantics can be unreliable proxies for behavior that moves without rework.The paper generalizes this boundary problem from package ecosystems to substitution across vendors, deployment models, and managed services.
- IT sourcing: IT-sourcing and cloud-migration research establishes vendor dependence and switching cost as procurement risks but largely lacks a test for when a specific compatibility claim becomes a credible exit option.The paper evaluates an individual compatible-with claim rather than an entire service or migration program.
- Conceptual distinction: The paper distinguishes compatibility escrow from literal software escrow, which releases source code after triggers such as bankruptcy or abandonment.Compatibility escrow denotes a standing substitution path rather than a continuity mechanism triggered by vendor failure.
- Regulatory context: Standards and regulatory instruments, including ISO/IEC 19941, GDPR Article 20, and the EU Data Act, provide related interoperability or portability contexts for procurement decisions.These instruments shape the surrounding apparatus but are distinct from the paper’s buyer-side test for compatibility claims.
6. The Framework: Five Conditions
The Substitution Escrow Threshold requires compatibility claims to function as governed exit options, not merely vendor assertions. Its five conditions test whether the boundary is complete, independently testable and governed, operationally reversible, and protected from extension drift.
- Threshold conditions: A compatibility claim crosses the threshold when it satisfies five conditions strongly enough to become a governed exit option.The conditions are boundary closure, executable conformance, custody independence, state and operations reversibility, and extension quarantine.
- Boundary closure: Boundary closure measures whether the compatibility contract covers the production behaviors the workload relies on.The top-twenty-behaviors test distinguishes dependencies inside the contract from implementation details, extensions, undocumented semantics, and operational tooling.
- Executable conformance: Executable conformance requires a versioned test suite, certification process, or reproducible validation procedure that parties other than the vendor can run.Conformance evidence can enter architecture review, security admission control, and procurement decisions, although it does not prove operational quality.
- Custody independence: Custody independence requires that the compatibility contract not be reducible to one provider’s roadmap or unilateral control.OCI, Kubernetes, and OpenTelemetry have external governance structures, while S3 lacks an equivalently established neutral conformance process in the cited record.
- State and operations reversibility: State and operations reversibility asks whether real production assets, configuration, policy, and operating procedures can move within a bounded program.Kubernetes API conformance does not by itself make managed-service IAM, storage, upgrades, observability, policies, and runbooks portable.
- Case implications: Compatibility outcomes remain workload-specific because OCI, OpenTelemetry, S3, and PostgreSQL cover different boundaries and operational dependencies.OCI supports artifact/runtime portability; OpenTelemetry decouples instrumentation and telemetry export; S3 requires workload profiling; PostgreSQL substitutability depends on schema, queries, extensions, transactions, distribution, and operations.
7. The Decision Structure
The decision structure distinguishes five institutional outcomes according to how much of the substitution path is governed and portable. Compatibility can reduce integration cost or accelerate evaluation without materially reducing assessed vendor exposure.
- Outcome cells: The framework produces five institutional outcomes for compatibility-dependent infrastructure decisions.These outcomes distinguish fully escrowed compatibility from narrower or vendor-dependent forms of compatibility.
- Escrowed compatibility: Escrowed compatibility closes the boundary, makes conformance executable, keeps custody independent, reverses state and operations, and quarantines extensions.Its core is governed and testable, while the exposed perimeter is controlled separately.
- Narrow escape hatch: Narrow escape-hatch compatibility standardizes a deliberately limited, vendor-neutral layer rather than promising full platform portability.This outcome captures compatibility that is valuable within a constrained boundary.
- Borrowed and onboarding compatibility: Borrowed compatibility describes a widely implemented vendor-originated API lacking independent governance or a neutral conformance program.Onboarding compatibility goes further only at the syntax or protocol layer; semantic state and operations remain workload-specific.
- Decision rule: Compatibility changes institutional risk only when it escrows the buyer’s future substitution path; otherwise it may improve bargaining position without materially reducing vendor exposure.The same claim can still reduce integration cost or accelerate evaluation, but those benefits do not receive full exit credit.
8. Case Matrix
The case matrix distinguishes compatibility claims by the boundary they govern and the evidence, custody, reversibility, and extension controls supporting substitution. OCI is procurement-grade within a narrow artifact/runtime/distribution boundary; Kubernetes and OpenTelemetry escrow narrower cores, while S3 and PostgreSQL require workload-specific validation.
- OCI: OCI provides high substitution value within an explicit image, runtime, and distribution boundary, without claiming full platform portability.Its boundary is independently governed through open industry standards, and certification supplies published testing, peer verification, and pass-based certification.
- PostgreSQL: PostgreSQL compatibility is medium-low for production substitution because protocol and syntax compatibility do not establish workload behavior.Schema, extensions, planner assumptions, transactions, operations, backups, performance, and failure semantics require actual-workload validation.
- Scope: The five cases form an analytic typology rather than a validation corpus, so the assignments require future evidence from procurement artifacts, migrations, conformance records, and workload tests.A validation study would need independently coded evidence across multiple institutions.
- Kubernetes: Kubernetes conformance supports a governed and testable core API, but production portability remains exposed to provider and organization-specific dependencies.Those dependencies include IAM, storage, ingress, observability, upgrades, backups, and incident operations; extensions require a portability ledger to quarantine them.
- OpenTelemetry: OpenTelemetry is a narrow, vendor-neutral escape hatch that strongly decouples instrumentation and telemetry transport but does not make observability backends substitutable.Dashboards, queries, alerts, retention, incident workflows, RBAC, billing, and historical data remain outside its boundary.
- S3: S3 compatibility offers practical integration and rewrite-risk benefits, but its borrowed, AWS-controlled interface lacks neutral conformance and requires tested workload profiles for exit credit.Object data may be movable, while lifecycle, IAM, encryption, replication, consistency, residency, cost, and other operational behaviors remain workload-specific.
9. Similar Outcomes, Different Mechanisms
Similar compatibility outcomes arise from different mechanisms: OCI relies on escrow and certification, while S3 relies on ubiquity and support; Kubernetes and OpenTelemetry protect narrower layers, and database portability remains workload-specific.
- Different mechanisms: OCI and S3 both reduce vendor exposure, but only OCI generally merits procurement-grade credit without workload profiling.OCI combines independent custody, explicit specifications, and certification; S3 depends on implementation support against AWS’s reference API.
- Different mechanisms: Kubernetes conformance secures a certified orchestration API core while leaving managed-service perimeter migration exposed.Identity, storage, networking, ingress, add-ons, observability, upgrades, and operating models remain outside the certified surface.
- Different mechanisms: OpenTelemetry reduces lock-in at instrumentation and telemetry export, while observability workflows remain exposed.Backend changes can still require work on dashboards, queries, alerts, retention, incident workflows, and historical data.
- Different mechanisms: S3 and PostgreSQL compatibility both avoid immediate rewrites, but database substitutability is more semantic, workload-specific, and operationally entangled.The same dominant-interface compatibility claim therefore carries different procurement meaning across object storage and databases.
- Different mechanisms: Procurement should evaluate compatibility by the production boundary it governs rather than by API familiarity or ecosystem size.Kubernetes has executable conformance, whereas PostgreSQL compatibility is typically documentation plus workload assessment.
10. Strategic Implications
The framework shifts compatibility assessment from a binary product attribute to a layer-specific question about which future decision becomes cheaper and what evidence supports that claim.
- Strategic Implications: Buyers should ask which future decision a compatibility claim makes cheaper, rather than whether the product is simply compatible.The answer differs by layer: OCI supports compliant artifact changes, Kubernetes the certified API core, OpenTelemetry telemetry export, S3 tested operations, and PostgreSQL evaluation or partial migration.
- Strategic Implications: Procurement should assign compatibility credit by layer because one platform can be portable in artifacts but proprietary in identity, data, or operations.A single open-or-compatible risk field obscures where dependency actually remains.
- Strategic Implications: Foundations should treat conformance as a product by producing evidence usable in architecture, procurement, security, and risk reviews.A README alone does not provide the decision evidence required to cross the threshold.
- Strategic Implications: Compatibility reallocates dependency rather than eliminating it: OpenTelemetry shifts it toward backend workflows, while Kubernetes shifts it toward the managed-service perimeter.OCI moves artifact lock-in into surrounding platform, supply-chain, and operational choices.
- Strategic Implications: Security teams should treat executable compatibility as an evidence boundary, borrowed compatibility as workload-profile dependent, and onboarding compatibility as unproven until validated.This converts compatibility claims into differentiated control requirements.
11. What the Framework Predicts
The framework predicts differentiated enterprise treatment: OCI will remain baseline, Kubernetes necessary but insufficient, OpenTelemetry stronger for instrumentation than backends, S3 increasingly profile-based, and PostgreSQL compatibility evaluation-oriented.
- What the Framework Predicts: OCI-compatible artifact requirements will continue appearing as baseline platform and supply-chain controls.The prediction rests on a narrow, independently governed boundary supported by certification evidence.
- What the Framework Predicts: Certified Kubernetes will remain necessary but insufficient for migration risk reduction.Buyer diligence is expected to continue around storage, identity, networking, add-ons, upgrades, observability, policy, and runbooks.
- What the Framework Predicts: OpenTelemetry will reduce instrumentation lock-in more than observability-backend lock-in.Backend migration is expected to retain work beyond endpoint changes, including dashboards, queries, alerts, retention, workflows, and historical data.
- What the Framework Predicts: S3-compatible procurement will become increasingly profile-based rather than accepting compatibility as a binary claim.Relevant profiles include operations, object lock, replication, IAM, lifecycle, encryption, eventing, and failure semantics.
- What the Framework Predicts: PostgreSQL-compatible distributed databases will continue winning evaluations through ecosystem familiarity while requiring workload-level certification for production substitution.Migration tools, unsupported-feature lists, extension matrices, schema guidance, and distributed-data documentation remain confirming signals.
12. Where the Framework Ends
The framework is a narrow tool for pricing substitution risk, not a universal preference for escrowed compatibility or a replacement for evaluating proprietary operational advantages.
- Where the Framework Ends: The framework does not imply that buyers should always prefer escrowed compatibility over proprietary systems or managed services.Operational superiority, support, security, cost, and integration depth may outweigh substitutability concerns.
- Where the Framework Ends: Compatibility escrow is unnecessary when exit is irrelevant or value depends on proprietary data, workflow effects, or managed operational excellence.In those settings, the framework is secondary.
- Where the Framework Ends: The framework’s purpose is to prevent institutions from awarding compatibility credit beyond the future decision it actually makes cheaper.Its scope is decision pricing, not a general ranking of infrastructure products.
- Where the Framework Ends: The framework is falsifiable if low-scoring claims routinely enable low-cost substitution, high-scoring claims fail bounded migration, or cases stop separating outcome cells.These observations would show that the threshold misprices risk, is set incorrectly, or has become mere bookkeeping.
13. The Next Test: AI Compatibility Claims
AI compatibility claims are multiplying faster than conformance evidence, making AI infrastructure the framework’s most urgent next stress test. The paper argues that endpoint and platform compatibility should not count as production substitutability until boundary, conformance, custody, reversibility, and extension drift are tested.
- AI infrastructure is the framework’s most urgent next stress test because compatibility claims are multiplying faster than conformance evidence.
- Existing AI claims include OpenAI-shaped servers and gateways, MCP, vector-database APIs, and model-serving or evaluation-harness compatibility claims.
- These interfaces may reduce application rewrites, agent-tool integration friction, or client integration cost, but they do not by themselves establish production substitutability.
- Endpoint mimicry is easy, while behavioral substitutability requires accounting for model behavior, latency, context handling, tool calling, structured outputs, safety, evaluation, costs, retention, and incidents.
- Compatibility claims should be priced according to how much of the future substitution decision they place into escrow rather than treated as virtues in themselves.