Missing grow-room data belongs in the batch record, not behind the chart

A batch report should say where the record is incomplete. A smooth-looking climate curve is not a substitute for a stated data-coverage boundary. Before reading a trend for a batch stage, establish what the room was expected to record, what actually arrived, which values were valid, and which process entries were never filled in.

Name the four kinds of absence

A sensor that stopped reporting, a value that arrived invalid, a reading that is no longer current and a log entry nobody wrote are four different conditions, and each needs its own label. Automation interfaces already carry this vocabulary: OPC UA classifies every value as Good, Uncertain or Bad with reason-coded substatuses such as Bad_SensorFailure, Bad_NoCommunication and Uncertain_SubstituteValue for a manually overwritten value, and treats staleness as something a reader detects from timestamps (OPC UA Part 8, §7.3). Industrial historians persist quality information with every stored value, including reason-coded absences such as communication loss (AVEVA Historian Concepts Guide).

Do not quietly treat an unknown value as zero, as an ordinary interval or as an unchanged process state. Keep the reason beside the value where it exists.

Put coverage beside the conclusion

Regulated record-keeping treats completeness as part of data integrity: the ALCOA+ attributes expect records to be complete, consistent, enduring and available, so a record that silently omits an expected entry is a data-integrity failure, not a cosmetic gap (MHRA 'GXP' Data Integrity Guidance, March 2018). Recognised data-quality models group the same ideas under characteristics such as completeness, consistency, currentness, credibility and traceability (ISO/IEC 25012 via arc42).

In practice, every batch report states the room and batch, the time window and timezone, the sources included and the material gaps. It separates measured observations from calculated and inferred figures, identifies any interpolation rather than presenting it as a measurement, and keeps those limits next to the conclusion — not in a footnote nobody reads.

Read the example within its evidence

Take an illustrative batch-stage report: climate readings cover most of a stage but not the interval around an equipment interruption, and the feeding entry for that day was never filled in. The supported conclusion covers only the intervals the record actually covers; it should not describe the whole stage as stable merely because the available points look similar. If the missing interval is needed to answer the operating question, say so — a useful report can end with one specific follow-up record instead of a confident summary.

Check recovery claims

A node coming back online does not retroactively fill the unknown interval. Connectivity, stale-data and backlog conditions recover separately, and a process entry written later does not prove it describes what was known at the time. After a reconnection, ask whether buffered history was actually accepted and whether the loss was recorded for the room. These are reporting-design principles, described here as method — not a description of any installed dashboard or a released product feature.

What to specify

• which sensor streams and which process entries each batch stage requires
• how missing, stale, invalid and never-recorded entries are labelled
• what a reader may conclude when coverage is incomplete
• who reviews the report before anyone acts on it

For the neighbouring question of what a dashboard's signals prove while a system is offline, see heartbeat, freshness and backlog.

Where MIND fits

The MIND Agentic Server, configured around an existing MIND installation or a growing system integrated in a scoped project, brings climate and equipment data together with your team's process records, batches and growth cycles, and adds analysis, alarms, reports and agent workflows. If you want a coverage statement on one report your team already uses — conclusion and gaps on the same page — discuss a scoped reporting project with Manna.

Prepared with AI assistance for Manna Insect Oy.