Governed operational data
Data Fabric and API Guide
A technical guide to the stable identities, source time, quality, authority, lineage, APIs, streams and datasets that make facility, network, security, compute and operating-workflow data reusable without flattening every source into one database.
- Access
- Open access
- Resource type
- Developer and data-governance guide
- Primary audience
- Developers, data and platform engineers, operators, customers, analytics teams and assurance reviewers
- Product scope
- DCOS Data Fabric, PrecisionDCMS, DCOS Cloud and external integrations
Federated, not flattened
Convert operational data into reusable information while preserving the authoritative source.
PrecisionDCOS Data Fabric converts data from facility, network, connectivity, security, compute, storage, cluster, customer and operating-workflow systems into governed, contextualized and reusable operational information.
It provides canonical identifiers, quality semantics, schema and profile versions, historian services, an event ledger, dependency context, APIs, webhooks, streams, exports and dataset delivery for operators, customers, assurance programs and external analytics or AI/ML systems.
The Data Fabric does not require every source to be copied into one database. High-cardinality telemetry, video, logs, DCIM, CMMS, VMS/PACS, carrier systems and customer platforms may remain in qualified domain stores. The common contract identifies the authoritative source, preserves time and quality, relates records through stable identity and exposes policy-controlled views.
One operating contract does not mean one physical database.
Every value carries context
A number without identity, time, quality and authority is not operational truth.
Scroll horizontally to see the full table.
| Field group | Required meaning |
|---|---|
| Identity | Organization, tenant, site, space, system, equipment, interface, point, service and source identifiers |
| Value | Value, data type, engineering unit, enumeration and scale |
| Time | Source time, receive time, processing time and source age |
| Quality | Current quality, reason, staleness, simulation and out-of-service state |
| Authority | Authoritative source, read scope, commandability and control class |
| Lineage | Source system, interface, collector, OEM profile, transformation and schema version |
| Context | Alarm class, maintenance state, dependency, customer/service impact and active incident or work |
| Governance | Tenant, classification, retention, residency, access and evidence policy |
{
"point_id": "cooling-loop-a.supply_temperature",
"equipment_id": "cooling-loop-a",
"value": 27.4,
"unit": "degC",
"quality": "GOOD",
"quality_reason": null,
"source_time": "2026-08-08T14:30:00Z",
"received_at": "2026-08-08T14:30:01Z",
"source_age_seconds": 1,
"commandable": false,
"control_class": "NONE",
"schema_version": "precisiondcos.point.v1"
}The example is illustrative. It does not imply that every source supports the same fields or update rate. Source-specific omissions, uncertainty and transformations must be represented rather than silently invented.
Quality is explicit
Do not render stale or simulated data as ordinary current truth.
Quality is preserved through APIs, dashboards, alarms, calculations, exports and datasets. Consumers must not drop quality in a way that causes an uncertain, stale, out-of-service or simulated value to appear equivalent to a current validated source.
- GOOD
- Current and validated within the accepted source contract
- UNCERTAIN
- Usable with a known limitation such as fallback source, partial validation or time uncertainty
- BAD
- Invalid or unavailable as current truth
- STALE
- No accepted update before the configured timeout
- OUT_OF_SERVICE
- Administratively removed under authorized maintenance
- SIMULATED
- Controlled test or simulation source
- 01Source state
- 02Collector and interface health
- 03Normalized quality
- 04Alarm / calculation eligibility
- 05API / dashboard / dataset presentation
- 06Consumer decision
A failed interface, old cached value or replay backlog must not create a false normal condition or false incident closure.
Versioned operational interfaces
Organize interfaces around stable resources and governed relationships.
Interfaces are versioned and tenant-scoped. Authentication, authorization, pagination, filtering, rate limits, idempotency, webhook signing, retry behavior, schema change, deprecation, retention and audit are documented for the selected service.
Direct database access is not the standard integration model. Consumers use supported APIs, webhooks, streams, exports or approved domain-system interfaces so that authority, quality, tenant scope and lifecycle can be enforced.
/api/v1/organizations
/api/v1/sites
/api/v1/assets
/api/v1/equipment
/api/v1/points
/api/v1/events
/api/v1/alarms
/api/v1/incidents
/api/v1/work
/api/v1/maintenance
/api/v1/changes
/api/v1/capacity
/api/v1/dependencies
/api/v1/impact
/api/v1/network/paths
/api/v1/security/events
/api/v1/compliance/evidence
/api/v1/datasetsGET /api/v1/points/{id}
Select the right delivery mode
Operational applications, analytics and bulk data have different interface needs.
Scroll horizontally to see the full table.
| Surface | Best suited for | Required governance |
|---|---|---|
| REST API | On-demand resource and workflow access | Identity, scope, rate, version, pagination and audit |
| Webhooks | Event-driven notification | Signed delivery, retry, idempotency, ordering and dead-letter handling |
| MQTT or Sparkplug | Site and telemetry messaging where selected | Topic, namespace, quality, birth/death, identity and broker authority |
| OPC UA | Qualified industrial data exchange | Namespace, security, quality, subscription and command boundary |
| Kafka-compatible stream | High-throughput event and telemetry integration | Schema registry, partitioning, ordering, retention and consumer responsibility |
| NDJSON, JSON or CSV | Interoperable export and bounded bulk transfer | Schema, time, quality, classification and delivery manifest |
| Parquet and object delivery | Analytics and large datasets | Partitioning, schema, lineage, residency, encryption and lifecycle |
| Customer portal and dashboards | Human operational use | Role, tenant, quality presentation, evidence and accessibility |
| Domain-system link or reference | Video, DCIM, CMMS, VMS/PACS and other retained sources | Authoritative system, deep-link security, retention and availability |
Every production integration should identify its provider, source and destination systems, data or control direction, authoritative source, permissions, maturity, support owner, version, limits, retry behavior, test status and handback method.
Data becomes operational when it is related
Preserve the path from source condition to verified closure.
The event ledger preserves source identity, time, quality and native reference. Dependency context relates the condition to affected systems, services, customers and operating objectives. Work and change records preserve the human and technical response. Evidence links the tests, approvals, screenshots, reports, configurations and source records that support closure.
Correlation may combine multiple source events, but it must not erase the native event or pretend a downstream workflow is the authoritative equipment state.
- 01Source condition
- 02Normalized event
- 03Alarm
- 04Incident
- 05Communication / approval
- 06Work / change / maintenance
- 07Restoration
- 08Verified closure
- 09Evidence
Governed enablement
Provide high-quality operational context without giving analytics hidden authority.
The Data Fabric can supply curated operational data, dependency context, event history, maintenance, capacity, network, security and evidence datasets to approved analytics, digital-twin and AI/ML environments.
- Approved purpose and user population
- Dataset definition, source and lineage
- Quality, time and missing-data treatment
- Classification, privacy, residency and retention
- Evaluation, drift, change and human-review process
AI and analytics are advisory by default. A model output may inform triage, recommendation, forecasting or planning. It does not become equipment authority, close an incident, approve a change or make a compliance claim without an explicitly approved workflow and accountable human or system owner.
Do not place a generic “AI copilot” input on this resource page and imply autonomous control. The page should explain governed data enablement, not present an unvalidated operational chatbot.
Portable records
Plan customer access and exit before the first production value arrives.
The order defines data ownership, service rights, source-system restrictions, customer access, retention, residency, export frequency, format, cost, deletion, legal hold and handback.
Practical handback provides the agreed asset, operational, event, work, configuration-reference and evidence records in documented formats, subject to source licenses, security, privacy and third-party rights. Secrets, private keys and provider credentials are handled through a separate controlled process.
- Canonical asset and identifier export
- Point and schema catalog
- Time-series and event export
- Incident, work, maintenance and change records
- Dependency and service relationships
- Evidence index and retained artifacts
- Integration and endpoint register
- Data dictionary and version information
- Known quality and retention limitations
- Customer and third-party restrictions
- Secret and credential transition plan
- Validation and deletion or retention record
The Data Fabric and API Guide includes
- Data Fabric definition and federated-source model
- Canonical identity and data contract
- Time, quality, staleness and simulation semantics
- Source authority and lineage
- API resource families
- Authentication, authorization and tenant scope
- Webhook, stream and export patterns
- Dataset and bulk-delivery interfaces
- Event, incident, work and evidence relationships
- Dependency and impact model
- Command and administrative boundaries
- AI/ML and analytics governance
- Data rights, retention, residency and portability
- Integration register and support ownership
- Versioning, deprecation and handback considerations
Frequently asked
Questions and answers
- Does PrecisionDCOS require all data to be centralized?
- No. Qualified domain stores can remain authoritative for high-cardinality telemetry, video, logs, DCIM, CMMS, VMS/PACS, carrier and customer data. The Data Fabric establishes identity, quality, lineage, relationships and policy-controlled interfaces across them.
- Are the API examples a contractual interface?
- They illustrate the resource model and naming convention. The current API specification, authentication method, service profile and executed order govern production availability, fields, rate limits, retention and support.
- Can customers export their data?
- The service is designed to support policy-controlled access and practical handback. Exact datasets, formats, frequency, retention, source restrictions and delivery method are defined by the order and applicable third-party rights.
- Are command APIs available?
- They are disabled by default and are not implied by the read API. Any equipment-changing command is separately engineered, authorized, interlocked, time-bounded, feedback-confirmed, audited and accepted.
- Can AI models consume PrecisionDCOS data?
- Yes, through approved datasets, streams or APIs with defined purpose, lineage, quality, security, privacy, evaluation and human oversight. Model access does not grant operational authority.
Related resources
Authority and Safety Boundary Brief
Distinguish data visibility, workflow permission and equipment command authority.
Read resourcePrecisionDCMSPrecisionDCMS Technical Manual
Review controlled source, protocol, quality and collection requirements.
Read resourceAssurance and ComplianceAssurance Services Overview
Connect operational data and evidence to implemented controls and independent assessment.
Read resourceDefine the data contract
Build the interface around authoritative sources and accountable consumers.
Share the source systems, desired consumers, scale, retention, residency and intended analytics or workflow. PrecisionX will identify the supported API, stream, export or dataset pattern.