The philosophy of the device#

Technological sovereignty serves a single end: to allow an organisation — a business, an administration, an individual — to continue to operate its data and conduct its operations, whatever happens. The failure of a provider, geopolitical conflict, sanctions, hostile takeover, the unilateral flip of a publisher. Everything else — licenses, contracts, certifications — is only a means to serve that end.

How can a buyer — CIO, CISO, head of procurement — know whether a provider actually allows that continuity? And how can a provider — software publisher, hosting provider, cloud provider, distributor, integrator — demonstrate it without going through heavy certification schemes that only large companies can absorb?

The manifesto proposes a simple, free, public and universally verifiable instrument: a single sovereignty.json file that covers seven domains, published at a standardised location on the declarant’s domain, and indexed without rating or ranking by the manifesto. The device does not distinguish open source from proprietary: it distinguishes providers who make their chain readable from those who obscure it. Depending on the declarant’s profile, we speak of a Sovereignty Profile (the seven domains filled in) or of a commitments declaration (only domain 7 filled in) — the technical format is the same.

Why this form rather than certification#

Operational continuity depends on the entire software chain — publisher, hosting provider, distributor, registries, foundations. If a single link escapes control or readability, the sovereignty of the whole is compromised. The device described here exists to make that chain readable, through a public and standardised format rather than through certifying audits.

Software sovereignty suffers from an information asymmetry. A buyer — CIO, CISO, head of procurement — has neither the means, nor the time, nor often the expertise to disentangle what a product or service actually entails in terms of dependencies, jurisdictions, and continuity plans. Providers’ marketing claims are barely comparable, barely verifiable, and tend to highlight strong points while keeping silent on weaknesses.

The traditional answers to this asymmetry rest on certification: third-party audits, labelling by accredited bodies, conformity to reference frameworks. These mechanisms have their use, but they come at a cost. A serious annual audit represents tens of thousands of euros. An ISO or SecNumCloud qualification can cost considerably more. That cost effectively excludes European micro-enterprises and small publishing SMEs — precisely the players that European technological sovereignty ought to promote. It also enriches audit firms, a substantial share of which is Anglo-American, which raises a coherence problem for a sovereignty device.

We propose an alternative. Not as a replacement for the existing qualification mechanisms — which remain relevant in the contexts where they are required — but as a first level, accessible to all, that makes the essentials readable and allows a rapid assessment of a declarant’s posture.

Terminological cohabitation: Sovereignty Profile and commitments declaration#

The technical device is unique: a single sovereignty.json format, conforming to a public schema (sovereignty-v1.json), each domain of which is individually optional. The declarant fills in the domains relevant to their case. The manifesto nevertheless retains two communicational designations, because they refer to distinct editorial situations:

Sovereignty Profile. Designates a declaration that covers all seven domains. This designation is used for technology providers — software publishers, hosting providers, cloud providers, distributors, integrators — who document their entire chain. The inspiration is the Nutri-Score: public calculation, voluntary but standardised display, and what becomes progressively suspect is the opacity of those who do not display it.

Commitments declaration. Designates a declaration that covers only domain 7 (“commitments and assumed limits”). Typical cases: a user organisation that formalises its sovereignty policy; an administration that makes its trajectory of exposure reduction public; an individual or a professional community that takes on the principles of the manifesto; a non-provider entity that wishes to go on record about its choices.

Both designations refer to the same technical file. On the tooling side, on the schema side, on the public index side, there is only one device. The distinction has effect only in communication: a buyer who consults a Profile knows they will have all seven domains to read; a reader who consults a commitments declaration knows they will find intentions and assumed blind spots there, not the full inventory of a technical chain.

The conditions of equivalence for proprietary#

A substantial share of European software solutions is and will remain proprietary — that is legitimate, and the manifesto claims it. But that legitimacy is not to be confused with a guarantee of sovereignty. Where open source guarantees structurally the continuity of use (the code is public, the failure of the publisher prevents neither use, nor the fork, nor self-hosting), proprietary cannot rely on this structure. It must therefore demonstrate contractually what free software offers structurally.

Seven established mechanisms make this demonstration possible. They are cumulative, and a serious proprietary publisher combines several.

But they are not equal. Reversibility is the non-negotiable priority — particularly for models in which the client entrusts its workload to the provider (SaaS, and even more so PaaS). Without operationally tested reversibility, the six other mechanisms become theoretical: escrow gives access to code that cannot be run elsewhere, a notice period is only a delay before the inevitable, operational continuity assumes that a successor can run what the client cannot run itself, an audit right does not change the dependency, anti-acquisition statutes protect the capital future without securing the technical exit, and release-on-trigger releases usable code only if the execution target remains available. Reversibility is what makes the other mechanisms operable — it is what must be designed, contracted and tested first.

1. Standard reversibility clause — the non-negotiable condition. Depending on the service model, reversibility takes two complementary forms.

— For SaaS solutions (the publisher operates the service; the client entrusts its data to it): the contract includes a clause for the complete export of data in documented open formats, with tested migration scripts and a contractual export deadline (cf. sheet pub-009). The stake is data portability.

— For PaaS solutions (the provider operates the platform; the client deploys its code on it): the contract guarantees application portability — packaging in standard OCI format, deployment manifests portable to diverse targets, detachable managed services with a documented and tested self-hosting procedure, a quantified contractual relocation deadline, periodic public demonstration of a successful migration (cf. sheet pub-014). The preferred target is self-hosted via Docker Compose — accessible, executable on a standard VPS without a cluster or heavy orchestrator to maintain; the other options (another conforming PaaS, managed or self-hosted Kubernetes) remain open but are not prescribed, Kubernetes itself being a project under American governance with no established European alternative — making it the only fallback would reproduce, at the orchestrator level, the dependency one is trying to break at the PaaS level. The stake is application workload portability, deeper and structurally harder than that of data alone. It is on PaaS that the cost of unprepared reversibility is heaviest: if it has not been designed from the outset, it may turn out to be impossible afterwards.

Reversibility does not boil down to the license — it is proven by the tools, the formats and the time allocated, in the operational language proper to each model.

2. Software escrow. The current source code of the solution is deposited with a trusted European third party — a specialised notary, a legal escrow agent, a foundation. A tripartite contract (publisher, escrow agent, clients) defines precisely the circumstances under which the code is released to the clients: opening of insolvency proceedings with liquidation, officially announced cessation, finalised acquisition by a non-EU entity. Periodic refresh of the escrow (typically quarterly) is essential to its protective value.

3. Public release commitment. Failing escrow, or in addition to it, the publisher publishes an explicit commitment — known as release-on-trigger — to release the source code under a free license under named triggering circumstances, with a documented deadline (typically 30–90 days after the event). The commitment specifies the applicable license (for example AGPL v3) and the public repository in which the code will be published.

4. Minimum contractual notice period. Before any end of support, unilateral flip or substantial change to the service, the publisher commits by contract to a minimum notice period (typically 6 to 12 months). This gives the client time to migrate, to re-contract or to mobilise its escrow.

5. Operational continuity commitment. In the event of cessation, an arrangement is in place: organised transfer of the client relationship to an identified successor, or a sector guarantee fund, or a mutual takeover agreement between peers. The publisher does not merely promise an export — it prepares a trajectory of continued operation.

6. Statutory protection clauses. For providers of strategic interest, statutory provisions limit non-EU acquisitions: a shareholders’ agreement, pre-emption rights for European investors, a public golden share, a specific share with blocking rights. Domain 6 of the Profile declares them explicitly.

7. Source code audit right. For clients whose contract justifies it — sensitive public bodies, critical infrastructures, strong sovereign requirement — the publisher opens a source code audit right under a non-disclosure agreement (NDA). It is not a publication, but a verification made possible by independent eyes chosen by the client.

The thesis is not that proprietary is forbidden. It is that without these conditions explicitly declared, a proprietary publisher cannot claim the same guarantee of sovereignty as an open source publisher. Domain 5 of the Profile is where each of these conditions is declared precisely; domain 6 covers capital; domain 7 makes explicit the blind spots that remain. Each mechanism has one or more operational commitment sheets in the device (pub-009 and pub-014 for reversibility, declined respectively in SaaS and PaaS — the priority; pub-005 for the escrow + release pair; pub-010, pub-011, pub-012 and pub-013 for conditions 4 to 7).

An important sectoral caveat. The manifesto sets chain readability as a principle — not the universal publication of source code. For certain sectors — defence, critical infrastructures, energy, health, finance, sensitive administrations — the open source publication of code can itself constitute an active risk. Agentic AI now allows an attacker so equipped to silently scan millions of lines, identify non-trivial flaws, and exploit them without warning, without contributing a patch, without responsible disclosure — the opposite of a case such as Copy Fail (CVE-2026-31431), where disclosure was responsible, and which is instructive precisely because it could have remained silent. In these contexts, proprietary combined with solid contractual mechanisms — tested reversibility first, targeted audit right next, escrow as a safety net — can offer a better sovereign profile than an open source publication that would expose the attack surface without proportionate defensive counterpart. The Profile device does not decide for the declarant; it makes the choice and the conditions of its sovereign equivalence visible.

A dedicated orientation page is addressed directly to proprietary publishers and European startups: For European proprietary publishers — a condensed formulation of the seven mechanisms (with reversibility as the priority), a developed sectoral caveat, and a specific trajectory for early-stage projects.

Four provider profiles#

Technological sovereignty is not played out at the level of the software publisher alone. It is played out across the entire chain: who publishes, who hosts, who operates, who distributes. The device covers four categories of provider, each with its specific questions.

Category A — Software publisher#

Typical profile: a software product to install or in SaaS, with third-party dependencies in the code, and a development team of its own. Examples: a French publisher of a business software suite, a publisher of a European open source solution with a commercial entity, a European SaaS provider.

The key questions concern the third-party components in the software, the jurisdiction of the open source foundations used, the conditions of continuity in the event of publisher failure, and the capital structure.

Category B — Hosting provider, cloud, IaaS-PaaS#

Typical profile: execution infrastructure made available. The client deploys its own software on it or uses managed services. Examples: OVHcloud, Scaleway, Outscale, Infomaniak, Hetzner, but also any traditional hosting operator or web host.

The key questions concern the physical location of the data centres and the capital ownership hierarchy, the legal status with regard to extraterritorial laws, the underlying technical bricks (OpenStack, VMware, hyperscaler stack resold), the managed services offered and their dependencies on foreign publishers, and technical reversibility.

Category C — MSP, managed service provider#

Typical profile: operates on behalf of its clients an infrastructure and/or software that it does not necessarily publish or host itself. The client delegates day-to-day administration to it. Examples: an MSP that manages a Microsoft 365 estate and servers on AWS for French SMEs, an MSP that operates OVHcloud or Scaleway environments for local authorities, an operator of RMM/PSA tooling, a service provider that operates the stack of a third-party publisher on a third-party host.

The key questions concern the administration tools used (RMM, PSA, monitoring) and their jurisdiction, the delegated access to client infrastructures (who can do what, where the credentials are), the actual chain of technical subcontractors behind the service, and the MSP’s capacity to guarantee operational continuity if one of its own tools or subcontractors fails.

Category D — Distributor, reseller, integrator#

Typical profile: supplies European clients with solutions developed elsewhere. This is the heart of thesis 12 of the manifesto, which points to the role of European providers turned distributors of foreign bricks. Examples: a French integrator that resells Microsoft 365 under a service contract, a so-called “sovereign cloud” provider that resells AWS under a white label, a French publisher that packages American software with local support.

The key questions concern the share of revenue tied to products whose original publisher is non-European, the effective control over the roadmap of distributed solutions, the contractual guarantees the distributor can pass on beyond those of the original publisher, and the skills and access to the code in the event of failure of the original publisher.

This category is politically the most sensitive. Many French players present themselves as “sovereign” while being distributors of American solutions under a reseller contract. Self-declaration invites them to say so — or to choose silence, which itself becomes a signal. Conversely, a distributor of European bricks — an integrator that deploys PostgreSQL, Nextcloud or a Mistral product, for instance — falls technically into the same category without embodying the syndrome; the Profile makes that distinction readable rather than hiding it behind a single word.

The principle: structured public self-declaration#

Whatever its profile, the declarant publishes the sovereignty.json file on its own domain, at a standardised location. There is no prior validation, no trusted third party that “stamps”, no membership cost. The rigour of the device rests on four principles.

First, structured public publication. The document is visible to all, in a standardised format that allows comparison between declarants. Lying publicly in a structured document exposes the declarant to a public dismantling by its clients, its competitors, journalists or researchers.

Second, dated annual update. A frozen declaration loses its value. A declarant that does not update its file signals the absence of any real commitment. The device materialises this requirement through an automatic daily check: a canonical URL that ceases to respond is flagged as such for thirty days, then automatically removed from the index if it has not been restored.

Third, the possibility of contestation. Any party with factual elements can contest a declaration. A structured public procedure — an open reporting and discussion space — is being put in place; in the meantime, reasoned reports are made by email (contact [at] sovereignty-gap.eu). Substantiated contestations may lead to a manual removal from the index, traced in the public history.

Finally, transparency about blind spots. A declarant that publicly assumes its weaknesses becomes more credible than one that pretends to master everything. The format explicitly encourages this honesty; domain 7 is entirely devoted to it.

Inspirations of the model#

The device borrows from three established precedents.

The Nutri-Score. The calculation is public, the display is voluntary but standardised, and what becomes progressively suspect is the opacity of those who do not display it. Pressure comes from the market and from transparency, not from a heavy supervisory authority. The manifesto takes up this principle with one important difference: no synthetic score is calculated. Readability comes from the structure of the file, not from an aggregated score.

The SBOM (Software Bill of Materials). The structured list of the software components of a product became mandatory in the United States for federal suppliers by executive order in May 2021. The existing open formats (SPDX, CycloneDX) allow largely automated production, which reduces the cost of compliance. Domain 1 of the device is in this lineage and may readily be composed of an SBOM published in parallel.

Declarations of the Have I Been Pwned type. Operators are judged on their transparency and their reactivity in the face of incidents, not on the absence of incidents — a more honest and more useful posture than the pretence of zero defect. Domain 7 of the device draws on this logic: declaring what one does not master is more credible than pretending to master everything.

The seven domains#

The file covers seven domains. The questions in each domain adapt to the category of declarant. For each one, the declarant answers with the level of precision it deems appropriate — knowing that vague or evasive answers themselves constitute a signal for buyers.

A detailed educational sheet is published for each domain — what it covers, why it matters, what is expected by category of declarant, how to fill it in. The whole set is browsable and shareable from the public catalogue of the seven domains.

Domain 1 — Strategic third-party components#

For a publisher: list of third-party software components (open source or proprietary) on which the solution depends in a non-substitutable way, that is, whose absence would cause the loss of a critical functionality of the product.

For a hosting or cloud provider: list of the underlying technical bricks of the infrastructure (hypervisor, orchestrator, managed database, storage services, etc.) and of the publishers or foundations to which these bricks belong.

For a distributor or integrator: list of distributed solutions whose original publisher is non-European, with the share of revenue associated and the nature of the distribution agreement.

For each component identified, whatever the category: name and version, type of license, country or jurisdiction of the publisher or governance foundation, essential or peripheral character. The aim is not technical exhaustiveness — the transitive dependencies of a project can run into the hundreds. What matters is the list of strategically determining components.

→ Educational sheet for domain 1

Domain 2 — Workaround plans#

For a publisher: for each strategic third-party component, is there an identified replacement solution in the event of discontinuation, license flip, or jurisdictional blockage? What estimate of the time and cost of migration? Has this migration been concretely tested?

For a hosting provider: what happens if a central component of the stack becomes unavailable (for example: VMware acquired and licensed in a restrictive way, as occurred in 2024)? What plan of migration to an alternative? What impact on clients?

For a distributor: what happens if the original publisher of a distributed solution unilaterally changes the conditions, raises prices massively, or stops serving the European market? What alternative for clients? Does the distributor have the skills to ensure continuity?

An honest answer of “no solution identified to date” is worth more than a false reassurance.

→ Educational sheet for domain 2

Domain 3 — Supply chain dependencies#

List of third-party services indispensable to the operation of the product or service: forge where the code is hosted (GitHub, GitLab, Codeberg, other), package registry used for dependencies (npm, PyPI, Maven Central, other), container registry (Docker Hub, private registries, other), CDNs used, third-party authentication services, critical CI/CD platforms, third-party infrastructure services (DNS, certificates, monitoring).

For each one: jurisdiction of the operator, estimated impact in the event of cut-off, planned migration plan.

→ Educational sheet for domain 3

Domain 4 — Hosting and data#

For a SaaS publisher, or for the hosting recommendations of an on-premise solution: location of the servers (country, hosting provider, effective jurisdiction), trajectory of client data (does it transit through, or is it stored, outside the EU, in which cases, for which purposes), contractual guarantees on this location, procedure for informing the client in the event of an extra-European requisition.

For a hosting or cloud provider: precise location of the data centres, capital ownership hierarchy of the operating companies, applicable qualifications (HDS, SecNumCloud, ISO 27001, etc.), resistance to extraterritorial laws (does the CLOUD Act apply? on what basis can the host refuse a foreign requisition?), commitment on the country of effective execution of client data.

For a distributor: where are the distributed solutions actually hosted? Can the distributor guarantee a European location, or only pass on the conditions of the original publisher? In the case of a managed service resold under a white label, who actually controls the servers?

→ Educational sheet for domain 4

Domain 5 — Continuity in the event of failure#

This is the heart of the device on the dimensions where the proprietary solution is intrinsically weak.

For a publisher: is there a software escrow mechanism? If so, with which third party, in which jurisdiction, with which release conditions? Failing a formal escrow, does the publisher commit to publishing the source code under a free license under specific circumstances (bankruptcy, liquidation, definitive shutdown of the product, acquisition by a non-EU entity)? What notice period does the publisher commit to giving before an end of support? Is there a standard reversibility clause in client contracts?

For a hosting provider: what happens to client data and workloads in the event of cessation of activity? What notice period? What export tools? What interoperable formats? Is there a guarantee fund or a continuity arrangement operated with a peer?

For a distributor: if the distributor ceases its activity, what is the impact for clients who depend on it for the support of resold solutions? Is there a possible transfer of the client relationship to another integrator, or directly to the original publisher?

Open source publishers answer this domain by specifying the license of the current versions, the conditions of the fork, the governance of the project, and the mechanisms in the event of failure of the commercial entity that carries it.

→ Educational sheet for domain 5

Domain 6 — Governance and capital#

Whatever the category: who are the principal shareholders above 5% of the capital, what is the nationality of the reference shareholders, is the declarant subject to a foreign-investment screening mechanism (in France: IEF, in Germany: AWG, in Italy: Golden Power), are there statutory protective provisions in the event of an attempted non-EU acquisition.

A sensitive but essential domain: a French provider acquired tomorrow by a non-European actor changes its sovereignty profile from one day to the next, and the client contract generally offers no protection against that event.

→ Educational sheet for domain 6

Domain 7 — Commitments and assumed limits#

The declarant honestly states:

what it explicitly guarantees, and the level of those guarantees (enforceable contractual commitment, unilateral public declaration, mere internal good practice);
what it cannot guarantee, and why;
the upcoming changes that could modify this profile in the next twelve to twenty-four months (version change, infrastructure migration, fundraising with foreign investors in prospect, strategic repositioning);
the points where the declarant knows itself to be weak, and the actions undertaken to improve.

This seventh domain is politically the most important. It transforms the declaration from an exercise in communication into an exercise in honesty. A declarant that publicly assumes its weaknesses becomes more credible than one that pretends to master everything. It is precisely the opposite of the usual marketing posture, and it is what distinguishes serious declarants from the rest. It is also the only domain that, by construction, a non-provider user organisation that wishes to formalise its own trajectory fills in — hence the distinct designation of commitments declaration.

→ Educational sheet for domain 7

Technical format#

The declaration takes the form of a sovereignty.json file conforming to a public, versioned JSON schema (sovereignty-v1.json). The structure allows comparison between declarants and aggregation by third-party tools — for example, a site that lists declared hosting providers by jurisdiction, or an observatory that tracks the aggregate evolution of the most frequently declared blind spots.

The file is published at a public, stable canonical URL, indicated at the time of notification. The recommended location is the root of the declarant’s domain:

https://[domain]/sovereignty.json

This choice of standardised location follows the logic of files such as robots.txt, humans.txt, security.txt. It allows automated tools to discover declarations without central coordination. Where the root is not accessible (constrained hosting, declaration carried by a public git repository, dedicated subdomain), an alternative canonical URL remains valid, provided that it is public, stable and explicitly indicated at the time of notification.

The JSON schema, its variants by category of declarant, and the associated web generator are made available by the manifesto as a methodological commons. The whole is under a license allowing reuse and modification.

The declaration generator#

To facilitate the production of a declaration and ensure its conformity with the reference schema, the manifesto provides a guided web generator at /en/profile/. The generator takes the form of a sequence of seven successive steps — declarant, commitments, domains, details, products, identity, verify — freely navigable via a clickable side outline.

The generator runs entirely in the browser. No data entered is transmitted to a server: the current draft is saved locally (in the declarant’s browser) and can be resumed from one session to the next. This constraint is essential: a declarant that formalises its fragilities should not have to entrust this information to a third party, even the manifesto itself.

An existing declaration can also be imported into the generator, from its public canonical URL or from a local .json file, to be revised, updated or derived.

The generator produces a sovereignty.json file conforming to the sovereignty-v1.json schema, ready to be published at the chosen canonical URL. The declarant chooses which domains to fill in; empty domains are valid. The format moreover distinguishes a domain simply left empty (meaning: not declared at this stage) from a domain explicitly marked “not applicable”, accompanied by a brief reason — for example, a publisher with no client data has no need to fill in domain 4 on hosting. This distinction protects readability: a blank is not an assertion. The fields are accompanied by short explanations drawn from the seven educational sheets of the device, to help formulate usable answers without copying hollow standardised text.

The generator’s code is published under a free license. Any declarant can audit it, fork it, or propose variants of it. The rigour of the device does not depend on trust in the manifesto, but on the transparency of the process and the format.

To understand by reading before writing, annotated examples cover different typical cases — see examples of Profiles.

Notification, challenge and indexing#

Once the file is published, the declarant notifies the manifesto from /en/profile/notify. This notification triggers a challenge the purpose of which is to prove that the declarant effectively controls the domain — or repository — on which it publishes.

On notification, the manifesto issues a unique token: a random string of 32 hexadecimal characters, valid for seven days. The declarant must publish it in a place that only a legitimate holder of the domain or repository can reach — a DNS record, a file on the web server, a file in the git repository. The manifesto then verifies this publication by itself: if the token is found, the challenge is passed. It is the same paradigm as that used by Let’s Encrypt or domain-ownership verification tools.

The proposed methods depend on the type of declarant. In the examples below, the token is a3f1b7c8d9e0f1a2b3c4d5e6f7a8b9c0 (placeholder) and the declared domain is example.eu.

For an organisation (business, administration, association, provider), three methods to choose from.

DNS TXT challenge (recommended) — TXT record on the domain:

sovereignty-gap-challenge.example.eu.  IN TXT  "sovereignty-verify=a3f1b7c8d9e0f1a2b3c4d5e6f7a8b9c0"

HTTP root challenge — file hosted at the root of the domain:

URL      https://example.eu/sovereignty-challenge.txt
Content  a3f1b7c8d9e0f1a2b3c4d5e6f7a8b9c0

HTTP .well-known challenge — a variant of the previous one, for hosts that do not allow writing at the root:

URL      https://example.eu/.well-known/sovereignty/challenge.txt
Content  a3f1b7c8d9e0f1a2b3c4d5e6f7a8b9c0

For an individual declarant (private individual, professional community whose declaration is hosted on a public git forge).

git challenge — file alongside the declaration in the public git repository, fetched by raw HTTP request. If the declaration is published at https://codeberg.org/example/sovereignty/raw/main/sovereignty.json, the expected challenge file is:

URL      https://codeberg.org/example/sovereignty/raw/main/sovereignty-challenge.txt
Content  a3f1b7c8d9e0f1a2b3c4d5e6f7a8b9c0

The challenge is verified automatically before any human action on the moderation side. Once passed, it proves control of the domain or repository and does not need to be renewed. The subsequent daily verification does not re-challenge — it simply checks that the canonical URL still responds and that its content remains compliant with the schema.

After moderation (indicative deadline: five working days), the declaration appears in the public index at /en/profile/index, listed in reverse chronological order of update. The email provided at notification is deleted immediately after moderation. No hierarchical comparison between declarants is proposed, and none is computable from the schema’s fields.

What the device is not#

To avoid any confusion:

Not a label. No body stamps or validates. It is a unilateral declaration by the declarant.
Not a qualification, not a certification. No audit, no reference framework to comply with, no accreditation.
Not a binding standard. Adherence is voluntary. No sanction strikes those who do not publish.
Not a ranking. No score, no rating, no axiological colour. Declarations are indexed, not ranked. No completeness score is calculated from the domains filled in or left empty.
Not a substitute for existing qualification mechanisms where they are relevant (HDS, SecNumCloud, ISO 27001). It is a first level of transparency, complementary and accessible.

For the full list of the project’s assumed limits — what the device does not measure, does not guarantee, and the gap between the manifesto and the tool — see Assumed limits of the device.

What the device asks of buyers#

For the device to have a real effect, it must be taken seriously by those who buy software and services:

Require the declaration as a prerequisite for listing in public and private procurement processes.
Give a preference, at functional equivalence, to providers who publish their declaration over those who do not.
Make the absence of declaration a negative signal as explicit as its presence is a positive one.
Require declarations from the entire chain: publisher, hosting provider, and integrator. A single non-transparent link is enough to compromise the sovereignty of the whole.
Use declarations in risk analyses, rather than relying solely on providers’ marketing arguments.
Publicly contest, with evidence, declarations that turn out to be misleading, and expect that other players will do likewise.

The device does not on its own create a more sovereign market. It requires the mobilisation of buyers, who are the true arbiters.

To help exploit a Profile from the buyer’s side, see the persona reading guide — in particular the buyer page.

An evolving device#

The seven-domain format presented here is a starting proposal. It is intended to evolve collectively, as new risks emerge and feedback comes in.

A public procedure allows the community to propose improvements each year: newly identified risks, newly observed good practices, simplifications of questions that have become redundant. The format’s evolutions are public, dated, and accompany declarations in their applicable version. The schema’s version number — sovereignty-v1.json today — is written into each published file, which allows existing declarations to remain readable even after a major evolution of the format.

The manifesto commits to maintaining this collective infrastructure: reference schema, evolution procedure, public index of declarations, public contestation procedure. This mission has no membership cost; it is carried by the resources of the field.

How to begin, in practice#

For a declarant who wishes to publish a first declaration:

Go to /en/profile/ and start the guided journey. At the first step, choose your category (publisher, host/cloud, distributor/integrator, or user organisation that fills in only domain 7). The steps and questions adapt accordingly.
Fill in the relevant domains along the successive steps. The draft is saved locally and can be resumed at any time; the side outline allows free navigation between steps. Where uncertainty exists, it is better to describe the uncertainty than to claim a certainty that does not exist. The domains not relevant to the use case can be left empty — no completeness score is calculated.
Download the sovereignty.json file produced at the Verify step.
Publish the file at the standardised location on the declarant’s domain, at the root: https://[your-domain]/sovereignty.json.
Notify the manifesto from /en/profile/notify, indicating the canonical URL, the name of the declarant and a moderation email (deleted after validation).
Choose and pass the challenge (DNS, HTTP or git) that proves control of the domain.
Wait for moderation (indicative deadline: five working days). On validation, the declaration appears in the public index at /en/profile/index.
Update annually, dating the new version. The daily verification meanwhile ensures that the URL still responds and that its content remains compliant with the schema.

The cost for the declarant is essentially the time spent on honest writing. No external fee is imposed. No audit is required. The rigour of the device rests on structured public publication and on the possibility for anyone to contest with evidence.

A path open to all#

This page addresses all the players that make up the European technological chain — proprietary publishers, open source publishers, hosting providers, cloud providers, integrators, resellers — as well as user organisations that wish to formalise their own commitments publicly.

The manifesto argues that this path should be recognised, encouraged by public and private buyers, and explicitly written into the European technological sovereignty programme. The declarants who commit to it are allies; the manifesto supports them.

For European proprietary publishers sometimes wrongly read as less “sovereign” than open source solutions, the device makes it possible to demonstrate concretely their guarantees on the dimensions where the proprietary license is intrinsically weak — reversibility, continuity — through publicly declared contractual commitments and escrow mechanisms.

For European hosting and cloud providers confronted with the competition of American hyperscalers, the device makes it possible to render readable what genuinely distinguishes them: jurisdiction, capital, underlying technical bricks, continuity commitments.

For distributors and integrators whose activity rests in part or in whole on the resale of foreign solutions, the device makes it possible to clarify honestly the perimeter of their added value and their capacity to ensure continuity of service beyond the mere reseller contract. Those who take on this transparency distinguish themselves from those who play on the ambiguity between the brand’s nationality and the technology’s nationality.

For user organisations — administrations, businesses, associations, professional communities — that do not supply technology but wish to go on record about their own trajectory of exposure reduction, the commitments declaration (domain 7 only) offers a readable framework, without playing the false symmetry of a provider Profile that does not fit them.

This page will be enriched in the light of contributions and concrete cases. Providers and buyers who wish to take part in the evolution of the format, and user organisations that wish to integrate the device into their internal processes, are invited to come forward via the About the site page.