Five Context Checks Before AI Touches Facility Work

By Jared Mastroianni

• August 22, 2026
• 9
• Business Storage, Guides, Self Storage

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

An AI system can find a correct fact and still produce the wrong operating answer.

The fact may belong to another facility. It may come from a page that controls public wording but not gate behavior. It may be accurate today but not effective until next week. It may support a draft without supporting a change. Or it may describe what a provider accepted without proving what the facility now does.

That is why useful AI in self-storage depends less on giving a model “more context” and more on giving it the right operating context.

Before AI drafts a notice, explains an exception, prioritizes a task, compares a metric, or proposes a facility change, an operator should be able to answer five questions:

1. What exact facility, resource, and field are we talking about?
2. Which source owns the fact, and who is allowed to decide or act?
3. Which timestamp governs the question?
4. What is the best evidence-bounded state, including conflicts and unknowns?
5. What may happen next, and what readback would prove the work is complete?

These five checks are small enough to use in daily operations and strong enough to expose many of the problems that become expensive at portfolio scale.

1. Identify the exact operating object

Facility names are useful labels. They are weak control keys.

A portfolio can have renamed locations, similar street names, vendor-specific site codes, legacy webpages, separate access-control identifiers, and legal entities that do not map one-to-one to facility brands. If an AI workflow joins records by a familiar display name, it can return a believable answer for the wrong property.

Start with a stable facility identifier. Then name the exact resource and field involved.

“What are the hours for Cedar?” is ambiguous. Office hours, access hours, call-center hours, auction hours, and holiday hours are different operating fields. A better question is:

Which approved public Saturday office-hours value applies to Facility Cedar’s owned profile for the August 29 publication window?

That question identifies a facility, field, destination, use, and time. It can be tested.

The same discipline applies to maintenance and collections. “The gate is fixed” should identify the facility, asset, work item, represented condition, and evidence source. “Occupancy is 91 percent” should identify the facility set, unit population, calculation rule, as-of time, and exclusions.

The first control is simple: do not let similarity substitute for identity.

2. Separate source authority from permission to act

The source that can supply a fact may not be the source that can authorize a decision. The person allowed to approve a change may not hold the credential that executes it.

For one AI-assisted task, identify four authorities separately:

• Source authority: which record and field govern the fact?
• Policy authority: which rule and version govern the decision?
• Decision authority: who may choose among the permitted outcomes?
• Execution authority: who or what may perform the exact action?

Suppose an official marketing page lists public office hours while an access-control system lists gate schedules. Both sources may be legitimate. Neither should automatically govern the other field.

The same boundary matters with credentials. A user account that can edit a WordPress field is not proof that the proposed content is approved. Technical capability, credential scope, policy permission, and human authorization are separate facts.

NIST SP 800-53 Revision 5.1 addresses controls such as access enforcement, least privilege, separation of duties, and accountability for processes acting on behalf of users. It is a federal control catalog that requires organizational tailoring; it is not a self-storage AI standard. The useful operating lesson is narrower: identity and assigned access should remain inspectable.

RFC 9396 shows how authorization details can be expressed with specific actions, locations, data types, and identifiers. It does not define facility policy. It does reinforce why “has write access” is too broad for consequential work.

3. Name the clock that matters

“Latest” is not a complete time rule.

One facility fact can have several legitimate timestamps:

• when the event occurred;
• when a person or system observed it;
• when a record was stored;
• when the fact becomes effective;
• when it expires;
• when it was approved;
• when an action was attempted;
• and when governing state was read back.

A holiday schedule may be entered today and become effective next month. A sensor event may arrive late. A correction may invalidate an earlier record without erasing the history. A provider may accept a request before the public page changes.

If a workflow keeps one generic timestamp, it cannot explain which of those meanings governed the answer.

The CloudEvents 1.0.2 specification provides stable vocabulary for describing event context. It does not establish facility truth, authority, causation, or completion. The W3C Time Ontology Recommendation provides vocabulary for instants, intervals, durations, and temporal relations. It does not choose the correct operational clock. The operator still has to declare that rule.

Ask one practical question: if two records disagree, is one late, one future-effective, one expired, or are they truly in conflict?

4. Preserve conflicts and unknowns in governing state

AI systems are often rewarded for returning one clean answer. Operations sometimes require an answer that remains visibly incomplete.

For every field needed by the task, preserve a state such as:

• known;
• unknown;
• conflicting;
• stale;
• not applicable;
• or derived.

Those values are not interchangeable. Unknown is not false. Empty is not zero. Unavailable is not not-applicable. A generated summary is not the originating record.

Then make an admission decision for the exact question:

• admit the field;
• admit it with a stated limit;
• hold it because sources conflict;
• hold it because it is stale;
• reject it because the source does not own the field;
• or reject it because the field is outside the task.

PROV-O supplies general vocabulary for entities, activities, agents, attribution, delegation, derivation, and invalidation. It helps describe how a field was assembled. It does not prove that the field is true, current, complete, or authoritative.

The operating control is not “retrieve the most relevant passage.” It is “admit only the fields that are supportable for this question.”

5. Bind the answer to an allowed next step

A recommendation, an approval, an attempted action, and a confirmed operating result are different states.

Before an AI-assisted output moves into work, record:

• the exact question and context version;
• the allowed outcomes;
• the policy or rule used;
• unresolved facts and limits;
• the consequence and reversibility of the proposed action;
• the required human reviewer;
• the narrow action permitted;
• and the system or public surface that must be read back afterward.

If the facility, field, source, policy, value, consequence, or requested action changes materially, create a new context version. Do not let an old approval silently follow new facts.

The NIST AI Risk Management Framework 1.0 emphasizes intended purpose, scope, risk tolerance, knowledge limits, human-AI roles, and lifecycle risk. The framework is voluntary, use-case agnostic, and currently under revision. It does not certify this method. Its practical relevance is that AI risk depends on the context in which a system is used.

The NIST Generative AI Profile, AI 600-1, discusses risks including confabulation, automation bias, data privacy, and information integrity. A five-check context record does not eliminate those risks. It gives an operator a better chance to see which inputs, omissions, and authority boundaries are shaping the output.

A one-page context card

For a daily operator workflow, the record can be short. Use these fields:

Question
One bounded operating question, with facility, field, destination, and time.

Identity
Stable portfolio, facility, resource, field, subject, actor, and destination IDs.

Authority
Governing source and policy; decision owner; execution owner; approval scope and expiry.

Time
Occurred, observed, recorded, effective, approved, executed, and readback times where applicable.

State
Admitted values, conflicts, unknowns, exclusions, source versions, and limitations.

Next step
Allowed disposition, required review, narrow action, idempotency key if a tool is involved, and authoritative readback target.

Boundary
What this context does not establish.

This card should be built for one question, not treated as a permanent summary of the facility.

A 10-minute operator drill

Choose one recurring AI-assisted task: prepare a facility notice, explain an exception, prioritize a maintenance item, compare a metric, or draft a profile correction.

Run the five checks against one fictional example. Then change one fact at a time:

1. substitute a similarly named facility;
2. use a fresh source that does not own the field;
3. make the value future-effective;
4. expire the actor’s approval;
5. introduce two conflicting authoritative records;
6. change the value after approval;
7. return a provider “accepted” response without a governing-state readback.

The workflow should narrow its answer, hold the action, or request an owner. It should not fill the gap with plausible prose.

The final test is straightforward:

Can another qualified operator reproduce why each fact entered the answer, why each excluded fact stayed out, which authority governed the decision, and what readback would close the work?

If not, the system has information around a prompt. It does not yet have operating context.

Read the full architecture paper and download the operating-context tools for the complete five-layer contract, fictional example envelope, JSON Schema, readiness suite, diagram, and source register.

This article presents an authored operating method. It does not describe a deployed product, customer implementation, measured result, autonomous capability, service level, certification, legal conclusion, safety procedure, or industry standard. Examples are fictional. Source pages and versions were checked August 22, 2026.