Sovereignty control dimensions

Why control must be separated into dimensions

A system may be strong in one dimension and weak in another. For example, an organization can operate inference on-premises while depending on an uncontrolled public package repository for every rebuild. A single “sovereign” label hides this difference.

Assess each dimension separately, record its current state, and make trade-offs explicit.

Data control

Data control covers more than storage location. Determine:

• Which data classes may enter the system.
• Where prompts, files, embeddings, indexes, logs, caches, and backups reside.
• Which identities can read, transform, export, or delete each class.
• Whether permissions survive ingestion and retrieval.
• Which egress paths exist and how they are enforced.
• How retention, legal hold, deletion, and recovery work.

Evidence may include data-flow diagrams, access-policy exports, storage configuration, DLP decisions, retrieval permission tests, and deletion records.

Model control

Model control concerns the full model lifecycle:

• Provenance, ownership, license, and acceptable-use conditions.
• Evaluation against the intended workload and risk.
• Packaging, hashing, signing, approval, and internal promotion.
• Runtime parameters, system instructions, adapters, and quantization.
• Update, rollback, vulnerability response, and retirement.

Possessing model weights is useful, but control also requires the ability to reproduce what was evaluated and deployed.

Infrastructure and dependency control

This dimension covers compute, networking, identity, storage, orchestration, and the software supply chain. Ask:

• Can the workload run inside the required boundary?
• Which control planes or administrators remain external?
• Which images, packages, drivers, operators, and services are required?
• Can approved artifacts be rebuilt, restored, and patched without uncontrolled public pulls?
• Are keys, secrets, routes, and policy decisions under an accepted authority?

External infrastructure can be compatible with sovereignty when decision rights, access, portability, and exit conditions are explicit.

Operational control

Operational control is the ability to keep the system safe and useful over time. It includes:

• Release approval and change management.
• Observability, evaluation, capacity, cost, and service objectives.
• Incident response, containment, forensics, and notification.
• Backup, restore, continuity, and disaster recovery.
• Skills, documentation, support dependencies, and operational handover.

A design that cannot be safely operated or recovered is not a durable sovereign capability.

Evidence and assurance control

Evidence control answers: “How do we know?” Useful evidence is attributable to a system and version, protected from inappropriate change, understandable by its audience, and retained for the required period.

Examples include architecture decisions, model hashes, container digests, evaluation results, policy decisions, approvals, deployment manifests, audit events, exceptions, incident records, and recovery-test results.

See Evidence by design for the evidence-planning method.

Use a profile, not a binary label

Record a short statement for each dimension:

Required control:
Current implementation:
External dependencies:
Evidence available:
Known gap:
Owner and next action:

This creates a sovereignty profile that can be reviewed and improved. It is more honest and useful than declaring the complete system “sovereign” without qualification.