SovereignOS · Operating system Roadmap

An AI-native operating system for sovereign organisational work.

SovereignOS is the planned customer-operated environment for SovereignEU applications, intelligence and trust controls—designed as an open alternative to proprietary desktop operating systems while keeping identity, data paths, models and updates under defined organisational control.

Status: Roadmap. SovereignOS is a planned operating system, not a currently downloadable or supported replacement. The base system, installer, licence, supported processors and devices, security architecture, update lifecycle, application compatibility and deployment modes will be published and evidenced per release.

One coherent workspace

See the operating system—not just a list of features.

The concept below shows the intended experience: recognisable applications, a shared AI intent surface, permission-checked context, an explicit model route and approval before a consequential action.

SovereignOS Regional administration · Customer boundary Local control
AI intentPrepare the mobility committee brief from approved project records Super K
Office ApplicationsDraft · source-linked

REGIONAL TRANSPORT · 23 AUGUST 2026

Decision brief: shared mobility procurement

Three open decisions have been assembled from the approved project register, procurement policy and committee record.

Recommended next stepConfirm accessibility criteria before tender release.

6 approved sources · 2 passages need review

Organisation identityLocal model routeSigned update policyReviewable activity record
Applications and governed AI in one operating environment.Roadmap interface concept. It illustrates the intended relationship among applications, context, models, permissions and approval; it does not represent a currently available release.

Operating-system architecture

An operating system—not another application.

SovereignOS is the enclosing product. Applications remain distinct and portable while shared system services provide identity, context, model routing, policy, updates and operational evidence.

Integrated by default. Portable by design. Published formats, interfaces, configuration and export paths are intended to let organisations adopt or replace components without surrendering their records or operational knowledge.

Customer-controlled SovereignOS boundary

Validated hardware or virtual environment · Customer-selected infrastructure · Defined operator and jurisdiction

AI-native by architecture · Roadmap

AI becomes a governed system service.

AI-native means that applications can use common context, model and tool services under the current identity and policy boundary. It does not mean unrestricted access, silent surveillance or autonomous production change.

Bounded context

Retrieve only the approved, permission-checked evidence relevant to the current user and task.

Customer-defined model routes

Select and operate supported local or agreement-defined models, with the actual route visible for each deployment.

Permissioned actions

Expose intended tools, data scope and effects before agents act across applications.

Approval and evidence

Retain sources, policy, approvals, actions, versions and outcomes for review and rollback where supported.

Explore Sovereign Intelligence

Cross-application work

One request. A controlled path through the system.

The operating system can coordinate approved context and proposed actions while each application retains responsibility for its records.

  1. AskThe user states an outcome in the shared intent surface.
  2. ResolveIdentity, task and policy determine the permitted context and model route.
  3. PrepareApplications and agents assemble a source-linked draft and proposed actions.
  4. ApproveThe user reviews recipients, data boundary, evidence and consequential effects.
  5. RecordApproved artefacts, actions and outcomes return to their owning applications.

Release evidence

A credible operating-system alternative must prove the foundations.

Each supported SovereignOS release will need dated, version-specific evidence. Roadmap intent is not a substitute for implementation, testing or operational ownership.

Boot and system integrity

Base distribution and kernel provenance, verified or secure boot scope, installer signing and recovery conditions.

Data and device protection

Encryption, credential storage, sandboxing, administrative access and lost-device procedures.

Updates and rollback

Signed packages, release rings, maintenance windows, tested rollback and supported lifecycle dates.

Hardware and accessibility

Supported architectures, devices, drivers, peripherals, assistive technology and tested accessibility coverage.

Compatibility and exit

Document formats, browser and protocol coverage, application packaging, export and migration evidence.

Software and model provenance

Repositories, exact licences, SBOMs, model terms, dependencies, security contacts and reproducible artefacts.

Migration without a forced big bang

Translate familiar work, validate the boundary, then expand.

A real alternative must coexist with current devices, identities, formats and services while teams establish operational confidence.

  1. 01
    Map the current workstation

    Inventory hardware, applications, formats, peripherals, identity, security and accessibility needs.

  2. 02
    Choose a bounded cohort

    Define users, workflows, interoperability needs and measurable acceptance criteria.

  3. 03
    Operate in parallel

    Validate installation, updates, recovery, daily work, support and export before retiring dependencies.

  4. 04
    Expand by evidence

    Add devices and functions only after the applicable hardware and workflow scope is accepted.

Shared Roadmap capability

SovereignEU Improvement Loop

Customer-authorised signals and outcomes can support evaluated candidate improvements inside the deployment boundary. Customer-defined policy, approval, versioning and rollback govern release.

Explore the Improvement Loop

Complete Roadmap portfolio

Applications, intelligence, core services and trust.

Explore the seventeen defined product responsibilities intended to operate within SovereignOS. Their individual availability, release terms and supported boundaries remain explicit.

Explore what is inside SovereignOS

Planned operating modes

Match the system image to an evidenced environment.

Actual availability will depend on the released version, supported hardware, network assumptions, update path and named operational responsibilities.

01

Verified workstation

A supported SovereignOS image installed on a published device and peripheral configuration.

02

Organisation-managed fleet

A governed image, identity policy, application set and update ring operated by the accountable organisation.

03

Virtual or restricted environment

A virtual workspace or restricted-network deployment only where installation, operation, updates and support have been tested.

A practical first step

Define the first SovereignOS cohort.

Bring the hardware, applications, identity, data, AI, security, accessibility and migration requirements that determine a credible pilot boundary.

Discuss a design partnership