This page captures the open questions and deliberate provocations that the Sovereign Tech Stack thesis needs to resolve. None of these are settled. They are framed as discussion prompts — to be argued with, not accepted.

If a position here makes you uncomfortable, that is the point. The wrong answer to any of these locks the venture into the wrong shape.

A. What’s the point of the Commonwealth?

The Commonwealth is a fact of British political and economic history. It is also, for most working purposes, a polite fiction — 56 countries with little operational coherence and almost no shared digital infrastructure. Yet it keeps appearing in UK strategy documents as if it represents a coherent market or a meaningful alliance.

For Sovereign Tech Stack, the Commonwealth question is sharp: does a UK certification mark have any reason to extend to Commonwealth-incorporated vendors? Australia, New Zealand, Canada, Singapore, India — each has its own tech industry, its own data jurisdiction, its own sovereignty calculus. Treating “Commonwealth” as a sovereignty extension axis would either dilute the UK standard to meaninglessness, or impose a UK-centric standard on countries that did not ask for it.

The alternative position: treat the Commonwealth as a network of bilateral relationships, not a bloc. If there is mutual interest with Canada (NATO, Five Eyes, similar data regimes), that is a Canada conversation — not a Commonwealth conversation. The word “Commonwealth” should probably be retired from sovereign tech vocabulary; it imports historical baggage without delivering operational clarity. The work is harder — bilateral conversations are slower than multilateral pronouncements — but the work is real.

Open for discussion: is the Commonwealth a useful frame for sovereign tech, a misleading one, or simply irrelevant? If we use the word, what specifically do we mean by it?

B. We love US tech when it’s thinking globally, positively

Sovereign Tech Stack is not anti-American. It is anti-default. The distinction matters.

There is a class of US-originated technology that thinks globally, embraces open standards, supports interoperability, and treats other jurisdictions as participants rather than markets to extract from. Linux. PostgreSQL. The Internet protocols themselves. Significant portions of the open-source ecosystem. Companies that publish open specifications, contribute upstream, and respect data residency as a design constraint rather than a compliance burden.

This is good US tech. It coexists with sovereignty. The UK does not need to replace these things — it needs to participate in them on its own terms.

The problem is the other class of US tech: products designed around US-controlled cloud infrastructure, US-jurisdiction data, opaque acquisition chains, lock-in by default, and a strategic posture that treats non-US users as a regulatory inconvenience. This is the class the certification standard exists to exclude. Not because it is American, but because it is structurally incompatible with anyone else’s sovereignty.

The framing matters because the alternative — reflexive technological nationalism — produces worse outcomes than the problem it claims to solve. The UK needs a stack that is sovereign and plugged into the best of what the world builds. Those two things are compatible. They are not the same thing.

Open for discussion: how do we articulate this distinction in a way that survives both political opportunism and oversimplification? The “Buy British” frame is too crude; the “open and sovereign” frame may be too nuanced for a SME buyer.

C. But how deep in the stack do we go?

A sovereign technology stack can be defined at many depths. At the shallowest, it is a SaaS curation exercise — replacing American applications with British ones at the application layer, while the underlying compute remains AWS, the chips remain Taiwanese, and the cables remain American-controlled.

At the deepest, it is a national industrial strategy: UK-owned fabs, UK-controlled compute, UK-routed networking, UK-trained foundation models, all the way down to the silicon and the energy that powers it. This is the position taken by the most ambitious sovereign tech advocates. It is also, for Sovereign Tech Stack as a commercial venture, an obviously infeasible scope.

The practical question is where on this spectrum the certification mark sits. SaaS-only is too shallow — it ignores the dependencies that determine real sovereignty. Down-to-the-fab is too deep — there is no commercial path there in any timeframe that matters. The interesting answer is somewhere in between, and it is genuinely undecided.

Some candidate positions:

  • Application + data residency only — certify SaaS vendors that are UK-owned and UK-data-resident, regardless of underlying infrastructure. Pragmatic, scalable, weak.
  • Application + infrastructure — additionally require UK-owned hosting and compute. Tighter, but excludes most vendors today because the UK-owned cloud layer is thin.
  • Application + infrastructure + supply chain transparency — vendors must disclose their full stack, with a clear roadmap to UK-owned alternatives where current dependencies are American. Realistic and progressive, but harder to audit.
  • Tiered certification — a Bronze / Silver / Gold structure that reflects depth. Allows the standard to evolve without resetting the mark each time.

Each position has a different strategic consequence. The shallowest version is easiest to launch but weakest as a moat. The deepest is most defensible but excludes almost everyone today.

Open for discussion: what depth is honest about what sovereignty means, while still leaving a commercially-viable certification surface?

What this page is for

The Sovereign Tech Stack thesis is not a finished document. It is being argued out in public — selectively, with people whose pushback improves it. If you have a view on any of these, the conversation is open. Disagreement is more useful than agreement at this stage.