Unified data infrastructure
GitHub Let's talk

Sovereign Infrastructure

Data that stays inside the boundary you define.

Some systems are defined by where they are not allowed to be. That is a design constraint, and it has to be respected before it is promised.

See Data Infrastructure All of Public & Sovereign

The same layer, with hard boundaries drawn around operation, residency and exit.

The story

The same layer, with hard boundaries drawn around operation, residency and exit.

Where it starts

Operational records

The registers, cases and transactions the service depends on. It is the first of 4 workloads running in Sovereign Infrastructure.

The question it raises

A boundary you can state

One system and one storage contract mean the boundary is describable rather than assembled from components.

Why one question is hard

From Boundary to Exit

Sovereign Infrastructure data moves through 4 stages — Boundary → Operate → Control → Exit. The shapes in play are SQL, JSON / documents, Time series, Objects, and answering one question means reading across all of them.

What PLOMID contributes

Sovereignty is a set of properties, not a deployment diagram. These are the ones the layer carries today.

  • Deployment is a decision Self-hosted, edge and managed topologies are design destinations of the deployment fabric, and the fabric is specified as its own part of the platform.
  • Control over operation Who runs the system, and where it runs, is part of the first conversation rather than a tier on a pricing page.
  • One storage contract Every model inherits the same durability and recovery rules instead of one guarantee per system.
The environment

Systems that must run inside a boundary, under a known operator.

A sovereign deployment is the same data layer with hard boundaries around operation, residency and exit. PLOMID is one system with one storage contract, which is what makes those boundaries describable at all, and the deployment fabric is the part of the platform that carries them.

Deployment & residency

Where this data is allowed to run.

Inside a boundary you control, operated by people you can name, with an exit you can describe.

Deployment, residency and control
The data journey

How sovereign infrastructure data reaches one layer.

Walk the path the data takes, from the environment that produces it to the questions it answers. Select a station, or a shape, to read each step.

The same layer, with hard boundaries drawn around operation, residency and exit.

Environment

The boundary

Where the system is allowed to run, decided before anything is deployed.

SQL

One environment · many workloads

What runs against sovereign infrastructure data.

4 workload families over one set of shapes. Choose one to see what it moves and where it lands.

The registers, cases and transactions the service depends on.

  • Planned once against the layer, not once per store
  • Read beside the records it shares a key with
  • Persisted under one storage contract
Where the data goes to work

Questions asked inside the boundary.

Each one is answered where the environment allows, from the same layer rather than a copy that drifted.

A boundary you can state

One system and one storage contract mean the boundary is describable rather than assembled from components.

  • SQL

Operator known

Who runs the system, and where, is a named property rather than an inference.

  • SQL
  • Time series
  • JSON / documents

Exit as a design property

Portability follows from the storage contract rather than from an export tool added later.

  • JSON / documents

Smaller surface to secure

Fewer systems means fewer places a copy can exist, which is the whole point of the constraint.

  • Objects
Data models in play

The shapes, in one layer.

4 shapes carry this domain. Choose a stage to read the operation, or a shape to see every stage that handles it.

PLOMID · Sovereign Infrastructure boundary · operate · control · exit Select a stage
Stage

Boundary

Where the system is allowed to run

SQL

Workload map Sovereign Infrastructure workload map. Every shape on it is a surface of the layer, and each stage names the part of the operation it carries.
  • SQL Records, keys and joins
  • JSON / documents Documents and nested objects
  • Time series Measurements and events in time order
  • Objects Large assets with queryable metadata
Workload architecture

The boundary, then the path.

The environments set what the architecture may do — then the work, the shapes and the path a request takes.

Sovereign Infrastructure · workload architecture
Workloads

What runs against this data.

  • Operational records
  • Time-ordered activity
  • Controlled documents
  • Boundary reporting
Data models

The shapes those workloads read and write.

  • SQL
  • JSON / documents
  • Time series
  • Objects
The layer

One path from a request to the data it names.

  • Planning Predicates narrow the work before it runs
  • Execution Records, fields and windows answered together
  • Transactions Readers and writers do not block each other
Surfaces

How the work reaches the layer.

  • SQL surface The query language the layer is documented in
  • Applications Services and jobs writing and reading as they run
  • Analytics & AI clients The same layer, the same access path
What you build next

Data Infrastructure

One layer for records, documents and time-ordered data, instead of one system per shape.

If A boundary you can state is your question, start here.

See Data Infrastructure Every solution
Next

Where to go next

Solutions The workload answers this industry leans on, with their models and status. Platform The data models in the product today, and the ones extending the layer. Architecture How a request is planned, executed and persisted once it reaches the layer.