The Sovereign Stack: White Paper

A proposal to DG CONNECT (Directorate-General for Communications Networks, Content and Technology)

Establishing digital primitives: standard, interoperable, scalable tools for a faster, cheaper, better digital economy.

Version: 1.0 Draft Date: February 2026 Contact: richard@buckden.io

Abstract

Digital fragmentation costs Europe €400 billion annually, with 40% of IT budgets consumed by integration overhead, while citizens juggle an average of 100 passwords across incompatible systems that refuse to talk to each other. The EU Digital Identity Wallet arrives in December 2026, but without addressing the underlying fragmentation of our digital infrastructure, we will simply add another layer to an already fractured ecosystem. The Sovereign Stack proposes a radical simplification: establishing common digital primitives, standardised, interoperable building blocks for identity, data, APIs, and services, that allow Europe to build once and deploy everywhere, transforming digital waste into digital prosperity.

This white paper outlines the rationale, technical framework, governance model, and a concrete pilot programme: building the The Sovereign Stack stack by enhancing a real local service in partnership with a local authority, a private sector partner, and an academic institution, with FrankMail, a sovereign citizen email service, as the first follow-on application.

Contents

1. WHY: The Rationale and Principles
2. WHAT: The Technology Framework
3. HOW: Governance, Funding and Certification
4. WHERE: The Pilot
5. Appendices

1. WHY: The Rationale and Principles

1.1 From Adolescence to Adulthood

Europe, and the wider community of nations that share open values, helped lead the world from the infancy of the digital revolution into its adolescence. From packet switching (Davies, UK), smart cards (Moreno, France), the World Wide Web (Berners-Lee, CERN), Linux (Torvalds, Finland), GSM mobile standards (ETSI, France), to MP3 (Fraunhofer, Germany) and JavaScript’s ongoing maturation through ECMA (Geneva), Europe provided foundational technologies that connected millions, made information more accessible than ever, and created new markets in the process.

But adolescence is not adulthood. The digital economy has grown in pockets, with capabilities concentrated in too few places and without a shared framework for how its core components should interoperate. This lack of coordination, compounded by fragmentation and constantly shifting standards, creates waste, slows innovation, and prevents us from realising the full efficiency and growth potential the technology could deliver.

For citizens and businesses, the impact is clear:

• The password nightmare of endless logins and resets undermines security and productivity
• The constant flow of spam email wastes time and resources despite decades of countermeasures
• The frustration of incompatible platforms forces people to juggle systems that should simply work together

For builders and providers, the challenges are just as real:

• Switching costs make every migration or integration disproportionately complex
• Shifting frameworks create constant churn, forcing costly rewrites instead of lasting innovation
• Fragmented skill sets, too many Digital Dialects, produce incompatible stacks and scattered expertise

The result is lower quality, reduced efficiency, and higher costs across the board.

1.2 Opportunities

1. Eliminate waste and duplication – Interoperable standards replace repeated logins, APIs, and formats, cutting inefficiency at the root.
2. Raise quality and resilience – Simplified stacks and common skills reduce bugs, downtime, and fractured user experiences.
3. Refocus talent on innovation – Free developers from switching costs and framework churn so they can build, not just patch.
4. Scale AI as an everyday assistant – Open AI connectors support coding, analysis, and services, making advanced capability routine.
5. Increase competitiveness – Lower barriers for SMEs and reduce integration costs while keeping incumbents under healthy pressure.
6. Streamline government and enterprise services – Interoperability from day one cuts costs, reduces duplication, and speeds delivery.

1.3 Five Guiding Principles

1. Citizen Sovereignty – Users own their identity and data. No lock-in, no surveillance, no selling attention.
2. Interoperability by Default – Services, data, and identity work across providers, sectors, and borders; no custom integration required.
3. AI-Ready Architecture – Machine-readable specifications, standardised patterns, and comprehensive test coverage enable AI-assisted development at pace.
4. Open Standards, Open Competition – Transparent technology on a level playing field, lowering barriers for SMEs while keeping incumbents under healthy pressure.
5. Build Once, Deploy Everywhere – Common digital primitives for identity, data, APIs, and services. Every project starts from a working foundation, not from scratch.

1.4 Why Now

The case for The Sovereign Stack is not abstract; it is economic, urgent, and measurable.

Most of the components already exist in open form. The challenge is integration, not invention. Yet without coordination, the cost of fragmentation grows exponentially as more citizens come online and more services become digital.

The evidence:

• 20–40% of IT budgets are consumed by technical debt and rework, projects slowed by incompatible frameworks, duplicated APIs, and diverging skill sets (Gartner, 2022)
• 40–50% of engineering effort is spent on integration and rework rather than new value (McKinsey, 2020)
• Global IT spend will exceed $5 trillion by 2025, meaning hundreds of billions of euros wasted annually in duplication (IDC, 2023)
• €55 billion in annual losses to cybercrime, much linked to fragmented identity and access systems (European Commission, 2020)
• $150–200 per employee, per year wasted on password management alone (Ponemon Institute, 2021)
• 40% of digital transformation delays stem from identity and authentication challenges (UK Cabinet Office, 2022)
• €400 billion annual opportunity cost if Europe fails to scale digital adoption and sovereignty (EU Digital Compass, 2021)

The situation is like a transport system without shared rules. Today, digital services resemble roads with different widths, signs, and driving laws: they work locally but break down at scale. Common “motorway rules”, open, standard, interoperable building blocks, allow everyone to drive faster, safer, and at lower cost.

We are paying heavily for inefficiency. Citizens face friction, businesses waste resources, and governments lose efficiency. The technology and tools already exist; what is missing is shared foundations and coordination. The Sovereign Stack provides that framework.

1.5 The Problem-Driver Framework

Why each layer demands intervention in the The Sovereign Stack stack

Identity & Access

• Problem: 100+ passwords per citizen, €55B annual cybercrime losses, 40% of digital transformation delays. Federated identity controlled by 3-4 tech giants creating pseudo-monopolies
• Why standardise: Break the oligopoly of identity providers, enable true competition, prevent any single provider from becoming the gateway to all services
• Fix: Mandatory interoperability between ALL identity providers, including government and private options (OAuth 2.0 + OIDC)

Data Exchange

• Problem: Data trapped in silos, no row-level security by default, breaches expose entire datasets unnecessarily, vendor lock-in through proprietary formats
• Why standardise: Enable granular data ownership where each record knows who can access it. Build security into the data layer, not just perimeter. Ensure data portability as a right
• Fix: Standard row-level identity binding, encrypted-by-default storage, zero-trust data architecture, mandatory export/import capabilities

Processing/Application

• Problem: 40-50% of engineering effort on integration/rework, framework churn every 2-3 years, fragmented skill sets across incompatible stacks
• Why standardise: Not the code itself, but the development infrastructure: requirements formats, test harnesses, documentation standards
• Fix: Standardised development toolchain, common testing frameworks, AI-readable specifications, consistent documentation standards

API/Integration

• Problem: Every service reinvents connection methods, switching costs prohibitive, endless custom adapters, months of integration work
• Why standardise: Reduce integration from months to hours, enable service substitution, lower barriers for SME participation
• Fix: Mandatory OpenAPI specifications, standard error codes, versioning rules, common authentication patterns

Runtime/OS

• Problem: Vendor lock-in at infrastructure level, sovereignty concerns, unpredictable costs, inability to migrate workloads
• Why standardise: Ensure workload portability, prevent infrastructure monopolies, maintain digital sovereignty
• Fix: Container standards, open hardware options (RISC-V), standardised deployment patterns

2. WHAT: The Technology Framework

2.1 Digital Renovation Cycle

Expected lifespans and change velocities for digital infrastructure layers

Just as buildings have components with different replacement cycles (foundations last generations while kitchens are renovated every decade), digital infrastructure requires a nuanced approach to change management. This model recognises four distinct lifecycles:

Foundation (50+ years): Protocol Standards & Mathematical Constructs

• Abstract specifications and algorithms that exist independently of implementation
• Examples: TCP/IP protocol, HTTP standard, RSA encryption, UTF-8 encoding
• These are ideas and agreements written in documents, not software that runs
• Change requires global consensus because breaking changes would fracture the internet

Infrastructure (15-25 years): Platform Implementations & Operating Systems

• Concrete software platforms that implement foundational standards
• Examples: Linux kernel, Windows Server, PostgreSQL, Node.js runtime
• These are actual software that needs security patches, updates, and eventual replacement
• Change requires coordinated migration planning but not universal agreement

Functional (7-10 years): Frameworks & Business Logic

• Tools and patterns for building applications efficiently
• Examples: React framework, Spring Boot, microservice architectures
• Balance between stability for existing systems and evolution for new capabilities
• Change driven by developer productivity and maintainability needs

Surface (3-5 years): Interfaces & Experiences

• What users see and interact with directly
• Examples: Mobile apps, web interfaces, API versions
• Rapid iteration based on user feedback and changing expectations
• Change driven by user needs, accessibility requirements, and device capabilities

This separation allows appropriate governance and investment strategies per layer, avoiding both premature obsolescence and expensive technical debt. The key insight: Foundations are specifications you implement; Infrastructure is software you run.

2.2 Reference Architecture

The The Sovereign Stack stack is structured across layers that represent the fundamental building blocks of digital systems. Each layer has a clear role, with open standards ensuring interoperability, quality, and scalability. Cross-cutting planes support developer productivity, observability, and trust. This layered architecture prevents duplication, strengthens competition, and provides the foundation for innovation.

2.3 Summary Layer Table

2.4 Detailed Layer Descriptions

2.4.1 Experience Layer

2.4.2 Application / Business Layer

2.4.3 Integration / API Layer

2.4.4 Data: Query & Exchange

2.4.5 AI Layer

2.4.6 Runtime & OS Layer

2.4.7 Identity & Access Layer

See Appendix: Digital Identity Systems for detailed implementation framework.

2.4.8 DRM & Licensing Layer

2.4.9 Cross-cutting Planes

2.5 Sovereign Stack Core Language Families

1. Scripting (DevEx / Automation) – JavaScript (ES6) with JSONata for data scripting
2. Experience (Presentation & Interaction) – JavaScript (ES6), HTML, CSS, Web Components, PWAs
3. Application / Business Logic – JavaScript (ES6) via Node.js
4. Documentation & Knowledge (Markdown-first) – Markdown, JSON Schema, OpenAPI

Exceptions: When performance-critical, domain-specific, or legacy interoperability is required. All exceptions should be exposed via Open API + UQL and meet observability and security baselines.

For practical implementation guidance including state management patterns, logging standards, and documentation requirements, see Appendix: Technology Implementation Recommendations.

3. HOW: Governance, Funding and Certification

3.1 Governance & PPP Model

The initiative should be advanced as a public–private partnership, led by DG CONNECT with strong involvement from SMEs, universities, and industry alliances. A joint board should set priorities, define lightweight conformance profiles, and ensure both public value and private innovation.

3.2 Certification

Certification should follow a tiered model:

• Self-certification for low-risk services, via a simple open-source testing system anybody can run
• Audited certification for critical infrastructure, ensuring trust and resilience

3.3 Funding Model

Estimated budget: Up to £1m for initial pilot

Model: 50:50 public-private partnership

Funding sources under discussion:

• DG CONNECT (Digital Europe Programme)
• UK Government (DSIT, GDS)
• Partner contributions (in-kind and financial)

3.4 Licensing for Artefacts

• White paper and non-code content: CC BY 4.0 (copy, adapt, commercial use with attribution)
• Code samples & prototype implementations: MIT by default for maximum permissibility; Apache-2.0 for components where explicit patent grants are preferred by partners

3.5 Publication & Repository

Public repository (e.g., github.com/Buckden/vb-sovereignstack) hosting specifications, code, and test artefacts; issues used for community feedback and self-certification test results.

4. WHERE: The Pilot

4.1 What Makes an Ideal Pilot Location

The Sovereign Stack is designed to work in any region willing to collaborate across public, private, and academic sectors. The ideal pilot location has:

1. Smart city ambition – A track record of, or appetite for, digital innovation and citizen-centred services
2. Scalable but manageable scope – Large enough for meaningful data, small enough for a controlled pilot
3. Strong local partnerships – Existing relationships between the local authority, employers, and academic institutions
4. Strategic visibility – A profile that attracts attention from national government and EU institutions
5. Political alignment – Local and national government eager to demonstrate digital leadership
6. Immediate community benefit – Residents and local businesses stand to gain from open data and new digital services

4.2 The Pilot Approach

The pilot has two goals: build the The Sovereign Stack stack, and prove it works by enhancing a real local service.

Building the Stack

The reusable digital primitives that underpin every The Sovereign Stack service. Critically, the stack is designed to be AI-ready, with standardised, machine-readable specifications, consistent patterns, and comprehensive test coverage, so that AI-assisted development and testing can deliver rapid, high-quality results from day one.

• Identity & Access: OAuth 2.0 + OIDC federation, FIDO2/WebAuthn passwordless authentication
• API Layer: OpenAPI + GraphQL, standardised patterns, AI-parseable schemas
• Data Layer: Row-level security, encrypted-by-default, user-controlled
• Observability: OpenTelemetry instrumentation, Winston logging
• Documentation: JSDoc + Markdown, AI-readable specifications throughout
• Testing: Comprehensive automated test suites enabling AI-assisted quality assurance

Enhancing a Local Service

The stack is only valuable if it solves a real problem. The pilot will take an existing local service, one that the anchor authority and enterprise partner agree needs refreshing, and rebuild or enhance it on the The Sovereign Stack stack.

The specific service will be agreed with partners during mobilisation. It should be something citizens already use, where the current experience falls short: slow, outdated, poorly integrated, or lacking user control. By modernising a service people know, we demonstrate the value of the stack in a way that is immediately tangible.

What Comes Next: FrankMail

Once the stack is proven through the pilot service, it becomes the foundation for further The Sovereign Stack services, starting with FrankMail, a sovereign email platform where users control who can reach them. See the FrankMail page for full details.

4.3 Partner Roles

The pilot requires three types of partners: an ambitious local authority, a private sector enterprise, and an academic institution. Each brings a different perspective: public service delivery, commercial viability, and independent evaluation.

For full partner role descriptions, deliverables, timeline, and success metrics, see the Pilot page.

Appendices

Appendix A: Economic Evidence References

1. McKinsey & Company (2020) – “Developer Velocity Index”: estimated 40–50% of engineering effort is spent on integration, maintenance, and rework rather than creating new value.
2. Gartner (2022) – “Top Priorities for CIOs”: noted that 20–40% of IT budgets in large organisations are absorbed by technical debt and associated inefficiencies.
3. IDC (2023) – Worldwide IT Spending Guide: projected global IT spend to exceed $5 trillion by 2025, with 30–35% attributed to integration and duplication challenges.
4. Ponemon Institute (2021) – “Password Practices Report”: estimated the average cost of password management is $150–200 per employee, per year.
5. European Commission (2020) – EU Cybersecurity Strategy: cited €55 billion in annual losses to cybercrime, much of it linked to identity and authentication weaknesses.
6. UK Cabinet Office (2022) – “Digital Identity Update”: found that 40% of government digital transformation delays were related to identity/authentication barriers.
7. European Commission (2021) – Digital Compass 2030: warned of a €400 billion annual opportunity cost if Europe fails to accelerate open digital adoption and digital sovereignty.
8. ECMA International – JavaScript is defined by the ECMA-262 ECMAScript Language Specification, with ES6 (ECMAScript 2015) as the foundational version for modern implementations.

Appendix B: European Digital Foundations

Europe’s leadership in foundational digital technologies from the 1960s to present:

Appendix C: Digital Identity Systems Framework

Modern digital identity systems can be understood through four interconnected layers that deliver core user functionality.

Functionality Supported

Digital identity schemes enable four primary functions:

1. Authentication & Authorisation: proving who you are and accessing services
2. Digital Signing: creating legally-binding electronic signatures
3. Identity Verification with Verifiable Credentials: proving specific attributes without oversharing
4. Document Storage: securely holding and presenting official documents

Structure & Liability Framework

The governance structure determines trust and accountability. Who issues credentials, who attests to their validity, and who bears liability when things go wrong forms the critical trust triangle.

The EU’s eIDAS regulation establishes clear statutory liability: member states are liable for authentication failures, while qualified trust service providers carry mandatory insurance. The UK operates a more fragmented, contractual liability model where responsibility varies by sector and agreement.

Two-Layer Issuer Model

Layer 1 (Root Identity) establishes the foundational digital identity: the primary key pair and core identity proofing that says “this cryptographic key belongs to this verified person.” Government-designated providers typically control this layer.

Layer 2 (Attributes) sees various authoritative sources attach credentials to this root identity: universities add degrees, transport authorities add driving licences, employers confirm employment status.

This separation is crucial: you have one verified identity but many attached attributes.

Technical Implementation

The underlying technology stack, from FIDO2/WebAuthn for passwordless authentication to PKI for digital signatures and W3C Verifiable Credentials for selective disclosure, remains largely consistent across schemes. The key differences lie in architectural choices: centralised versus wallet-based storage, federation protocols, and whether to use emerging technologies like zero-knowledge proofs for privacy-preserving verification.

EU Digital Identity Wallet (EUDIW)

A wallet-based system mandating that all EU member states issue interoperable digital identities by December 2026, with statutory liability and guaranteed cross-border acceptance.

Key dates:

• December 2026: At least one wallet available in each Member State
• December 2027: Mandatory acceptance by specified private-sector relying parties

UK Digital Identity

A market-led approach combining GOV.UK One Login for public services with certified private providers, operating outside eIDAS with sector-specific rules and commercial liability models.

Key Difference: The EU mandates one interoperable system with legal force across 27 nations, while the UK relies on market adoption with voluntary acceptance and varying standards by sector.

Appendix D: Technology Implementation Recommendations

State Management

Implement state machines using vanilla JavaScript objects for simple cases with fewer than five states and linear transitions, reserving XState for complex scenarios involving nested states, asynchronous operations, or guard conditions.

Employ a singleton service pattern distributed by functional domain (authentication, data management, user interface), ensuring each maintains a single globally-accessible instance to prevent state fragmentation.

Persist only business-critical states to the database while maintaining ephemeral UI states in memory, optimising both performance and system coherence.

Logging Infrastructure

Adopt Winston as the standard logging framework across all Node.js services, configured with structured JSON output for machine parsing and human-readable formatting for development.

Implement correlation IDs across service boundaries to enable end-to-end request tracing.

Set log levels dynamically per environment: verbose for development, info for staging, warn for production, with the ability to temporarily elevate levels for debugging without deployment.

Documentation Standards

Mandate JSDoc comments for all public APIs and complex internal functions, enabling automatic API documentation generation and IDE intelligence.

Combine JSDoc with Markdown files for architectural decisions, setup guides, and operational runbooks.

Maintain a documentation-first approach where APIs are documented before implementation, ensuring contract clarity and reducing integration friction.

Get Involved

The Sovereign Stack is seeking three types of partners: local authorities, enterprise partners, and academic institutions, to deliver the first pilot. See the Pilot page for full partner role descriptions.

Contact: richard@buckden.io Website: thesovereignstack.eu

The Sovereign Stack: transforming digital waste into digital sovereignty.