A full month before DAAC had a name, before there was a suite, before there was even a second product to put beside the first, I sat down and wrote a document with an uncomfortable question at its centre: what happens to a client if we disappear tomorrow?
Every serious buyer in the environments we work in asks some version of that question, whether out loud or in the way they structure a contract. They operate in low-governance, institutionally fragile places, and most of them have already been burned once by a vendor that locked them in, raised prices, or simply walked away with their operational continuity in its pocket. If the honest answer to "what happens if you disappear" is "you lose everything," the deal does not close. It should not close.
The tension I had to resolve was real, not rhetorical. Our framework is also our competitive advantage. It is what lets us build fast, consistently, securely. Open-source the whole thing and the advantage disappears. Lock every client permanently to our infrastructure and the sovereignty promise is empty. The way through was not a compromise between those two positions. It was a realisation that they were never actually in tension: give every client real, enforceable independence over their own application, while keeping the underlying framework as our own maintained asset. Ownership of the framework and freedom for the client are different things, and confusing them is what makes the tradeoff feel forced.
The insight underneath the insight is the one I still think about most. Our moat was never client lock-in. It was speed. If a client can leave at any moment with everything they need, and chooses to stay because we build and maintain faster than anyone else could, that is a stronger commercial position than one built on making leaving expensive. Sovereignty, properly built, is aligned with the business model. It is not a tax on it.
I laid out six layers that make the commitment real rather than a marketing line. Data portability first, because without it nothing else matters: a client can export everything, at will, not only on the way out, in open formats with the schema included, because a column of numbers means nothing without the definition of what the numbers are. Configuration portability, because in this model the application is its configuration, and the client should own that artefact outright, transferable to their own infrastructure without engineering rework. Operational knowledge portability: a runbook, a handover guide written for an engineer who has never seen our system before, a decision log capturing why the app is configured the way it is, so a client never drifts from their own intent without knowing it. Source escrow with a neutral third party and defined release triggers, the standard enterprise answer to vendor risk, applied here as a default clause rather than a negotiated concession. Licensed read access, for institutions whose procurement processes demand it before any escrow trigger fires. And the most radical one, aspirational when I wrote it and still mostly aspirational now: a single command that ejects a client's app entirely, producing a standalone codebase they could run without us, ever again, forever.
I want to be precise about what I was and was not claiming that day. Sovereignty is not a soft commitment or a posture struck for procurement reviewers. It is a verifiable property, built into the architecture, the deliverables, and the contract. And I want to be equally precise about the timing, because it matters to the story this whole series is telling: this was written down as its own principle a full month before I had any reason to think it would become one of the words people now assume some later, cleverer positioning exercise invented. It was never marketing. It was the operating principle first; the word for it came out of actually needing to answer a hard question a client would eventually ask, and the suite that carries the word today inherited it rather than coined it.