The AI Read the Whole Facility Record. Which Parts Did the Context Window Drop?

By Jared Mastroianni

• October 19, 2026
• 67
• Business Storage, Guides, Self Storage

Responsible AI begins before the model answers: teams must govern which facility records, safety rules and authority boundaries enter the submitted context. Jared-owned AI-generated editorial illustration; not a documentary record of a deployment or result.

Deck: An AI system can retrieve the right facility records and still submit an incomplete operating picture to the model. Responsible architecture must make context selection, compression and truncation visible—and refuse action when a required control disappears.

Consider a fictional facility, Cedar Quay Storage. A service coordinator asks an AI assistant whether to dispatch a gate vendor after several intermittent access failures. The application gathers the current work order, recent gate events, vendor history, customer notes, site contacts and a long maintenance thread. It also retrieves one facility-specific instruction: do not authorize an after-hours dispatch until an onsite employee confirms that the emergency egress path remains available.

The retrieval step succeeds. The instruction is in the candidate record set. But the application has an input budget, and the assembly process keeps the most recent event messages while compressing the maintenance thread. The facility-specific instruction falls out. The model receives a coherent story about repeated gate faults and recommends immediate dispatch.

Nothing in that fictional sequence requires the model to invent a fact. The system can fail earlier, while deciding what the model is allowed to see.

That is the context-control problem. Operators often ask whether an AI system read the work order, policy or facility history. The more precise question is: which records were eligible, which were retrieved, which were admitted, which were submitted, which were compressed, and which were dropped? If the application cannot answer those questions for a consequential recommendation, it cannot prove that the model worked from the required operating context.

A large context window is still a selection system

Every production AI workflow has a finite working budget. The application may reserve space for instructions and the model's response. It may retrieve more material than it can submit. It may summarize older records, remove repeated entries, rank passages, cap the number of documents or cut text at a boundary. Those choices are part of the decision architecture even when they occur in code that nobody calls “AI.”

Longer input capacity does not eliminate the problem. It moves the boundary. Research by Nelson Liu and colleagues found that performance on controlled long-context tasks could change depending on where relevant information appeared, with some models performing worse when the needed material was in the middle of the input.¹ That work is not a prediction about every current model or a self-storage deployment. It is a useful warning: presence inside a long prompt is not proof that the system handled the information reliably.

For a storage operator, the consequence is practical. A model might receive 40 pages of gate history yet miss the one facility instruction that changes who may authorize a response. It might receive a delinquency timeline but lose the active bankruptcy hold. It might receive a vendor proposal while a locally approved spending limit is absent. More text can create the appearance of completeness without establishing control completeness.

Separate the populations the system usually collapses

A responsible context pipeline should preserve at least four populations.

Candidate inputs are records the workflow could consider. They may include property-management data, access-control events, work orders, approved policies, prior human decisions and external content.

Eligible inputs are candidates that pass purpose, permission, organization, facility, time and data-quality rules. A record can exist and still be ineligible for a particular task.

Retrieved inputs are the eligible items returned by search, filters or deterministic queries. Retrieval proves availability to the application, not delivery to the model.

Submitted inputs are the exact instructions and evidence actually sent for that run, after ranking, compaction, deduplication and truncation.

The differences matter. “The AI had access to it” can mean only that a source existed somewhere upstream. “The retriever found it” can mean the application saw the item before dropping it. “It was in the prompt” can still leave open where it appeared, whether it was altered by summarization, and whether a higher-priority rule contradicted it.

Do not collapse those states into a single context_attached=true flag. Record counts, item identifiers, source versions, selection outcomes and reason codes at each boundary. For sensitive material, the audit record can store hashes and typed references rather than duplicating raw customer data. The objective is reproducibility without unnecessary exposure.

Put mandatory controls in a non-droppable envelope

Some information should compete for relevance. Mandatory controls should not.

Before a model receives task evidence, the application should construct a control envelope outside the ordinary retrieval ranking. At minimum, that envelope should establish:

• the organization and facility identity;
• the authenticated actor and workflow purpose;
• whether the model may observe, recommend, draft or trigger a bounded action;
• prohibited actions and required approvals;
• the applicable safety and escalation rules;
• the source cutoff and effective time;
• the policy and context-builder versions; and
• the required human handback conditions.

The exact set depends on the workflow. A maintenance-triage assistant needs different controls from a collections drafting tool. The architectural rule is consistent: if a field determines identity, authority, safety or the validity of the operating picture, it should not be ranked against narrative history for the last available tokens.

Then run a deterministic preflight. The preflight should confirm that every mandatory control is present, current, internally consistent and within the intended facility scope. If one is missing, the system should stop or hand the task to a person with a specific reason. It should not ask the model to infer the missing boundary from surrounding text.

This aligns with the NIST AI Risk Management Framework's emphasis on intended purpose, context, knowledge limits and defined human roles, and with its generative-AI profile's attention to information integrity, human-AI configuration and confabulation.²³ Those voluntary frameworks do not prescribe a self-storage context builder or certify an implementation. They support the governance principle; the operator still has to design the control.

Make compression and truncation policies explicit

Silent truncation is an operating decision disguised as plumbing.

An application needs a versioned policy for what happens when candidate material exceeds its budget. “Oldest first,” “lowest similarity first” and “summarize everything” are not neutral defaults. Each can remove information that remains operationally controlling.

A useful policy defines content classes and precedence. Mandatory controls are retained in full. Current authoritative facility facts outrank superseded records. Unresolved exceptions outrank closed routine events. Raw event details may be compacted into a deterministic summary if the source range and transformation are recorded. External text is clearly separated from operator-approved instructions. Duplicate entries can be removed, but the surviving item retains lineage to the originals.

Every dropped item should receive a reason code such as OUTSIDE_TIME_BOUNDARY, SUPERSEDED, DUPLICATE, LOWER_RELEVANCE, BUDGET_LIMIT or PERMISSION_DENIED. A BUDGET_LIMIT drop is not automatically a defect. A dropped mandatory item is.

The run record should bind the selection-policy version, ordering-policy version and context-builder version to the model release. Otherwise, a later reviewer can know which model answered without knowing which evidence that model was given.

Enforce authority outside the prompt

A complete control envelope improves the model's operating picture. It does not turn prose into a permission system.

The model can recommend a vendor dispatch, draft a customer response or classify an event. The application should still validate the output schema, check the requested action against an external authorization policy, limit tool privileges and require a person for high-consequence actions. OWASP's prompt-injection guidance similarly recommends constraining behavior, validating output, applying least privilege and requiring human approval for high-risk actions.⁴ It is community security guidance, not a universal guarantee, but the architectural point is sound: untrusted text and model output should not be able to rewrite the system's authority boundary.

That separation matters because facility records can contain uncontrolled text. A customer note, imported vendor email or legacy work-order comment may be relevant evidence, but it is not a governing instruction. The context manifest should label source type and trust class. The action gate should use authenticated rules, not whatever instruction happens to be closest to the model's answer.

Test context placement, not just answer quality

Most acceptance tests give the model one curated prompt and score the final answer. That can miss a fragile assembly process.

For a consequential workflow, build a small set of task-specific cases and run position variants. Place the controlling facility fact near the beginning, middle and end of an otherwise equivalent submitted context. Add realistic low-value history. Exercise the actual compaction threshold. Confirm that the mandatory envelope remains present and that the action gate produces the same permitted outcome.

Then test negative cases:

• Remove one mandatory control and expect a hard stop.
• Supply two conflicting facility identities and expect handback.
• Let a policy version expire and expect rejection.
• Add an external note that asks the system to ignore an approval rule and confirm that it remains evidence, not instruction.
• Force a budget reduction and confirm that dropped mandatory count remains zero.
• Correct a source record and confirm the next run uses the new version rather than a cached summary.

These tests do not prove universal reliability. They establish whether the actual context builder and action boundary behave as designed for a defined operating use.

Give operators a context manifest, not a token lecture

Facility teams do not need a dashboard full of tokenizer internals. They need a concise, reviewable manifest.

For each consequential run, record the workflow and facility, context-builder version, candidate and admitted counts, whether compaction or truncation occurred, mandatory-control presence, dropped-item classes and reasons, source cutoff, model release, action-gate result and handback state. Give the run a context-build ID and hashes for the submitted manifest and payload.

That manifest allows an operator to answer useful questions:

• Did the run use the right facility?
• Was the current safety rule present?
• Did the system drop anything because of budget?
• Was external content separated from approved instructions?
• Which policy and model versions governed the result?
• Did the system recommend, or did it actually trigger something?
• Who reviewed the handback?

The companion AI Context Assembly, Truncation, and Control-Presence Test turns those questions into a release record. Its blank template supports preproduction and change testing. Its worked Cedar Quay example is explicitly fictional and does not represent a modSTORAGE or Facily.ai system, customer, deployment or result.

Release only when control completeness is measurable

A practical release rule can be strict without being complicated.

Do not release a consequential workflow if any mandatory control can be dropped, if the submitted context cannot be tied to a manifest, if truncation happens without a reason-coded record, if external content can change authority, or if a missing control still produces a normal answer. After release, monitor the same conditions. A model upgrade, retrieval change, new summary method or smaller application budget can change the effective operating picture even when the user interface does not move.

The final discipline is semantic. A model response is not an observed facility fact. A retrieval result is not proof that the model received it. A submitted item is not proof that the model used it. And a fluent recommendation is not evidence that every controlling rule survived assembly.

If an AI system is going to participate in facility operations, the operator should be able to inspect not only what the system said, but what the system was actually allowed to know—and what it left behind.