Skip to main content
Reality Oracle
OverviewCitizensReality FeedVerified ActorsIntel SubscribersMarket PredictionInvestment FundsHow It WorksGates
Products
Backtest ForensicsLiving MapDrift AlertsPath QueriesCustom AxesRisk Maps
Solutions
Compliance OfficersRisk Managers / CROPortfolio ManagersCTOs & Engineering
Enterprise
Enterprise OverviewReality Oracle · SuperappThe AppsArchitectureAudit ManifestTrust CenterPricing
Developers
DocumentationAPI ReferenceSDKsArchitectureAudit Manifest
Resources
BlogUse CasesCustomer StoriesPressChangelog
Company
AboutFoundersCareersContact
Trust
Trust Center
More
PricingJoin Waitlist
··10 min read

Vendor lock-in is a compliance risk

Provider-agnostic as an audit posture — the manifest survives the vendor.

Vendor lock-in is a compliance risk

Vendor lock-in is usually framed as a commercial problem. In regulated AI, it is a compliance problem — because the manifest has to survive the vendor, and a manifest that dies with the vendor is a manifest that fails the audit window.

Lock-in is a commercial concern in most of software; in regulated AI it is a compliance concern, because the record has to outlive the relationship. A firm that built its audit record inside a vendor’s proprietary format, on a vendor’s proprietary chain, with a vendor’s proprietary replay tool, has a record that survives only as long as the vendor does — and vendors are not permanent. The manifest has to survive the vendor; the way it survives is that it is provider-agnostic and the replay is a property of the substrate, not the supplier.

Provider-agnostic as a posture

DEINO is provider-agnostic by design on the model side — OpenAI-compatible only, which covers OpenAI, vLLM, OpenRouter, Together, and any compatible endpoint, with no direct Anthropic SDK dependency. The manifest pins the model by hash, not by name, so the historical record verifies against the historical model even after the live model is swapped. The provenance is provider-agnostic; the chain does not care which provider produced the bytes, only that the bytes are the bytes. A firm that changes providers keeps its history; a firm that locked its history to a provider’s proprietary format loses it.

The manifest survives the vendor: the model is hash-pinned, the chain is provider-agnostic, the replay is a property of the substrate. The vendor can change; the record does not.
The manifest survives the vendor: the model is hash-pinned, the chain is provider-agnostic, the replay is a property of the substrate. The vendor can change; the record does not.

Why lock-in fails the audit window

The audit window is long; vendor relationships are not. A decision reviewed in October may have been made in January with a model from a provider the firm has since left, on a chain the vendor hosted, in a format the vendor owned. If the record dies with the contract, the firm cannot answer the October review — and "the vendor went away" is not a defense an examiner accepts. The provider-agnostic manifest is the answer: the firm holds its own chain, its own hashes, its own replay anchor, and the vendor’s departure removes nothing from the record.

The manifest has to survive the vendor. A record that dies with the contract is a record that fails the audit window — and "the vendor went away" is not a defense.

The tiers and provider-agnosticism

The binding tier does not mandate provider-agnosticism directly, but it reaches for the same property. The EU AI Act (binding law) requires logging that survives the system’s lifetime — which a vendor-locked format does not guarantee. SR 11-7 (supervisory guidance) expects model risk records to be retrievable across the model’s life, including after vendor changes. NIST AI RMF and ISO/IEC 42001 (voluntary) document lifecycle governance that implies portability. None of them say "be provider-agnostic"; all of them require the property that provider-agnosticism delivers — a record that outlives the supplier. Building to the property is how a firm meets all three at once.

  • Provider-agnostic on models (OpenAI-compatible, no direct Anthropic SDK) — the manifest pins by hash, not by name.
  • The chain is provider-agnostic; the record survives the vendor change.
  • The binding tier requires record durability, which vendor lock-in cannot guarantee.
  • The firm holds its own chain, hashes, and replay anchor — the vendor’s departure removes nothing.

What provider-agnostic does not promise

Provider-agnostic does not promise the forecasts are accurate; it promises the record is portable, which is a different and more defensible claim. Accuracy is a calibration loop gated by Gate 1 (reproducibility) and Gate 1b (beat a disclosed baseline on one series), and we are pre-revenue, building the POC. The manifest attests provenance and reproducibility, not truth — Certified ≠ True — and portability is part of reproducibility: a record that cannot be replayed without the original vendor is not reproducible, no matter what the bytes say. The provider-agnostic substrate is what makes the replay claim survive the relationship.

Vendor lock-in is a commercial problem everywhere else. In regulated AI it is a compliance problem, because the record has to outlive the vendor — and a record that outlives the vendor is a record that was never locked in.

— provider posture note
§Keep reading