OrdinateDB

Platform · Unified namespace

SPEC 01–02

The UNS answers ‘what is it now’. We answer ‘what was it, and why’.

OrdinateDB plays three roles around a unified namespace: it consumes the namespace today, it keeps the history the broker was never designed to hold, and — on the roadmap — it publishes the namespace from a governed model instead of a topic convention. In that order. Only the first two exist.

UNS consumer — available now

SPEC 02 §3

Point the collector at the broker. Modelling can wait.

The MQTT Sparkplug B collector subscribes to your namespace tree — births, deaths, aliases, sequence numbers handled properly. Each topic path becomes the source URI, and every signal auto-provisions into staging as its own series: full retention, full query access, from the first message. Binding a staged series to a modelled attribute is the normal series-lifecycle workflow SPEC 01 §6 — audited, time-versioned, and retroactive by default, so the history you recorded before modelling is visible through the attribute afterwards.

The broker link gets the same treatment as any other source: a local write-ahead log acknowledges each point before transmission is attempted, and outages drain as backlog rather than loss SPEC 02 §6. If someone restructures the topic tree, that is a new source URI and a new staged series — splicing the histories is an explicit, audited reconciliation, never a heuristic.

Consuming a UNS is table stakes. We list it so you can tick it, not because it is interesting.

staging · mqtt/sparkplug-b · uns-broker-01
site-east/crushing/crusher-01/motor-currentbound · Crusher01.MotorCurrent
site-east/crushing/crusher-01/statebound · Crusher01.State
site-east/utilities/chiller-03/power-kwstaged · queryable
auto-provisioned this month312 series
retention in stagingfull, from first message

the topic path is kept as the source URI. binding later is retroactive — nothing recorded before modelling is out of reach after it.

Why a UNS needs a historian

SPEC 00 §1

The broker holds the plant’s present. Somebody has to keep its past.

A broker is a state hub. It holds current values and moves change streams, and its memory is a retained message — one message deep. No history, no aggregation, no provenance, no quality lineage, no batch context. None of that is a defect; it is what a state hub is for, and it is why every production UNS architecture hangs a historian off the broker.

That is the division of labour here. The broker answers ‘what is it now’ and fans it out to every consumer on the plant. OrdinateDB subscribes like any other consumer and answers ‘what was it, and why’ — what the value was through the night shift, what the hourly average was and what evidence sits behind it, which batch was running at the time, and whether the flat line at 03:00 was a steady process or a dead sensor. We are not competing with the namespace. We are the memory it doesn’t have.

division of labour · broker + historian
brokerOrdinateDB
current value, fanned out plant-wide
change stream to any subscriber
retained history1 messageall of it
aggregates, with provenance
batch & downtime context
namespace history, as of a dateplanned

both, deliberately. the broker distributes the present; the historian keeps the past. neither is trying to do the other’s job.

Raw-first retention

Nothing is discarded by default. Where retention genuinely requires thinning, it is a named, versioned, audited policy — and queries over thinned ranges say so.

Provenance on every number

Percent-good, lossy ranges, provisional windows, manual origin — the evidence travels with the result, and the API never invents a number.

Episodes for batch and downtime

Batches, runs, excursions and stoppages are first-class spans over the same series — the context a change stream cannot carry.

Licensing that survives a big namespace

Priced per instance, never per tag. Subscribing to another fifty thousand topics is your broker’s business, not our invoice’s.

Model-driven UNS · Planned — Spec F2

SPEC 01 §1

The namespace as a published model, not a topic convention.

planned — not yet built

First the diagnosis. In most deployments, a UNS’s semantic structure lives in the topic strings themselves, maintained by whoever wired the broker. There are no templates, no versioning, no governance, and no way to ask what changed in the namespace last March. The hierarchy is real and useful — but its identity is smeared across its representation, so a renamed topic is a new thing and the old one silently ceases to exist. It is the same disease as string-pointer element references: the address doing double duty as the identity SPEC 01 §1.

OrdinateDB’s model already is what a namespace wants to be: governed, versioned, templated, addressed by identity rather than by string, with every change an audited event. Which means it can be published. The plan: topics generated from the composition tree and its views, enumeration concepts and units of measure travelling as Sparkplug metadata rather than tribal knowledge, and namespace changes arriving as audited model events instead of someone editing a topic string. OrdinateDB becomes the source of semantic truth for the UNS, rather than a subscriber to someone else’s string conventions.

The design sketch is Spec F2 — UNS publishing, in the open spec set. None of it exists yet. When it does, this section will get evidence instead of prose.

The consumer works today, the history is the point, and the publisher is a design sketch. The demo shows the first two; the third stays prose until it ships.