Skip to main content

Building applications on DataHub

EngineersIntegratorsLeadership
In one minute

Everything the console does, it does through the same API your own software can call. That makes DataHub a foundation to build on: an application written against it inherits the model, live delivery and access control, instead of rebuilding all three the way every stand-alone dashboard does.

The best-known platforms in this category earned their reputations less through their own screens than through the applications customers built on top. The same is true here, and it is why the API surface is small and stable: four primitives, learned once.

What your application inherits​

The hard part of most industrial appsWhat the platform hands you instead
Context, knowing which signal belongs to which machineThe knowledge graph: your app traverses relationships instead of shipping its own mapping tables
Freshness, polling loops and refresh timersSubscriptions: data pushed at millisecond latency, position held across reconnects
Access control, per-app user lists and permission codeData set permissions ride the user's token; your app cannot show what the user may not see
History, a store for what happenedEvents and time series, queryable back through time
DocumentsFiles, reachable from the equipment they describe

The economic consequence is the one the cost-of-doing-nothing argument makes in reverse: a conventional dashboard rebuilds context locally and throws it away, so its cost repeats per app. An application on the model reuses the context, so each new application gets cheaper than the last, the same compounding as the questions.

The first application worth building​

Build the equipment 360: one screen per piece of equipment, showing everything the model knows about it, live signals, open events and work orders, documents, and its neighbours in the graph, aimed at the person holding the tools, on whatever device they carry.

This is the application pattern behind the most celebrated success stories in this category, at aerospace manufacturers and offshore operators alike, and the reason is consistent everywhere it has been built: preparing a job used to mean an hour or more collecting information from four or five systems, and with the app it is minutes, for every job, every day. The published case studies report double-digit efficiency gains in field-work preparation from exactly this pattern.

Four properties make it the right first app:

  • It is read-only. No control-system risk, no writeback approvals, no guardrail debates. The riskiest thing it can do is show the truth.
  • It exercises every primitive. Resources, series, events, files and a live tail on one screen: if the equipment 360 works, your model works, which makes it the honest end-to-end test of everything on this site.
  • The value recurs daily and is measurable. Baseline how long job preparation takes today, the same discipline as measuring return, and measure it again with the app in the field.
  • It makes the model visible. An operator who has seen their plant as one connected screen understands the platform faster than any presentation. The first app is also the internal argument for the second.

The shape is deliberately simple: resolve the equipment from a search, a scan or a tag prefix, then one traversal outward for context, one query per attached series, the event log filtered to the same resources, and a live tail for the signals on screen.

What people build next​

  • An alert router. A durable subscription watching for typed events and delivering them to the channel each team actually reads. The first taste of push-instead-of-poll operations.
  • A morning report generator. Yesterday's events, excursions and KPIs, compiled into the document the 07:00 meeting already uses, the reporting half of the agent story, buildable without an agent.
  • Field capture. The equipment 360's writeback sibling: findings, readings and photos recorded as events and files against the resource, so field knowledge lands in the model instead of in a notebook.
  • A soft-sensor host. External computation reading by subscription and writing derived series back, the pattern functions will eventually absorb in-platform.
  • Agents. An agent is an application in this sense too, the same API, the same permissions, the same event log recording what it did. AI agents →

Design rules that keep apps honest​

  • Write results back into the model. An app that computes something useful and keeps it in its own database has built a new silo on top of the platform that exists to remove them. Derived numbers belong in series, findings in events, connected to the resources they concern.
  • Match on external ids, never on names. Names change freely; your app should not care.
  • Use a service account with the narrowest grants that work, and remember write does not imply read.
  • Build consumers idempotent. A durable subscription redelivers unacknowledged data after a reconnect; seeing a datapoint twice must be harmless.
  • Do not cache permissions. The platform authorises every request afresh; an app that caches visibility decisions reintroduces exactly the stale-access problem the platform avoids.

Where the developer detail lives​

This page is the map, not the reference. The API, SDKs, authentication flows and code examples are documented for developers at the SDK documentation.

External references
Go deeper