The Facility Observation Coverage Map: What Your Systems Can Observe, Infer, and Fail to Establish

Chief Operating Officer, modSTORAGE CEO and Co-Founder, Facily.ai

Evidence boundary: This is an authored operating and architecture method. Every facility, device, person, record, value, and outcome in the examples and companion tools is fictional. The method is not evidence of a Facily.ai or Facily OS capability, a modSTORAGE deployment, sensor fitness, facility condition, customer result, performance level, legal conclusion, safety assurance, certification, or industry standard.

Open the full-size accessible diagram.

Governed companion package

Inspect the observation coverage map and admission gates.

These exact files contain an authored method, blank controls, and entirely fictional examples. They do not establish source fitness, claim truth, physical coverage, privacy compliance, product deployment, customer use, performance, safety, security, certification, or independent validation.

Download the source and limitations register ↓Download the observation coverage register ↓Download the readiness suite ↓Download the JSON Schema ↓Download the fictional JSON record ↓Download the assessment runbook ↓Download the accessible coverage SVG ↓Download the coverage PNG ↓

The question before the dashboard

A self-storage operator opens a dashboard and sees green tiles: gate online, climate normal, leak sensors clear, cameras connected, no after-hours exceptions. The temptation is to read the screen as a complete account of the facility.

It is not.

Each tile is a claim assembled from an observation path. That path begins somewhere—a controller register, contact switch, environmental probe, message broker, application database, derived metric, human inspection, or model inference. It samples some property over some physical and temporal footprint. It can miss conditions outside that footprint. It can be stale, delayed, aggregated, transformed, disconnected, misidentified, unauthorized for the proposed use, or silent for reasons that look exactly like “nothing happened.”

The first architecture question is therefore not What does the dashboard say? It is What could this observation system have known, for this exact operating question, at this exact time?

That is the purpose of a facility observation coverage map.

The map ties a bounded operating claim to the sources, observation points, timing, semantics, failure detection, privacy constraints, corroboration, and decision rules required to support it. It does not reward the number of connected devices. It shows where evidence exists, what the evidence means, and where the facility remains intentionally or unintentionally unobservable.

For AI-assisted operations, that distinction is foundational. A model can write a confident explanation from incomplete telemetry. It can correlate signals and propose a diagnosis. It cannot create observation coverage that the facility never had.

Coverage belongs to a claim, not a device

“We have gate telemetry” is too broad to govern an operating decision.

An access system may expose a controller heartbeat, schedule version, relay command, motor current, open-limit switch, close-limit switch, safety loop, manual override, and event log. Those signals answer different questions. A current controller heartbeat does not establish that the gate is closed. A closed-limit switch does not establish that the vehicle lane is clear. A schedule record does not establish that a credential was denied. A successful API read does not establish that its cached value is fresh.

The unit of coverage is one claim:

For one identified facility and bounded physical or operational scope, is one defined property observable with sufficient time, quality, authority, and failure awareness for one named use?

Examples include:

• the outbound gate leaf is physically in the closed position now;
• the north climate corridor remained between two defined temperatures during a named interval;
• a water-presence sensor reported active while its health channel remained current;
• the access controller produced no forced-door event during a complete, gap-free window;
• a customer-facing hours record matches the currently approved governing source;
• an alarm condition is isolated to one point rather than proven across an entire zone.

Those claims need different observation paths and different evidence. A portfolio cannot honestly report one universal “telemetry coverage” percentage unless it defines the denominator as a set of claims, not merely a count of installed devices.

NIST SP 800-82 Rev. 3 describes operational technology as systems and devices that interact with or manage devices interacting with the physical environment, and it includes building automation, physical access control, and environmental monitoring among its examples. It also emphasizes OT's distinctive performance, reliability, and safety context. That is useful grounding for facility systems, but it does not declare any particular self-storage signal complete or safe.

The three records that must stay separate

An observation program often collapses three different things into one row. The coverage map preserves them separately.

1. The observation source

The source is the accountable producer or governing record: a specific device, controller point, service, database field, procedure, or person. It has an identity, owner, lifecycle state, location, configuration version, clock, access policy, and retention rule.

2. The observation event or value

The observation records what the source produced: value, unit, status, source time, observed time, received time, quality, sampling mode, sequence, transformation, and native evidence reference. It is one occurrence or bounded interval, not a timeless truth.

3. The operating claim

The claim is the statement an operator or AI wants to use. It names the property, physical scope, time interval, population, tolerance, consequence, and decision. The same observation can be admissible for one claim and inadequate for another.

A temperature probe reading of 76°F may support “this probe sampled 76°F at 14:03.” It may not support “every unit in Building B remained below 78°F all afternoon.” The second statement changes the spatial footprint, duration, denominator, and missingness assumptions.

W3C PROV-DM supplies a durable vocabulary for entities, activities, agents, generation, use, derivation, attribution, and invalidation. It can link source, observation, transformation, and claim. Provenance helps an operator assess evidence; it does not make the observation true, complete, current, or authoritative.

Five claim modes

The coverage map requires every claim to carry one mode. The modes are descriptive, not a universal confidence ladder.

Directly observed

An identified observation point is configured to measure the stated property within a declared footprint. The record preserves sampling, quality, time, and missingness. “The identified water pad reported active” can be directly observed. “The building is flooding” is a different claim.

Derived

The claim is computed deterministically from identified observations under a versioned rule. A fifteen-minute maximum temperature derived from complete one-minute samples belongs here. The map retains the input set, transformation, aggregation window, and gap rule.

Inferred

The claim is estimated from observations using a statistical, causal, rules-based, or machine-learning method. A pattern of humidity, compressor runtime, and door events may suggest an HVAC issue. It remains an inference with a model or rule version, uncertainty, alternatives, and escalation threshold.

Declared

An identified human or system asserts the state without an eligible direct observation of the property. A manager may declare a lane clear after an inspection. A vendor portal may declare a device online. Declarations can be useful and accountable, but their procedure and limits belong in the record.

Unknown

The system lacks admissible evidence for the claim. Unknown is not a data defect to hide. It is a valid operating state. It may result from no observation point, an expired source, a gap, a quality failure, a conflict, a privacy prohibition, a common-mode dependency, or a use outside the source's approved purpose.

AI may summarize any of these modes. It must not rewrite derived as direct, inferred as observed, declared as measured, or unknown as normal.

A coverage map has eight layers

The companion observation coverage register expresses eight layers for each governed claim.

1. Question and consequence

Name the exact question, decision, and consequence class. “Check climate” is not a question. “Should a manager inspect the north corridor after a sustained high-temperature alert?” is bounded enough to test.

Consequence affects sufficiency. A signal can be useful for prioritizing an inspection while remaining insufficient for changing access, suppressing an alarm, sending a customer message, or making a safety, legal, financial, or security conclusion.

2. Target and property

Resolve the facility, zone, system, device, point, and measured property. Preserve lifecycle and configuration versions. “Door 12” is inadequate if identifiers were reused after a controller replacement.

3. Footprint and denominator

Declare what the source can see: one threshold pad, one door contact, one corridor, one controller, one data partition, one inspection route. Then declare the population the claim covers. A sensor count is not a denominator unless the expected inventory and lifecycle state are governed.

4. Acquisition and transformation

Record whether the path is event-driven, polled, streamed, manually inspected, or batch imported. Preserve sampling interval, change filter, queue depth, aggregation, unit conversion, derived rule, and software version.

RFC 9232 provides an informational framework for telemetry generation, export, collection, correlation, and consumption and explicitly discusses coverage viewpoints and data quality. It is network-focused and not an Internet Standards Track specification. This paper uses its separation of the telemetry path as an analogy, not as a facility standard.

5. Time and continuity

Preserve source time, observation time, receipt time, evaluation time, freshness, allowed lateness, and required duration. Define how the system detects a gap or restart.

The OpenTelemetry Metrics Data Model describes timestamps, delta and cumulative temporality, transformations, gaps, and the difference between defined and absent values. Its page is mutable and carries mixed section stability. More importantly, software metric semantics do not prove the physical meaning or fitness of a facility sensor. They are useful for making aggregation and absence explicit.

6. Quality and failure awareness

Record native quality codes, calibration or inspection status when applicable, queue overflow, sequence gaps, clock uncertainty, stuck-value tests, out-of-range values, and the health of the observation path itself.

The pinned OPC UA v1.05 MonitoredItems section describes sampling intervals, queues, monitoring modes, notifications, revised parameters, status, and overflow behavior. That protocol evidence is bounded. A good service status cannot prove correct sensor placement, calibration, physical coverage, or suitability for an operating decision.

7. Authority, privacy, and allowed use

Name who owns the source, who may view it, which uses are permitted, how long evidence is retained, and which observations are intentionally not collected.

The NIST Privacy Framework 1.0 is a voluntary tool for identifying and managing privacy risk in data processing. It does not authorize surveillance or replace legal review. In a facility context, an intentional privacy boundary is not “missing coverage” to be automatically eliminated. It is a governed design constraint.

8. Decision and degradation rule

State what evidence admits the claim, what corroboration is required, what conflict blocks it, and what happens when coverage degrades. A mature rule does not say “use best available data.” It says, for example: route a manager inspection when the water pad is active and current; do not declare the extent of water; do not trigger a physical shutoff; escalate if the health channel is stale or observations conflict.

Silence requires its own proof

“No event” is often the most dangerous facility claim because several conditions produce the same empty screen:

• the condition did not occur;
• the producer did not sample it;
• the producer was offline;
• the observation point was disabled;
• the value did not cross a change filter;
• the broker retained an old value;
• the session expired;
• the queue overflowed;
• the collector dropped the record;
• the timestamp fell outside the query window;
• a transformation removed the identifying attribute;
• the event was stored in a different partition;
• access policy hid the record;
• the dashboard query failed.

The absence of an observation supports absence of the condition only when the contract defines the expected producer, active inventory, sampling or event behavior, heartbeat or path-health evidence, delivery deadline, queue and overflow behavior, time window, retention, filter, and completeness test.

OASIS MQTT 5.0 defines keep-alive, retained messages, session expiry, and quality-of-service delivery semantics. Those features help describe a message path. They do not prove that a sensor was healthy, that a retained value is current, that an application processed it, or that no physical condition existed.

NIST SP 800-137 describes continuous monitoring as ongoing awareness at a frequency sufficient to support risk-based decisions. “Continuous” therefore should not become a marketing synonym for gap-free. The facility map states the actual frequency and the decision it can support.

The blind-spot register

Every covered claim should carry explicit blind spots. The authored method uses nine types:

1. Spatial — the source cannot see part of the claimed physical area.
2. Temporal — sampling, lateness, retention, or downtime leaves an interval uncovered.
3. Semantic — the field, unit, threshold, lifecycle state, or status code is ambiguous.
4. Identity — facility, zone, device, point, tenant, or record identity is unresolved or reused.
5. Transport — messages can be delayed, duplicated, lost, retained, reordered, or hidden by a failed path.
6. Quality — calibration, inspection, clock, overflow, stuck-value, or source-quality evidence is inadequate.
7. Common mode — the primary and “independent” corroborating paths share power, network, controller, clock, cache, or software.
8. Authority and use — the source is not governing or permitted for the claim, audience, or consequence.
9. Intentional privacy — collection, precision, access, or retention is deliberately limited.

Blind spots are not all defects. Some are necessary. The control is to name them, decide who accepts them, set an expiry, and prevent downstream systems from silently broadening the claim.

NIST SP 800-53 Rev. 5, current Release 5.2.0 provides audit, accountability, monitoring, configuration, integrity, and physical-environment control families that can inform this discipline. The catalog is flexible. Referencing it does not establish control implementation, assessment, or certification.

NIST CSF 2.0 organizes cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. An observation coverage map can support those conversations by exposing inventory, monitoring, exceptions, response, and restoration evidence. It is an internal design aid, not a conformity claim.

A fictional water-presence walkthrough

Harbor Annex is a fictional self-storage facility used only for teaching.

At 02:14, a fictional water-presence pad in the north climate corridor reports active. An AI assistant is asked: “Is Building B flooding, and should the water supply be shut off?”

The observation coverage map prevents that broad question from collapsing into one alert.

The pad directly observes its local contact state, not the depth, source, extent, or cause of water. Its device-health path reports a current heartbeat. A separate corridor humidity probe shows a rise, but humidity is only corroborating context and cannot establish liquid water. The floor plan shows the pad's intended footprint but does not prove installation position. No flow meter covers the branch. The shutoff valve has no governed remote-control authority in this fictional package.

The admissible claims are narrow:

• the identified pad produced an active observation at 02:14;
• its health channel was current at evaluation time;
• a separately sourced humidity observation changed during the same interval;
• the extent, source, and operational consequence remain unknown.

The decision rule allows the AI to assemble an incident packet and route a named manager inspection. It prohibits declaring a flood, notifying customers, suppressing the alert, or initiating a physical shutoff. If the pad heartbeat becomes stale, the state changes from active-and-current to indeterminate; it does not change to clear.

That is operational intelligence: not a bigger claim, but a better-bounded one.

AI can reason over coverage without inventing it

AI is useful when it works inside the map. It can:

• resolve a question into required claims;
• identify missing observation points or lifecycle records;
• distinguish direct, derived, inferred, declared, and unknown statements;
• compare source time, receipt time, freshness, lateness, and continuity;
• flag unit, aggregation, population, and footprint mismatches;
• detect contradictory or common-mode corroboration;
• assemble an operator packet with native evidence links;
• state which broader conclusions remain unsupported;
• route an indeterminate case to the accountable person.

AI should not infer that silence means normal, treat connectivity as sensor health, promote a model estimate into a direct observation, widen one point into a building, or recommend collection that violates a privacy boundary.

NIST AI RMF 1.0 is a voluntary, use-case-agnostic framework organized around Govern, Map, Measure, and Manage, and NIST states that version 1.0 is under revision. NIST AI 600-1 adds a voluntary cross-sector profile for generative-AI risks. They support disciplined context, documentation, measurement, monitoring, and human oversight. They do not validate this method, a model, or a self-storage deployment.

Structural validity is not observation validity

The companion Draft 2020-12 schema makes the record machine-checkable. The JSON Schema Core specification defines the structural vocabulary used for the contract.

A conforming JSON document can still be wrong. Schema validation can establish that required fields and types are present. It cannot establish that the sensor exists, the source is authorized, the clock is accurate, the footprint is complete, the privacy purpose is permitted, the inference is calibrated, or the claim is safe to use.

That boundary belongs in every test result.

Measures that expose coverage honestly

Useful measures focus on claim admissibility and blind spots rather than raw telemetry volume:

• governed claims by facility, consequence, and mode;
• claims with resolved target, property, footprint, and denominator;
• claims with current source identity and lifecycle evidence;
• paths with explicit sampling, lateness, gap, queue, overflow, and retention rules;
• observations with native quality, unit, and timestamps preserved;
• directly observed, derived, inferred, declared, unknown, and indeterminate counts;
• claims blocked by spatial, temporal, semantic, identity, transport, quality, common-mode, authority, or privacy limits;
• time from coverage failure to accountable-owner acknowledgement;
• decisions that correctly degraded when evidence became incomplete;
• intentional blind spots with current owner, rationale, and review date;
• corroborating paths that are genuinely independent for the named failure mode.

Do not publish a portfolio coverage percentage without the claim inventory and denominator. Do not convert these controls into safety, reliability, savings, occupancy, customer, or model-performance claims without a separately designed and executed evaluation.

A practical adoption sequence

Beginner: replace the green tile with a sentence

Choose one dashboard tile. Write the exact sentence it supports, including facility, property, footprint, and time. Then write one sentence it does not support. If the team cannot do that, the tile is not yet governed.

Intermediate: map one observation path

Use the coverage register and assessment runbook. Trace source, sample, transform, transport, storage, query, and display. Record how each layer fails and who owns the failure.

Advanced: test silence and contradiction

Run the readiness suite. Disable the producer, delay a sample, reuse an identity, change a unit, overflow a queue, replay a retained value, break the clock, remove an attribute, conflict two observations, and restrict access. The system should return a typed degraded state instead of normal.

Architect: make coverage a versioned interface

Adopt a contract such as the companion schema and fictional instance. Version claim definitions, observation points, transformations, decision rules, and privacy purposes together. Require release tests when a sensor, controller, field, sampling rate, topology, aggregation, model, policy, or facility lifecycle state changes.

Use the architecture diagram to review where data is generated, where meaning changes, and where a blind spot can be detected—or hidden.

The operator-to-architect exercise

Take one facility question and answer these without referring to a dashboard color:

1. What is the exact claim, target property, physical footprint, interval, and denominator?
2. Is the claim directly observed, derived, inferred, declared, or unknown?
3. Which source produced each input, and is its identity and lifecycle current?
4. What are the sampling, filtering, queue, transformation, and aggregation semantics?
5. How does the system detect silence, a gap, overflow, restart, stale value, or stuck value?
6. Which timestamps exist, which clock produced them, and what lateness is admissible?
7. What native quality, calibration, inspection, or device-health evidence is preserved?
8. What physical area, state, or population remains outside the observation footprint?
9. Do corroborating paths share power, network, controller, clock, cache, or software?
10. Is the source authorized for this use, audience, consequence, and retention period?
11. What intentional privacy boundary must remain unobserved?
12. What precise evidence moves the claim to decision-ready, and what evidence degrades it?
13. Who owns the unknown or indeterminate state, and when is it reviewed?

If the system cannot answer these questions, the solution is not a more confident AI summary. It is an explicit observation gap with a bounded operating response.

The operating principle

Connected, reporting, observed, derived, inferred, corroborated, and decision-ready are different states.

A mature self-storage operating system preserves those distinctions. It makes silence testable. It records the physical and temporal footprint of each source. It treats privacy limits as governed boundaries. It refuses to turn one sensor into a building-wide conclusion. It lets AI organize evidence and uncertainty without allowing AI to manufacture coverage.

The facility observation coverage map answers the question that should precede every automated diagnosis and every confident dashboard: What could we actually know, how could we know it, what could have hidden the truth, and what must remain unknown?