No Single Point of Failure

Principle IX: No Single Point of Failure

No vendor lock-in; no single point of failure.

Every dependency is a bet. Every vendor relationship is a bet. Every API you integrate is a bet that the provider will continue to exist, continue to offer acceptable terms, and continue to not make breaking changes on a Tuesday afternoon. Some of these bets are good. None of them should be irreversible.

The Abstraction Requirement

Obsidian treats every external dependency as replaceable. Not “replaceable in theory, if we had six months and a rewrite budget” — replaceable in practice, with a configuration change and a restart. This means every provider interaction goes through an abstraction layer. Every model call is routed through an interface that does not know or care which model is behind it.

This is not over-engineering. This is survival. The model landscape changes monthly. Providers raise prices, deprecate endpoints, alter rate limits, and occasionally cease to exist entirely. A system that is coupled to a single provider is a system that has outsourced its reliability to someone else’s business decisions.

Multiple Escape Routes

The rule is simple: before accepting any dependency, Obsidian requires that at least two alternative providers exist and have been validated. Not “could theoretically work” — validated. Tested. Measured. The failover path must be as well-understood as the primary path, because at some point the failover path will be the primary path.

This applies to models, to infrastructure, to storage, to every component that is not under direct Obsidian control. The Warden itself is designed to be reconstructable from persisted state — because even the constitutional guardian is not exempt from the principle it enforces.

The Dynamic Model Landscape

Language models are not commodities — they have meaningfully different capabilities, latencies, and cost profiles. But they are also not unique snowflakes. Obsidian treats models as a heterogeneous pool, routing requests based on capability requirements, cost constraints, and measured performance. If one model degrades, traffic shifts. If a provider fails, the system continues.

This dynamic routing is not just a resilience mechanism. It is an optimization mechanism. The best model for a task today may not be the best model tomorrow. A system that can adapt to that reality without code changes is a system that improves automatically.

Implications

Every integration in Obsidian has a provider interface and at least one alternative implementation. Every agent capability that depends on an external service must declare that dependency explicitly. The system must be deployable — not just theoretically functional — with any single provider removed.

Relationship to Other Principles

This principle operationalizes Survival by Design (Principle IV) at the dependency level. It requires Observable by Default (Principle V) to detect provider degradation. And it works with Production Reality (Principle X) to ensure that failover decisions are based on measured performance, not assumed capability.