The AI Read 72. What Exactly Was Measured?

By Jared Mastroianni

• October 18, 2026
• 51
• Business Storage, Guides, Self Storage

Facility signals become useful evidence only when the property, place, time, unit, source, and decision boundary stay attached. Jared-owned AI-generated editorial illustration; not documentary evidence.

A semantic observation contract for self-storage systems that must tell a measurement from a setpoint, report, estimate, or instruction before they act on it.

A self-storage system receives the number 72. The easy part is storing it. The hard part is knowing what it means.

Seventy-two could be the temperature recorded by a hallway sensor in degrees Fahrenheit. It could be the cooling setpoint on a controller. It could be relative humidity expressed as a percentage. It could be the average of twelve temperature readings, a technician’s target, a tenant’s estimate, or a model’s forecast for an hour from now. The digits are identical. The operating consequences are not.

This is where artificial intelligence can create trouble without ever producing a dramatic hallucination. A system may retrieve a real value from a real source and still turn it into a false facility statement because the surrounding semantics were lost. “The building is 72 degrees” sounds precise. It may describe nothing that was actually observed.

Operators need a stricter rule: no numeric result becomes facility fact until the system can say what property was measured, where, when, by what procedure, in what unit, over what interval, with what quality, and for which permitted use. That bundle is the semantic observation contract.

A value is not an observation

An observation is more than a row containing a timestamp and a number. It is a relationship among a feature of interest, an observable property, a procedure or sensor, a result, and time. That basic structure appears in the World Wide Web Consortium’s Semantic Sensor Network ontology and the Open Geospatial Consortium’s SensorThings standard. Neither document is a self-storage operating policy. Both are useful reminders that a measurement has meaning only through its context.

For a facility operator, the minimum distinction is the record class. A system should identify whether an incoming record is:

• an observation, produced by a sensor or documented measurement procedure;
• a setpoint, representing a desired controller target;
• a reported condition, supplied by a person without being independently measured;
• a command target, describing what a device has been told to do;
• an estimate or forecast, inferred by a model rather than directly observed;
• a policy limit, expressing an operating threshold; or
• a derived statistic, calculated from a defined set of underlying observations.

These classes must not collapse into one generic “facility data” field. A controller set to 72°F does not prove that a hallway is 72°F. A tenant who says a space “feels like 72” has supplied a report, not a calibrated observation. A forecast of 72°F at 4:00 p.m. is not the state of the property at 3:15 p.m.

An AI system can use every one of these records. It must not misrepresent one as another.

Bind the number to the property and place

The next requirement is an explicit observed property. “Temperature,” “relative humidity,” “door position,” “line voltage,” and “motor current” are different quantities. A percentage without a property name is not enough. Neither is a unit without a property. Seventy-two percent relative humidity cannot be compared with 72°F merely because both values are 72.

The feature of interest must be equally specific. “Building A” may be too broad if the sensor is mounted in a second-floor corridor. “Climate wing” may still be ambiguous if two control zones behave differently. A safe record identifies the relevant facility, building, floor, zone, room, equipment component, or sensor location using governed identifiers.

That precision changes the operator’s response. A high-temperature observation in a mechanical room should not automatically become a tenant-space climate exception. A reading from a vestibule beside an exterior door may require a different interpretation than one from the center of a conditioned corridor. Location is not descriptive decoration. It determines whether the evidence is relevant to the decision.

The contract should also retain the source-system identity, sensor identity, and measurement procedure. A replacement sensor must not quietly inherit the history of the device it replaced. A value manually entered from a handheld meter should be labeled differently from a value streamed by a building controller. If the procedure changes, the comparison boundary changes with it.

Units are part of the value

The International System of Units treats a quantity value as the combination of a number and a reference, commonly a unit. That principle sounds elementary until information moves across vendors and applications.

One source may send degrees Fahrenheit, another degrees Celsius, and a third a unitless integer that depends on a configuration table. A model may receive all three under a column named temperature. If the integration normalizes them without retaining original unit, conversion rule, and conversion version, a later reviewer cannot reconstruct what happened.

The safe pattern is to preserve both the source value and the normalized value. Store the source unit exactly as received. Record the normalized unit, conversion method, and transformation version. Reject or quarantine a value whose unit is missing when the decision requires a known unit. Never infer a unit solely from what “looks reasonable.”

This is particularly important when AI generates narrative. The system should not fill a missing unit to make a sentence read smoothly. “The hallway measured 72” is incomplete evidence. The correct output may be an abstention: “A value of 72 was received, but the property or unit was not established.” That is a useful operating answer.

Time needs three clocks

A single timestamp is often inadequate. Operators should separate at least three times:

1. Phenomenon time: when the condition was observed, or the interval the result represents.
2. Result time: when the sensor or procedure produced the result.
3. Ingestion time: when the operating platform received the record.

Those times may differ by seconds or hours. A disconnected gateway can upload older readings after service returns. A laboratory result may be produced well after a sample was taken. A daily average has an interval, not a single instant. If the AI uses ingestion time as observation time, it can describe stale evidence as current.

Aggregation must be explicit too. An instantaneous reading, five-minute maximum, hourly average, rolling median, and daily count are not interchangeable. Every derived value needs the statistic, window start and end, sampling completeness, and reference to the underlying observations or query that produced it.

Freshness should be a decision-specific rule, not a universal label. A reading that is recent enough for a weekly energy review may be too old for an active temperature exception. The contract should name the permitted use and the maximum evidence age for that use. “Current” is a policy conclusion, not a property of the timestamp alone.

Quality is not a green checkmark

Sensor data is not automatically trustworthy because it arrived through an API. Devices drift, batteries weaken, mappings change, gateways retry, and maintenance teams relocate equipment. A semantic observation contract needs a structured quality record rather than a single good-or-bad flag.

Useful fields include calibration status, validation state, expected range, missing-data status, uncertainty when available, duplicate status, communication health, and known environmental limitations. A system should also preserve the reason for any quality judgment and the rule version that assigned it.

Quality is contextual. A sensor may be healthy but badly placed for the question being asked. A corridor reading can be valid evidence about that corridor while remaining insufficient evidence about every unit on the floor. An out-of-range value may be a true exception rather than a defective sensor. The system should distinguish “measurement failed,” “measurement is unusual,” and “measurement is not eligible for this decision.”

This is where human handback matters. When evidence is incomplete or contradictory, the AI should create a bounded review request: identify the missing semantic field, show the source records, name the blocked conclusion, and route the question to the role authorized to resolve it. It should not ask an operator to approve a vague model judgment.

Put the contract before the model

Semantic safety should be enforced before a value enters a prompt, feature set, or agent plan. Post-generation disclaimers arrive too late. The architecture needs a contract validator at the ingestion and retrieval boundaries.

The validator should perform five tests:

1. Class test: Is this an observation, setpoint, report, command, policy limit, estimate, forecast, or derived statistic?
2. Identity test: Are the facility, feature of interest, observed property, source, and procedure governed and resolvable?
3. Quantity test: Are the value, unit, conversion, and data type valid for the property?
4. Time-and-quality test: Are phenomenon time, result time, freshness, aggregation, and quality sufficient for the proposed use?
5. Authority test: Is this evidence eligible to support the requested conclusion or action?

A passing record receives a decision-use label, not a blanket declaration of truth. It might be eligible for “display in operator dashboard” but not “make tenant-facing climate statement.” It might support “open an investigation” but not “diagnose HVAC failure.” It might inform a weekly trend without authorizing a same-day vendor dispatch.

The model should receive the contract fields alongside the value. Retrieval should filter by record class and decision eligibility. Generated text should name the evidence type: “A corridor sensor reported 72°F at 2:10 p.m.” is stronger than “The facility was 72°F.” If the evidence is a setpoint, the sentence should say setpoint. If it is an estimate, it should say estimate.

A fictional example: four records that all say 72

Consider the explicitly fictional Lakebridge Storage Collective. Its operations platform receives four records:

• At facility LSC-FIC-01, hallway sensor TEMP-22 reports an instantaneous air temperature of 72°F at 2:10 p.m. The result arrives four seconds later and passes the location, unit, and device-status checks.
• The same facility’s controller configuration shows a cooling setpoint of 72°F. This is a target, not an observation.
• At LSC-FIC-02, humidity sensor RH-08 reports 72% relative humidity. This is an observation, but of a different property at a different facility.
• A tenant reports that a unit “feels about 72.” The record has no verified unit or measurement procedure and remains a reported condition.

A fifth record could be a model forecast of 72°F for the next hour. It may be useful for planning, but it is neither a present observation nor a controller setting.

The correct system does not choose one meaning and discard the others. It keeps all five, preserves their classes, and limits each to appropriate uses. If an operator asks, “Is the climate wing currently 72°F?” the first reading may contribute evidence for one hallway. It does not establish the state of the entire wing. The remaining records cannot fill that gap.

The operator tool: an AI Facility Observation Contract

The accompanying contract includes a blank register template and an explicitly fictional teaching example. Its fields cover record class, facility and feature identity, observed property, source and procedure, raw and normalized quantity values, phenomenon and result time, aggregation, quality, freshness, decision eligibility, provenance, and human handback.

Use it first on one high-consequence workflow. Climate exception review is a practical candidate because it combines sensors, controller settings, customer reports, thresholds, and inferred diagnoses. Inventory every input the workflow currently treats as “temperature data.” Classify each record. Reject silent unit assumptions. Separate measurement time from receipt time. Define which records can support an investigation, a customer-facing statement, or a work order recommendation.

Then test the contract with deliberately ambiguous values. Send 72°F, 72% relative humidity, a 72°F setpoint, a verbal “about 72,” and a 72°F forecast through the same retrieval path. The system should keep the records separate, describe each accurately, and abstain from a portfolio-wide conclusion.

The useful operating metrics are not generic model scores. Track the share of records with governed property and feature identifiers; missing-unit quarantine rate; stale-evidence rejection rate; class-confusion incidents; unsupported facility-wide generalizations; handbacks caused by missing semantics; and corrections that propagated to every dependent summary.

The goal is not to make every sensor perfect. It is to prevent the system from becoming more certain as context disappears.

Build the fact before the sentence

AI can make facility information easier to retrieve, compare, and explain. That leverage increases the cost of semantic shortcuts. A polished answer built on an untyped number can move faster than an operator can discover what the number originally meant.

The remedy is architectural. Preserve the record class. Bind the result to a property and feature. Carry the unit, procedure, time, aggregation, quality, and permitted use. Make ambiguity visible. Require handback when the evidence cannot support the requested conclusion.

Before an AI system says a facility “is 72,” it should be able to answer a more important question: 72 what, measured where, by whom or what, at what time, under which procedure, and for which decision?

Until it can, the system has a number. It does not yet have a fact.