1. What — A public reference for European digital infrastructure

The core platform

i12e.eu brings together information about company-backed, hosted platforms and open-source projects across core digital infrastructure categories.

Coverage includes:

• Cloud infrastructure and related managed services.
• Transactional email, marketing email, and email inbox platforms.
• Content management systems.
• Payment service providers and tax platforms.
• Billing, subscription management, and invoicing platforms.
• Social platforms and other categories of core digital infrastructure.

The underlying reference is sector agnostic. It should support people choosing infrastructure for organizations, production systems, experiments, and personal projects.

A comparison shaped by the visitor’s context

The website begins with a configurable statement, for example:

I am a compliance officer, looking for cloud infrastructure, in the European Union.

Visitors change their role, infrastructure category, and geographic scope. Those choices determine which information is emphasized and how providers are compared.

Below the statement, a comparison table presents the relevant data, potentially supported by one or two graphs. The experience should make useful differences immediately visible.

A compliance officer might see certifications and compliance evidence. A software engineer might prioritize self-service access and running containerized applications. A cloud engineer might examine managed services, infrastructure automation, and operational control.

Public data for people and AI tools

The dataset should be publicly available, freely downloadable, and free to reuse in other tools, services, and products.

AI assistants should also be able to consult and reference it when helping people choose infrastructure. The ambition is for tools such as ChatGPT and Claude to draw on this maintained reference, reducing the need to repeat the same provider research independently.

Public availability and reuse are commitments. Particular download formats, access interfaces, and AI integrations remain to be defined.

Applications built on the data

The first sector-specific application concerns Dutch journalism. It will use the infrastructure dataset to:

• Map news organizations’ technology dependencies.
• Identify relevant alternatives.
• Compare organizations with their peers.
• Provide tailored guidance informed by available infrastructure and sector adoption.

This application may sit on a separate subdomain. The core reference remains useful independently of it.

Over time, the same approach could be repeated in other sectors: establish contact with organizations, understand their dependencies, and use the shared data to support informed decisions.

2. Why — European digital autonomy, capability, and direction

i12e.eu aims to advance European digital autonomy by reducing exposure to external leverage, sustaining European jobs and innovation, and giving Europe greater control over its technological future in line with its values.

Reduce exposure to external leverage

The project responds to the strategic risks created by dependence on infrastructure controlled outside Europe. Making European alternatives visible and comparable should help organizations understand their options and make informed decisions about those dependencies.

Sustain jobs, expertise, and innovation

The motivation includes Europe’s capacity to develop its own technology.

Infrastructure choices influence where expertise accumulates, where products are developed, and where opportunities to innovate emerge. The project aims to support a self-sustaining European infrastructure ecosystem with the people and capabilities needed to build, maintain, and improve its digital foundations.

Shape technological direction

Europe should have greater capacity to determine how its infrastructure develops and which priorities its technology serves.

The project connects that ambition to practical decisions: discovering suitable platforms, comparing their strengths and limitations, and understanding the consequences of choosing them.

3. Who — A collective audience, supported by an independent foundation

The people using the platform

The audience is deliberately collective. Executive decisions and developers’ everyday choices should reinforce one another.

Software engineers and cloud engineers may warrant separate perspectives because their immediate requirements differ. The final role definitions should be refined through research while keeping the selection manageable.

Adoption from both directions

Executives can create organizational demand for suitable European platforms. Developers can become familiar with those platforms through prototypes, hobby projects, and everyday work, then bring informed recommendations into their organizations.

Both paths matter from the outset.

The people responsible for the project

The project’s intended organizational home is an independent nonprofit foundation.

Human responsibility includes engineering, user experience, source approval, country onboarding, research, communication, marketing, and securing funding. AI agents perform the repeatable collection and maintenance work that makes broad coverage possible.

4. Where — Coverage follows funding, with a path for expansion

The funding and coverage policy

Geographic coverage follows the funding available for that work.

The amounts sought from additional countries should be limited contributions appropriate to supporting their inclusion.

These are the project’s intended funding arrangements. Future grants and their specific coverage have not yet been secured.

Demand for additional countries

The website should provide an ongoing way for visitors to request countries that are not covered, potentially through a running poll.

Sufficient demand would trigger an investigation. A request or vote would not itself guarantee inclusion.

Monaco remains a possible additional country; its specific funding and inclusion route is not yet settled.

Provisional scope and the underlying eligibility principle

The provisional scope of future expansion remains dependent on funding, demand, and the assessment of additional countries.

The underlying eligibility principle for EU alignment remains open and subject to change. Demonstrable alignment through laws and government policy is a possible future basis for inclusion, but the requirements and assessment method have not been defined.

Geographic coverage determines which countries are researched. The sovereignty of an individual provider is assessed through the more detailed evidence and controls described under How.

Published datasets remain freely reusable regardless of where their users are located.

5. When — Dutch delivery first, followed by broader expansion

Development and delivery sequence

The funded incubator work must remain within the Dutch context. International expansion follows that phase.

Broader Dutch coverage is intended to follow the journalism work; its exact category-by-category completion schedule remains to be established.

Automation is expected to accelerate country onboarding and data expansion as the framework matures. Expansion will still require supervision and refinement, potentially extending beyond an initial month.

What success would look like after the first year

The ambition is:

• An effectively complete overview of serious infrastructure options across the intended countries and product categories.
• Recognition as the place to go for an overview and comparison of European infrastructure.
• Use of the dataset as a reference by AI assistants supporting infrastructure decisions.
• A working Dutch journalism application and the ability to extend that approach to other sectors.

The pace of geographic expansion depends on funding. Use by external AI tools is an intended outcome to pursue.

6. How — Automated maintenance, contextual comparison, and independent stewardship

Establish sources and country checks

Humans approve new websites and sources and oversee the onboarding of each country.

Country onboarding establishes the relevant company-register checks and other sources needed to assess entities. Once configured, routine checks of company existence should run automatically.

Company-register checks support entity validation. Provider websites and documentation supply evidence about offerings, features, and dependencies. The system should distinguish what the available sources establish from information that remains incomplete or unverified.

Maintain provider data through agents

Agents periodically examine approved provider and project websites, documentation, and relevant company records.

They maintain information about:

• Product offerings and capabilities.
• Relevant operational dependencies.
• Corporate entities and relationships.
• Company existence and available organizational information.
• Open-source funding, maintenance activity, and project health.

Companies should be able to request a fresh scan using an email address associated with their website. An email confirmation triggers the rescan; any resulting data changes still come through the agent’s source-based collection process.

Correct information at its source

When information is incomplete or cannot be verified, the platform should make that state visible. It should be possible to distinguish missing information, unverified information, and verification attempts that remain unresolved.

The follow-up process is to contact the provider, seek clarification, communicate the substantive clarification publicly, and request that the provider’s own published information be improved.

Provider-data corrections should then enter through agent rescans of those published sources. Manual editing of provider records is not the intended correction mechanism.

This makes subsequent scans able to revisit the same evidence and monitor for changes.

In the regular view, incomplete or unverified information should produce a notice. The final preference is to disclose that uncertainty rather than impose an automatic ranking penalty solely because the information is missing.

Uncertainty should affect the strict sovereignty view. Its exact effect on filtering or ranking remains to be defined.

Separate company location from sovereignty assessment

For company-backed platforms, headquarters and incorporation location are the initial geographic anchors for country placement.

The dataset should separately document:

• The company’s headquarters and incorporation.
• Ownership and control.
• Parent-company relationships.
• Distinct owning and operating entities.
• Relevant infrastructure and service dependencies.

Those relationships should have visible indicators and references so visitors can understand and filter them.

A provider may remain in the general comparison despite having non-European ownership or dependencies. For example, a provider based in the Netherlands with a US parent company can be listed with that relationship clearly identified, while being excluded from a strict European sovereignty view.

Where headquarters and incorporation differ, the precedence rule for country placement remains open.

Provide configurable sovereignty views

The default comparison emphasizes usefulness, innovation, and suitability within a product category, alongside the evidence relevant to the visitor’s role.

A separate strict sovereignty mode applies tighter requirements to ownership, control, and dependencies. Its geographic boundary should be configurable: EU-only requirements can be distinguished from broader selections involving the EEA, Switzerland, or the United Kingdom.

Known relationships outside the selected boundary can exclude a provider from that strict view.

Portability and the ability to move away from particular dependencies may also inform an assessment where evidence is available. Their treatment should reflect the actual platform.

Assess open-source projects on their own terms

Open-source projects need a distinct assessment because their deployment location can vary and they may not correspond to a conventional hosted provider or incorporated company.

Relevant information includes:

• Where project funding comes from.
• How actively the project is maintained.
• Its health and track record.
• Its apparent outlook and continuity.

Company-specific assumptions should not automatically be applied to open-source projects. Their geographic attribution and detailed assessment criteria remain to be developed.

Rank for usefulness, supported by public evidence

A high ranking should indicate that a provider meets the needs of people using products in that category relatively well, taking the selected role into account.

Potential inputs include:

• Features and practical capabilities.
• Compliance information.
• Track record, reputation, and years in operation.
• Staffing and organizational capacity.
• Funding and publicly available financial information.
• Evidence about customers, where available.
• Ownership and operational dependencies where relevant to the selected context.

These are candidate signals to assess together. Their weights, measurement methods, and thresholds have not been settled.

Everything that feeds a ranking should be public, including the relevant evidence and the method used to combine it.

Surveys and research with people across roles, industries, and categories should determine which comparisons are immediately useful.

The rankings should encourage providers to compete and improve by making capabilities and shortcomings visible. The presentation remains practical and informative; competitive pressure follows from the comparison.

Fund development and continuing operation

The preferred development model is public funding sufficient to support approximately one year of development work, together with compute and AI model usage costs.

After the initial build, continuing operation may be supported through EU or national funding and sponsorship. Advertising or commercial sponsorship could supplement recurring costs, particularly the costs of agents maintaining coverage in individual countries.

Advertising is not the preferred foundation for initial development because it would not reliably enable immediate full-time work and introduces concerns about influence.

The project will continue to require compute and model usage funding even if some work is eventually supported by volunteers. A fully open-source or volunteer-led software model has not been selected.

Protect independence through transparency

If advertising or sponsorship is accepted, the proposed safeguards are:

• Public disclosure of contracts, their dates, and amounts.
• Public financial accounts.
• Potential publication of invoices.
• Predefined advertising locations.
• Contractual restrictions on influence over rankings and on advertising placement negotiations beyond the defined arrangements.

Financial support should not determine comparison results.

Factual clarification should continue through the public-source correction process. This keeps necessary communication about accuracy distinct from attempts to influence a ranking.

The foundation’s detailed governance, contractual terms, and long-term funding mix remain to be developed.

Decisions deliberately left open

The document preserves the following matters as open:

• The EU-alignment criteria for additional countries and the level of demand that should trigger investigation.
• Ranking methods, role-specific weights, and ways to assess reputation and organizational health.
• The treatment of incomplete evidence in strict sovereignty mode and the depth of dependency verification.
• Country attribution where headquarters and incorporation differ, and geographic treatment of open-source projects.
• Specific funding programmes, contribution amounts, foundation governance, and invoice-publication policy.
• The formal data licence, export formats, and interfaces for reuse by other services and AI tools.

These open matters do not prevent the project definition from being published. They should remain visibly open until decisions are made.