The Five-Layer Operating Context Stack for Multi-Facility AI

An AI system can retrieve the correct sentence and still be wrong for the work.

The sentence can describe another facility. It can come from a source that is authoritative for marketing but not access control. It can be current as of the observation time and already obsolete at the effective time. It can be accurate yet outside the actor's authority. It can support a recommendation without supporting the proposed action.

That is the context problem in multi-facility operations.

Context is often treated as extra prose placed around a prompt. For consequential work, context should be a typed operating object assembled for one question, at one time, under one authority boundary. It should expose what is known, what is conflicting, what is missing, and what the resulting decision is allowed to do.

This paper proposes a five-layer operating context stack for self-storage portfolios:

1. identity;
2. authority and policy;
3. event and time;
4. governing state;
5. decision and action.

The stack is not a larger prompt. It is a contract between source systems, policy owners, operators, models, tools, and the governing-state readback.

The companion package includes a fictional operating-context envelope, a readiness suite, a structural JSON Schema, a fictional example envelope, and an accessible stack diagram. The complete source and limitation record is in the source register.

This is an authored reference pattern. It does not describe a deployed product, customer implementation, model capability, measured result, service level, certification, legal conclusion, safety procedure, or industry standard.

Open the full-size accessible diagram.

Governed companion package

Use the method. Test the failure paths.

These files contain fictional examples and structural tools. They do not establish a live facility fact, product capability, customer result, operating performance, certification, or independent validation.

Download the fictional operating-context envelope ↓Download the operating-context readiness suite ↓Download the Draft 2020-12 JSON Schema ↓Download the fictional example envelope ↓Download the accessible operating-context SVG ↓Download the operating-context PNG ↓Download the source and limitations register ↓

Begin with one operating question

The smallest useful context object is built for one named question.

“What do we know about Facility Cedar?” is too broad. It invites the system to mix public facts, operating schedules, customer records, work orders, incidents, forecasts, and model inferences without declaring which of them can govern the answer.

A bounded question looks more like this:

Which approved public Saturday office-hours value should be proposed for Facility Cedar's owned profile during the August 29 publishing window?

The question declares a facility, field, destination, proposed use, and time. It gives the context builder something testable. The builder can now determine which identities must resolve, which source owns that field, which policy applies, which event changed the value, which state is current, and whether the result supports a proposal or an action.

The context object should receive its own stable ID and version. If the facility, field, purpose, source version, policy version, value, consequence, or action scope changes materially, create a new version. Do not quietly update the context behind an already approved decision.

Layer 1: identity context

Identity answers what exact thing is this about?

At minimum, represent the portfolio, legal or operating entity when relevant, facility, resource, field, subject, current actor, and destination. Human-readable names remain display labels. They are not the join key.

A multi-location operator can have similar street names, renamed locations, legacy web pages, vendor site codes, access-control panels with local identifiers, and finance entities that do not align one-to-one with facility brands. The context builder should resolve those identities before retrieving facts.

The identity layer should include:

• stable facility and entity IDs;
• external-system aliases and their source;
• resource and field identifiers;
• the subject on whose behalf the work exists;
• the current human or service actor;
• the requested destination and environment;
• identity resolution state: resolved, conflict, unknown, or retired;
• and the evidence supporting the resolution.

Do not collapse subject, actor, and authorizer into “user.” A person may request a correction, a service may assemble it, another owner may approve it, and a different credential may execute it.

NIST SP 800-53 Revision 5.1 includes access enforcement, least privilege, separation of duties, audit accountability, and controls for processes acting on behalf of users. It requires organizational selection and tailoring and is not an AI context standard. Its relevant constraint is simple: the identity of a process and the access assigned to it should remain inspectable.

Identity resolution is necessary, not sufficient. A stable facility ID does not tell the system which source owns its access hours or whether the actor can change them.

Layer 2: authority and policy context

Authority answers who or what is allowed to supply, decide, approve, and execute this part of the work?

There are at least four kinds of authority:

1. source authority — which record and field govern the fact;
2. policy authority — which rule and version govern the decision;
3. decision authority — who may select among allowed dispositions;
4. execution authority — who or what may perform the exact action.

These authorities may belong to different owners. A facility information owner may govern public office hours. An access-control owner may govern physical entry schedules. A communications policy may govern message content. A credential scope may govern which profile field one service can update.

The authority layer should record:

• source owner and field-level authority;
• policy ID, version, effective interval, and owner;
• subject, actor, authorizer, and delegation reference;
• approved resource, field, action, population, environment, and time scope;
• approval requirement and expiration;
• segregation-of-duties requirement;
• and an explicit authority result: allowed, denied, unknown, expired, or conflict.

RFC 9396 defines a way to express fine-grained OAuth authorization details such as action, location, datatype, and identifier. It is a protocol mechanism, not a facility policy. The architectural lesson is that “write access” is too broad a context value for consequential work. The system should be able to reproduce the exact resource, field, operation, and boundary that were authorized.

Policy context should not be inferred from what a tool technically permits. Tool capability, credential scope, operating policy, and human approval are separate facts.

Layer 3: event and time context

Event and time answer what changed, when did it happen, and which clock matters to this question?

A facility context can contain multiple valid times:

• occurred_at — when the represented event happened;
• observed_at — when a source or sensor noticed it;
• recorded_at — when a system stored it;
• effective_from and effective_to — when the fact governs operations;
• evaluated_at — when policy or a model evaluated it;
• approved_at and expires_at — when authority began and ended;
• executed_at — when the tool attempted the action;
• readback_at — when governing state was checked.

Do not replace those clocks with one generic timestamp.

The latest recorded fact is not automatically the current effective fact. A future schedule can be recorded before it is effective. A sensor observation can arrive late. A correction can invalidate a prior record without rewriting history. Two sources can be fresh and still disagree because they govern different fields.

The pinned CloudEvents 1.0.2 specification defines interoperable event context attributes such as id, source, specversion, type, subject, time, datacontenttype, and dataschema. It does not define facility truth, business authority, causation, completion, or reconciliation. Use it as event-envelope vocabulary, not as evidence that an event is correct.

The pinned W3C Time Ontology Recommendation provides vocabulary for instants, intervals, durations, temporal positions, reference systems, and temporal relations. It does not decide which timestamp should govern a facility action. The operator must still declare the clock meaning and admissible lateness or freshness rule.

The event-and-time layer should expose missing clocks and conflicts. It should never manufacture a chronological story because the records are easier to read in that order.

Layer 4: governing-state context

Governing state answers what is the best evidence-bounded operational state for this exact question?

This layer is not a raw source dump. It is a field-level projection with provenance.

For each admitted state field, record:

• value and datatype;
• source record and field;
• source version or validator;
• observed and effective time;
• state quality: known, unknown, conflict, stale, not_applicable, or derived;
• derivation reference when applicable;
• conflict set and resolution owner;
• and the question for which the state is admitted.

Unknown, false, zero, empty, unavailable, and not applicable are not interchangeable. A system that turns them into the same blank value destroys operating meaning.

PROV-O provides general concepts for entities, activities, agents, attribution, association, delegation, generation, use, derivation, and invalidation. Those concepts help describe how a state field was assembled. They do not prove that the source is true, authoritative, complete, fresh, or appropriate for the decision.

The governing-state layer needs an admission decision for every field:

• admitted — sufficient for this exact question;
• admitted_with_limit — usable only within a stated boundary;
• held_conflict — competing values require an owner;
• held_stale — freshness or effective-time rule failed;
• rejected_authority — source does not own the field;
• rejected_scope — field is outside the question;
• unknown_required — the question cannot proceed without it.

Retrieval rank should not determine admission. A highly relevant document can still be non-authoritative. A low-ranking source record can still be governing.

Layer 5: decision and action context

Decision and action answer what may be concluded or done with the admitted state?

This layer binds the context object to a decision question, candidate dispositions, consequence class, reversibility, approval rule, tool action, and reconciliation target.

Record:

• decision ID and context version;
• exact question and allowed outcomes;
• policy input and result;
• model, rule, or human contribution with version;
• limitations and unresolved facts;
• consequence and reversibility classes;
• required reviewer qualification;
• proposed action envelope;
• idempotency key and attempt limit;
• approval state and expiry;
• authoritative readback target;
• and closure or handback state.

The NIST AI RMF 1.0 supports mapping context, intended purpose, scope, risk tolerance, knowledge limits, human-AI roles, and lifecycle risk. It is voluntary, use-case agnostic, and currently under revision. It does not certify this stack. Its value here is the insistence that risk management depends on the actual context in which an AI system is used.

The NIST Generative AI Profile, AI 600-1, describes risks including confabulation, automation bias, data privacy, and information integrity. A structured context stack does not eliminate those risks. It makes some of the inputs, omissions, and authority boundaries inspectable before a generated answer becomes operating work.

The decision layer must never rewrite a model output as governing state. A recommendation remains a recommendation. If a human approves an action, the approval record should refer to the exact context version and action envelope. If the context changes materially, the prior approval should not silently follow it.

Assemble context as a contract

The context builder should produce three outputs:

1. the admitted context — facts allowed for the exact question;
2. the rejection report — facts excluded with reason codes;
3. the context manifest — identities, sources, versions, clocks, policies, decisions, hashes, and limitations used to build both.

The manifest needs a stable context ID and version. A deterministic digest can help detect byte changes, but a matching digest proves only that the bytes match. It does not prove their truth or authority.

The companion JSON Schema demonstrates structural constraints for an example envelope. JSON Schema Core Draft 2020-12 defines the dialect, identifiers, references, vocabularies, and evaluation model; JSON Schema Validation Draft 2020-12 defines validation keywords. Passing the schema proves only structural conformance. It does not prove facility identity, source authority, time coherence, policy correctness, or operational safety.

For consequential use, context admission should fail closed when a required layer is incomplete. “Fail closed” does not always mean stop the entire workflow. The system can return a narrower answer:

• display known facts with conflicts visible;
• prepare a draft without permission to send;
• calculate a provisional result without calling it reconciled;
• request a qualified owner;
• or state that the decision is not supportable from current evidence.

Nine context failures worth testing

1. Right value, wrong facility

The value is correct for another stable facility ID. Similarity is not identity resolution.

2. Right source, wrong field authority

An official marketing page can govern public copy without governing physical access behavior.

3. Mixed-time snapshot

Each field is individually plausible, but the combined state never existed at one admissible effective time.

4. Current state, expired authority

The facts are fresh, but the actor's approval or delegated scope expired.

5. Fresh event, stale policy

The event arrived now, but the decision used a superseded policy version.

6. Retrieval outranks authority

The model selects a highly relevant document over the field's governing source.

7. Inference becomes source

A generated summary is stored, retrieved later, and presented as if it were the originating record.

8. Context version changes after approval

The value, consequence, source, or facility changes while the old approval remains attached.

9. Provider response becomes governing state

A tool says accepted or queued, and the context marks the operating outcome complete without authoritative readback.

The companion readiness suite turns these patterns into beginner-to-architect test cases.

A fictional portfolio example

Consider a fictional request: prepare an approved public notice about Saturday office hours for FAC-CEDAR.

The identity layer resolves the stable facility and public-profile field. It also finds an old page with a similar display name and rejects that alias as retired.

The authority layer identifies a facility information record as governing public office hours. It does not treat the access-control schedule as authority for public copy. It confirms that the communications actor may draft but not publish.

The event-and-time layer shows that the new schedule was recorded today, becomes effective next Saturday, and was approved for a specific publication window. The prior value remains correct until that effective interval begins.

The governing-state layer admits the new schedule as a future-effective public-information fact, holds a conflict with a stale public page, and excludes a different gate schedule because it is outside the question.

The decision layer permits a draft that states the future effective date. It does not permit publication because execution authority is absent. It sets the owned profile as the later readback target.

The AI can now produce useful work without pretending the entire facility has one universal “hours” value.

The example is fictional. It is not a facility-hours claim, access-control instruction, customer communication, deployed workflow, or product capability.

Context minimization is an operating control

More context is not automatically better.

Unbounded context can expose personal, financial, credential, security, legal, or customer information that the decision does not require. It can also increase the chance that a model will anchor on a plausible but non-governing detail.

Minimize context by purpose:

• include only the facilities, resources, fields, periods, and populations required;
• prefer references and bounded claims over full document copies;
• exclude reusable secrets and unrestricted personal data;
• record why each field was admitted;
• set retention and invalidation rules;
• and separate source evidence from generated narrative.

The authority layer should govern who can assemble and inspect the context itself. A context package can become more sensitive than any one source because it joins multiple systems.

The operator-to-architect exercise

Choose one proposed AI-assisted task: draft a facility notice, explain an exception, prioritize a work item, compare a metric, prepare a profile change, or assemble a vendor handoff.

Use the operating-context envelope and complete these steps:

1. write one exact operating question;
2. name the stable portfolio, facility, resource, field, subject, actor, and destination identities;
3. assign source, policy, decision, and execution authority separately;
4. record occurred, observed, recorded, effective, evaluated, approved, executed, and readback clocks where applicable;
5. admit or reject every state field with a reason code;
6. distinguish known, unknown, conflict, stale, not applicable, and derived;
7. bind the decision and any approval to one context version;
8. define the exact action envelope and authoritative readback target;
9. replay the case with the wrong facility, stale source, expired authority, future-effective value, changed policy, provider timeout, and mismatched readback;
10. verify that the system can return a narrower truthful answer instead of filling the gap.

The architecture gate is:

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

If not, the system has a prompt, not an operating context.

Sources

• Artificial Intelligence Risk Management Framework 1.0, NIST, January 26, 2023; current page checked August 22, 2026 and notes that the framework is under revision.
• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, NIST, July 26, 2024; page updated April 8, 2026.
• Security and Privacy Controls for Information Systems and Organizations, NIST SP 800-53 Revision 5.1, official derived OSCAL publication checked August 22, 2026.
• OAuth 2.0 Rich Authorization Requests, RFC 9396, IETF, May 2023.
• CloudEvents Specification, stable release 1.0.2, CloudEvents/CNCF, February 2022.
• PROV-O: The PROV Ontology, W3C Recommendation, April 30, 2013.
• Time Ontology in OWL, W3C Recommendation, October 19, 2017.
• JSON Schema Core, Draft 2020-12, June 16, 2022.
• JSON Schema Validation, Draft 2020-12, June 16, 2022.