Unified data infrastructure
GitHub Let's talk

Smart Infrastructure

Cities, utilities and transport read as one system.

Smart infrastructure is public-facing operational data: it has to be current, it has to be explainable, and it has to outlive the vendor that installed the sensors.

See Time-series Workloads All of Infrastructure & Technology

A public claim about a network backed by queryable data, not a dashboard.

The story

A public claim about a network backed by queryable data, not a dashboard.

Where it starts

Sensor telemetry

Occupancy, environment, traffic and energy measurements. It is the first of 4 workloads running in Smart Infrastructure.

The question it raises

City-scale reporting

Consumption and availability compute over the operational source rather than a reporting extract.

Why one question is hard

From Sense to Report

Smart Infrastructure data moves through 4 stages — Sense → Control → Maintain → Report. The shapes in play are Time series, SQL, Events, Geo, JSON / documents, and answering one question means reading across all of them.

What PLOMID contributes

Public infrastructure is judged on continuity. These are the parts that keep the record durable.

  • Time-ordered storage Measurements and events are stored beside the records and documents they describe, so history and current state agree.
  • One data layer Rows, documents and time-ordered events live in one system, so a question is asked once instead of once per store.
  • 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.
The environment

Buildings, transport and civic systems with sensors attached.

Building systems, transport networks and civic sensors produce telemetry, hold asset records and generate events. PLOMID keeps the measurements with the assets and events they belong to, so a public-facing claim about a network is backed by queryable data rather than a dashboard.

Workload architecture

The system reading itself.

Planning, execution and transactions first — then the workloads that use them and the shapes they name.

Smart Infrastructure · workload architecture
Workloads

What runs against this data.

  • Sensor telemetry
  • Asset and site records
  • Service events
  • Operational reporting
Data models

The shapes those workloads read and write.

  • Time series
  • SQL
  • Events
  • Geo
  • JSON / documents
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
One environment · many workloads

What runs against smart infrastructure data.

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

Occupancy, environment, traffic and energy measurements.

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

How smart 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.

A public claim about a network backed by queryable data, not a dashboard.

Environment

The estate

Buildings, transport and civic systems with sensors attached.

Time series

Data models in play

The shapes, in one layer.

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

PLOMID · Smart Infrastructure sense · control · maintain · report Select a stage
Stage

Sense

Environment, traffic and energy measurements

Time series · Geo

Workload map Smart Infrastructure workload map. Every shape on it is a surface of the layer, and each stage names the part of the operation it carries.
  • Time series Measurements and events in time order
  • SQL Records, keys and joins
  • Events Operational events as they happen
  • Geo Location as a queryable dimension
  • JSON / documents Documents and nested objects
Where the data goes to work

Questions a fleet asks about itself.

Each one reads telemetry with the records that explain it, from the same layer rather than a sidecar store.

City-scale reporting

Consumption and availability compute over the operational source rather than a reporting extract.

  • Time series
  • Geo

Asset accountability

Systems, controllers and sensors are records, so responsibility is queryable.

  • SQL
  • Events

Fault and works history

Faults and works orders sit beside the measurements that triggered them.

  • Events
  • JSON / documents

Vendor-independent data

Data outlives the system that produced it, because the records are not owned by a device platform.

  • SQL
  • Time series
Deployment & residency

Where this data is allowed to run.

Infrastructure is distributed by definition, so a central record with local reads is the practical shape.

Deployment, residency and control
What you build next

Time-series Workloads

Measurements and events stored beside the records they describe.

If City-scale reporting is your question, start here.

See Time-series Workloads 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.