Organization / Mission

AI sovereignty

Intelligence on
your terms.

The ability to use AI should come with the power to direct it.

AI sovereignty is the ability to make informed choices about the intelligence a person or organization depends on: what knowledge it can use, which models it runs, where computation happens, and what actions it can take.

It means being able to understand the system, set its boundaries, and change course when your needs or the technology change. The goal is practical agency throughout the life of an AI system.

What we’re building toward

01

Control your data.

Decide where knowledge lives, who can access it, and how it is used. Keep context portable as your systems evolve.

02

Choose your models.

Use the models that fit the work. Preserve the freedom to switch providers and integrate open models as needs change.

03

Own your operating environment.

Choose where intelligence runs, with a path toward infrastructure you control and systems you can adapt.

04

Keep people in command.

Make actions inspectable, permissions explicit, and consequential decisions subject to human judgment.

A long-term mission. Built one system at a time.

Explore the work

01 / The control surface

Knowledge → intelligence → action

Sovereignty is a
system property.

AI relies on a chain of connected choices. Control at one point is not enough if another layer can move your data, lock you to one model, or act without your authority. We think about agency across the full path.

A working map FOUR CONNECTED LAYERS
01 / INPUT

Knowledge

Sources · context · access

02 / MODEL

Intelligence

Provider · version · choice

03 / RUNTIME

Compute

Location · dependencies

04 / OUTPUT

Actions

Tools · permissions · review

People set the terms

Policies · permissions · visibility · the ability to change or stop

CONTROL / ALL LAYERS
A useful AI system keeps its inputs, dependencies, operating location, and actions legible to the people responsible for it.

02 / A practical standard

Agency you can exercise

Can you choose,
understand, and change it?

Sovereignty is not one checkbox or one deployment model. It is the ability to make consequential choices across the system—and keep that ability over time.

A

Choice

Select models, providers, and where work runs to suit the task, policy, and people involved.

Can I choose?
B

Visibility

Know what information is used, what a system depends on, and which actions it is allowed to take.

Can I understand?
C

Continuity

Keep your knowledge and workflows useful as models, vendors, and infrastructure change.

Can I change course?

Running locally can help in some situations; it does not, by itself, guarantee control. What matters is who can access, direct, move, and stop each part of the system.

03 / The test of change

An architectural principle

The system will change.
Your agency should remain.

A model improves. A provider changes direction. A workflow becomes critical. Sovereignty matters most when you need to make a different choice.

CONTINUITY / THROUGH CHANGEILLUSTRATIVE ARCHITECTURE
PRESERVE

Your knowledge.

Context, sources,
and working history.

KEEP REPLACEABLE
Model / AModel / B
HostedSelf-managed

Choose for the work.
Re-evaluate as needs change.

PRESERVE

Your intent.

Objectives, permissions,
and acceptance criteria.

Human authority spans the system. The ability to inspect, redirect, and stop should survive a change of technology.

A design objective: keep knowledge and policy separable from the components that process them. Portability still requires deliberate engineering and verification.

WHEN PRINCIPLES MEET REALITY

Control is something
you can exercise.

Three situations that reveal whether a system leaves room to choose.

01When the model changes.

A new model should be a decision you can evaluate. Keep representative tasks and acceptance criteria, compare results, and understand what will change before moving the work.

THE TEST / Can you switch without losing the context?
02When the data must move.

Changing environments should not mean starting from zero. Know what can be exported, which dependencies must be rebuilt, and how access rules will carry into the next system.

THE TEST / Can you take your working knowledge with you?
03When an action needs to stop.

Authority needs a practical mechanism. Make consequential actions visible before execution, define who may approve them, and distinguish stopping future work from reversing an action already taken.

THE TEST / Can a responsible person intervene in time?

04 / Mission into practice

The work ahead

A long horizon.
Concrete next steps.

Our mission sets the direction. The tools we build are how we put it to work.

Bring us a problem worth solving