Fewer systems to operate
One system with one storage contract means fewer places a copy of the data can quietly exist.
Data Infrastructure
One layer for records, documents and time.
Most data estates grew by addition: a relational system, then a document store, then something for events. The cost is not the licence, it is the code that keeps them consistent.
One application, three shapes of data, one system underneath them.
One layer for records, documents and time-ordered data, instead of one system per shape.
This is the base solution every other one builds on. Structured rows, documents and time-ordered events live in one system with one planning path and one storage contract, so a request spans shapes without leaving the layer. It is the base every other solution builds on.
One application, three shapes of data, one system underneath them.
Environment
The application
A service that already holds rows, documents and events in three different stores.
SQL · JSON / documents · Time series
Two estates, drawn.
The same shapes, held two ways. The difference is not the storage, it is where the agreement between them lives.
Separate systems Copies kept in step
One layer One plan · one contract
What this workload moves.
Every shape below is a surface of the layer, not a format to be converted into one. They are read and written together.
- SQL Records, keys and joins
- JSON / documents Documents and nested objects
- Time series Measurements and events in time order
- Events Operational events as they happen
How the workload reaches the data.
The models this workload names, the path a request takes through them, and the surfaces that speak to the layer.
Data Infrastructure · architecture
Workload
The shape of the work itself.
- Write
- Plan
- Read
- Persist
Data models
The models this workload names.
- SQL
- JSON / documents
- Time series
- Events
The layer
One path from a request to the data it names.
- Planning Predicates narrow the work before it runs
- Execution Rows, fields and windows answered together
- Transactions Readers and writers do not block each other
Surfaces
How the workload reaches the layer.
- SQL surface The query language the layer is documented in
- Applications Services and jobs reading and writing as they run
- Analytics & AI clients The same layer, the same access path
The work, stage by stage.
Choose a stage to read what happens there, or a shape to see every stage that handles it. Nothing on the map is a private interface.
PLOMID · Data Infrastructure write · plan · read · persist Select a stage
Stage
Write
Applications, services and jobs write records, documents and events
SQL · JSON / documents · Time series
01
Write
Applications, services and jobs write records, documents and events
- SQL
- JSON / documents
- Time series
02
Plan
One request is resolved against the layer once
- SQL
03
Read
Records, fields and windows answered together
- SQL
- JSON / documents
- Time series
04
Persist
One storage contract for every shape
- SQL
What changes when the data is in one place.
Stated as properties of the system rather than as results we cannot measure for you.
One definition of the truth
Reported and served numbers come from the same source, so they cannot disagree.
Questions that span shapes
A request reads records, nested documents and time windows together rather than being split per system.
A surface developers already know
The access path is SQL-shaped, documented, and runnable in a browser playground today.
What this is built on.
This solution is the layer itself, so the capabilities below are its composition rather than features on top of it.
- One data layer → Rows, documents and time-ordered events live in one system, so a question is asked once instead of once per store.
- One plan per request → A request is planned once against the layer rather than per system, which is where cross-system glue usually accumulates.
- One storage contract → Every model inherits the same durability and recovery rules instead of one guarantee per system.
- A public surface from the start → The SQL surface, the documentation and a browser playground exist today. Nothing described here needs a private API.
Workloads that sit beside this one.
Where this shows up.
Derived from the industry pages that reference this solution, so the two directions of the relationship always agree.
- Robotics → Robot state, motion traces, task outcomes and fleet coordination.
- Energy → Generation output, plant state, market positions and settlement records.
- Fintech → Ledgers, balances, product events and the relationships behind them.
- Enterprise → Systems of record, documents, workflow events and reporting in one organisation.
- E-commerce → Orders, catalogues, inventory, sessions and fulfilment events.
- Healthcare → Clinical records, encounters, observations, orders and results.
- Life Sciences → Experiment records, instrument data, sample lineage and publications.
- Pharmaceuticals → Trial data, batch records, regulatory submissions and pharmacovigilance.
- Scientific Research → Instrument output, simulation results, reference material and datasets.
- Observability → Metrics, logs, traces and the service records they describe.
- Autonomous Systems → Sensor streams, perception output, decisions, interventions and logs.
- Government → Registers, case files, service events and reporting obligations.
- Sovereign Infrastructure → Systems that must run inside a boundary, under a known operator.
- Edge Infrastructure → Compute and data close to the source, with a central record behind it.