The last mile between OT and IT

{
  "metric": "example_count",
  "value": null,
  "unit": "items",
  "observedAt": null,
  "quality": "unavailable",
  "schemaVersion": 1
}

# The last mile between OT and IT

Make industrial data interfaces explicit about meaning, time, quality, ownership, and recovery.

FIELDNOTES sample · 2026-09-07 · Industrial software · 3 min read

Source: https://awake-iris-z6ww.here.now/notes/the-last-mile-between-ot-and-it/

> Sample note: demonstration content, not a published article by the site owner.

## Agree on meaning before transport

Moving a value between operational technology and an information system is only part of an integration. The receiving system also needs to know what the value means, when it was observed, whether it is trustworthy, and who can resolve a disagreement. A successful connection does not answer those questions.

Write a data contract with both producers and consumers. Define names, units, allowed states, missing-value behavior, and the distinction between an observation and a derived result. Ask concrete questions: does a count reset, does a total include rejected items, and does unavailable mean disconnected or simply not measured?

Use a small synthetic example to expose assumptions before discussing transport choices. If two teams interpret the same record differently, changing the protocol will not repair the disagreement. Resolve the meaning and assign an owner for future contract changes.

## Preserve time and quality

Distinguish observation time from ingestion time. A value received now may describe an earlier state, especially after a connection recovers. Document timestamp format, clock assumptions, and ordering behavior. If trustworthy observation time is unavailable, represent that limitation instead of substituting an ingestion timestamp without explanation.

Carry quality explicitly. Missing, stale, invalid, and valid are different conditions, and zero may be a perfectly legitimate measurement. The synthetic record below illustrates an unavailable observation. It is a discussion fixture, not a device configuration or an instruction to connect to equipment.

Define freshness rules per use case. A historical report and a current-status display may tolerate different delays. Consumers should surface the relevant quality and age rather than requiring users to infer them from a number.

```json
{
  "metric": "example_count",
  "value": null,
  "unit": "items",
  "observedAt": null,
  "quality": "unavailable",
  "schemaVersion": 1
}
```

## Design for disconnection

Specify what happens when either side is unavailable. Buffering needs a capacity limit, a retention policy, and a visible outcome when that limit is reached. Backpressure should protect systems rather than allowing an integration to consume resources without a bound.

Assume messages can be delayed, repeated, or delivered out of order unless the complete delivery path provides stronger guarantees. Define event identity and duplicate handling. Acknowledging receipt is not always equivalent to committing a business result, so document where responsibility transfers.

Test backlog recovery in controlled simulation. Verify how current information is distinguished from replayed history and how gaps are reported. For records that affect accounting or traceability, agree on reconciliation rules with the responsible owners. Do not promise exactly-once business outcomes solely because one transport offers a delivery guarantee.

## Keep ownership and safety visible

Start with the minimum approved data access and preserve the boundary between observation and control. Read-only access can still create network load or expose sensitive information. Have network, operational, application, and applicable safety owners review the proposed access pattern and its failure behavior.

Run contract and load tests against isolated fixtures or approved simulators. Live validation, if appropriate, needs an agreed scope, monitoring, stop conditions, and human change approval. Application integration work should not modify protective functions or substitute for qualified assessment of equipment behavior.

Give each interface a named owner, a supported contract version, and a retirement process. Monitor freshness, rejected records, backlog age, and reconciliation status. The useful endpoint is not merely connected systems. It is information that consumers can interpret correctly, with a clear route to recovery when the connection or its assumptions fail.

Tags: OT and IT, Data contracts, Integration