Every dependency you do not own is a decision someone else gets to make for you. That is not inherently a problem — dependencies are how complex systems get built at all. No serious software project is built entirely from scratch, and the attempt to do so is usually a waste of resources and a source of new problems rather than a solution to existing ones.
The question is not whether to take on dependencies. It is which ones to take on, with clear understanding of what you are trading away when you do.
Dependency as control risk
When developers evaluate dependencies, the usual framework is technical: is this library well-maintained? Is it performant? Does it integrate cleanly with the rest of the stack? These are reasonable questions. They are also incomplete.
There is another category of risk that gets less attention: control risk. Who can change this dependency unilaterally, and what would that change cost me? A pricing model change. A policy update. A deprecated API. A strategic pivot by the company providing the service. These are not hypothetical events — they happen regularly, and when they happen to a load-bearing dependency, the cost of responding is often much higher than the cost of having made a different choice earlier.
The companies and developers who have thought about this tend to have a clearer sense of which dependencies are acceptable and which are not. The acceptable ones are stable, commodity, and cheap to replace. The unacceptable ones are load-bearing, unique, and expensive to replace — especially if the entity providing them has interests that may not always align with yours.
Sovereignty as an architectural principle means making this distinction deliberately, at the design stage, rather than discovering it under pressure when something changes.
What load-bearing actually means
Not every dependency carries the same weight. A logging library is a dependency. So is the intelligence layer of a system designed to reason over everything a person knows and does. These are not equivalent in terms of what you lose if they change or disappear.
The way I think about it: a dependency is load-bearing when two conditions are true. First, it is deeply integrated — removing it would require rethinking a significant part of the system, not just swapping one component for another. Second, it is central to what the system is for — not infrastructure that supports the product, but infrastructure that is the product.
When a dependency is both deeply integrated and central to the system's purpose, treating it as someone else's responsibility is an architectural choice with long-term consequences. It is not wrong, necessarily. But it should be made with clear eyes about what that choice means.
For Aether, the intelligence layer — the model that reasons over a person's knowledge, proposes actions, and engages with the governance layer — is load-bearing in exactly this sense. It is deeply integrated, it is central to what the system does, and its behavior shapes everything that happens downstream of it. Leaving that permanently in the hands of an external provider is a choice I am not willing to make.
The Una model track
This is why the intelligence layer in Aether is designed with a deliberate migration path rather than a permanent external dependency. Una v0 uses a configurable external provider — either the Anthropic API or a local Ollama instance. That is a pragmatic starting point. It allows the system to be built and tested without requiring a model training program at the outset, when there are a hundred other things to get right.
But the design always anticipated v1: a fine-tuned model on an open base, self-hosted, permanently closing the external dependency. Not because external providers are untrustworthy — they are not — but because an intelligence layer that deeply integrated and that central to the system's purpose should not live on a foundation that someone else controls indefinitely.
The transition has clear trigger conditions. It happens when there is sufficient usage data to fine-tune meaningfully, and when the governed engine has demonstrated that the rest of the system is stable. It is not a reaction to anything going wrong. It is the completion of a plan that was part of the architecture from the beginning.
The broader principle
Owning the stack is not an ideology. It is not a rejection of collaboration, external infrastructure, or the efficiencies that come from building on what others have built. It is a framework for making dependency decisions with appropriate seriousness — understanding what you are trading away, deciding whether that trade is worth making, and having a plan for the cases where the terms of the trade change.
For commodity infrastructure — databases, networking, standard tooling — external dependencies are almost always the right choice. The cost of owning those things yourself is high, the benefit is low, and the risk of the dependency changing in ways that harm you is manageable.
For the things that are central to what your system is and does — the parts that, if they changed, would change what you are building in fundamental ways — the calculus is different. Those are the parts worth thinking hard about. Those are the parts where sovereignty has real meaning.
The goal is not to own everything. It is to own what matters, to understand what you are depending on and why, and to make those choices consciously rather than by default.