Policy as Code for Facility Operations Without Hiding Human Authority

Method and evidence boundary: This is an authored reference model for testing policy-driven facility workflows. It is not legal, safety, security, accounting, employment, insurance, accessibility, payment, or compliance advice. Every facility, person, vendor, system, policy, identifier, time, threshold, decision, and result in the examples is fictional. Qualified owners must define the actual authority, source, consequence, review, enforcement, evidence, retention, and rollback rules for each use case.

Policy as code is often introduced as a way to make rules executable. That description is incomplete.

The difficult part is not translating a sentence into syntax. The difficult part is preserving who had authority to create the rule, which facts the rule was allowed to use, what decision vocabulary it could return, where the decision was enforced, what happened when a dependency failed, and who remained accountable for the consequence.

A self-storage portfolio can automate a policy decision and still lose the policy's meaning. A rule may be technically valid but use stale facility hours. A decision service may return allow while the gate controller never applies it. An AI assistant may explain a result in polished language while citing a policy version that is no longer active. A human may appear to approve an exception without holding authority for that facility, transaction, or period.

Policy as code should make those boundaries more visible, not less.

Open the full-size accessible diagram.

Governed companion package

Inspect the policy contract and readiness gates.

These exact files contain an authored reference method and fictional examples. They do not establish a product architecture, deployment, customer result, service level, legal or security conclusion, compliance, certification, performance, external review, or recognition.

Download the source and limitations register ↓Download the policy contract register ↓Download the policy readiness suite ↓Download the accessible reference-model SVG ↓Download the reference-model PNG ↓

Policy is not the same as authority

A policy is an approved expression of what should happen under defined conditions. Code is one possible representation of that policy. Neither the file nor the engine grants organizational authority by itself.

Authority has to arrive through a governed chain:

1. a qualified owner approves a policy purpose and consequence;
2. an authorized policy steward translates that approval into a versioned rule;
3. independent tests verify the rule against ordinary and adversarial cases;
4. an approved release process activates an exact version for an exact scope;
5. a decision point evaluates the rule against admissible facts;
6. an enforcement point applies only the permitted consequence;
7. an evidence record preserves the decision and enforcement dispositions;
8. a human or deterministic recovery path owns exceptions, reversals, and rollback.

If one of those links is missing, “the policy engine decided” is an evasion. The engine evaluated inputs under loaded instructions. People and governed systems remain responsible for whether those instructions were authorized, appropriate, deployed, enforced, and reviewed.

The NIST AI Risk Management Framework 1.0 is voluntary, non-sector-specific, and use-case agnostic. Within that boundary, it provides a useful governance principle: AI risk work spans the lifecycle and needs defined roles, documentation, and management rather than a one-time technical check. NIST also states that AI RMF 1.0 is under revision. A reference to the framework is therefore not a certification and does not make a facility workflow trustworthy.

The current NIST AI RMF Playbook makes the human boundary more explicit. Its voluntary suggestions include differentiating roles and responsibilities for human-AI configurations and oversight and tracking relevant risk information. The Playbook is mutable and is not a checklist. The operational lesson is bounded but strong: human oversight must be designed as a role and workflow, not added as a decorative approval button.

The nine-part facility policy stack

The reference model separates nine responsibilities. A small operation may implement several of them in one system or one team. The logical boundaries should remain visible even when the deployment is compact.

1. Authority record

The authority record answers who may establish, approve, change, suspend, or retire the policy.

Record:

• policy owner and approving authority;
• facility, legal-entity, system, workflow, and consequence scope;
• source policy, procedure, contract, or other approved basis;
• effective and expiration times;
• required reviewers and segregation conditions;
• emergency suspension authority;
• prohibited uses;
• version and supersession relationship.

A code repository can prove that a person committed a file. It does not prove that the person had authority to change a tenant-access rule, release a refund, alter an account restriction, or direct physical work.

2. Policy administration plane

The administration plane turns approved intent into a controlled policy artifact.

It owns:

• policy syntax and schema;
• version-controlled change requests;
• peer and qualified-owner review;
• test cases and expected decisions;
• signing or integrity checks where selected;
• release channels and facility targeting;
• rollback package;
• retirement and archive rules.

The policy steward may prepare a change. The approving authority approves the consequence. Those roles may be held by the same person only when the governing control permits it.

The separation has precedent in access-control architecture. The 2013 OASIS XACML 3.0 Standard distinguishes policy administration, policy information, policy decision, and policy enforcement roles. XACML is an access-control standard, not a self-storage operating recipe. Its value here is architectural: authoring a policy, supplying attributes, deciding, and enforcing are different functions.

3. Context and fact-admission plane

A policy decision is only as bounded as its inputs.

Each input should carry:

• semantic field name and version;
• value and unit;
• facility and entity scope;
• source system and record identity;
• observed and effective times;
• freshness horizon;
• authority to supply the field;
• confidence or validation state where applicable;
• conflict and missing-data disposition;
• privacy and retention class.

“Current manager,” “after hours,” “balance due,” “approved vendor,” and “emergency” are not primitive facts. Each depends on a definition, source, time, scope, and owner. A policy engine should receive a governed fact packet, not an unlabeled collection of convenient values.

4. Policy decision point

The decision point evaluates an exact policy version against an exact input packet and returns a bounded result.

A useful result is richer than a Boolean:

decision_id: DEC-FICTION-0042
policy_id: PAC-FICTION-ACCESS-07
policy_version: 12
input_packet_hash: sha256:fictional
decision: REQUIRE_REVIEW
reason_codes:
  - FACILITY_HOURS_SOURCE_STALE
  - ACTOR_ROLE_CURRENT
allowed_consequence: NONE
review_queue: FACILITY-AUTHORITY-REVIEW
evaluated_at: 2026-08-22T14:31:04Z
expires_at: 2026-08-22T14:36:04Z

The result separates the policy decision from enforcement. REQUIRE_REVIEW is not a denial, an approval, a work completion, or a human decision. It is a routing instruction under an exact rule version.

Current Open Policy Agent deployment documentation describes OPA as a general-purpose policy decision point serving application enforcement points. It also separates policy loading, external data, and decision logging responsibilities. OPA is one mutable product example, not a required provider or evidence of any Facily or modSTORAGE architecture.

5. Policy enforcement point

The enforcement point is the component able to apply the allowed consequence.

Examples might include:

• showing or withholding a next-step control;
• routing a work item to a qualified queue;
• refusing to release a message or transaction;
• requiring an additional approval;
• limiting a credential to a defined scope and duration;
• placing a candidate action in observe-only mode.

The enforcement point must validate that the decision is intended for its facility, action, resource, subject, policy version, and time window. It should record enforced, not_enforced, partially_enforced, expired, superseded, or failed separately.

The NIST Zero Trust Architecture publication separates policy decision mechanisms, administration, and enforcement and rejects implicit trust based solely on network location or ownership. It is a cybersecurity architecture, not a complete facility operating model. The bounded design lesson is that a decision and the component enforcing it should be separately identifiable and observable.

6. Consequence adapter

The consequence adapter converts a permitted policy result into the narrow command a downstream system understands.

This layer matters because policy language and device or application commands rarely share the same vocabulary. ALLOW_CREDENTIAL_ISSUE does not tell a specific controller how to create a credential, which doors it affects, when it starts, when it expires, or how revocation works.

The adapter must not broaden the result. It should bind:

• decision ID;
• exact target and action;
• command version;
• permitted parameters;
• idempotency and correlation keys;
• time window;
• retry behavior;
• reversal command where available;
• downstream response identity.

If the adapter cannot represent the policy consequence without losing meaning, the workflow should hold rather than improvise.

7. Evidence and observability plane

The evidence plane records what was proposed, decided, attempted, enforced, observed, reviewed, and reversed.

Current OPA decision-log documentation describes product-specific events that can include a decision ID, policy query input, result, bundle revision, trace fields, and masking behavior. Those fields can support audit and offline debugging. They do not prove that the policy was authorized, the enforcement succeeded, or the outcome was correct. Inputs may also contain sensitive data, so logging must be intentionally minimized, masked, access-controlled, and retained under approved rules.

For a facility workflow, preserve at least:

• policy and bundle version;
• input packet identity and admissibility result;
• decision, reasons, obligations, and expiry;
• enforcement request and response;
• observed real-world or downstream state where available;
• human review and override record;
• exception, retry, reversal, and rollback links;
• current owner and next action.

An audit log is evidence about an event. It is not the event's meaning, authority, success, or business outcome.

8. Human review and exception plane

Human review should exist where judgment, consequence, law, safety, ambiguity, or policy requires it. The reviewer needs more than a red or green recommendation.

Show:

• the proposed action and consequence;
• exact policy and input versions;
• source citations and freshness;
• conflicts, missing fields, and unknowns;
• deterministic reason codes;
• AI contribution, if any;
• available decisions and their authority requirements;
• time window and expiration;
• rollback or reversal path;
• reviewer identity, scope, and decision record.

The queue should return a bounded disposition: approved, denied, modified, returned_for_evidence, expired, or another approved state. “Reviewed” alone says only that someone looked.

9. Governance and assurance plane

Governance decides which policies deserve to exist and whether they continue to work as intended.

It owns:

• policy inventory and risk tier;
• current and target profiles;
• control mapping without equivalence claims;
• change, testing, deployment, and exception metrics;
• drift and stale-dependency review;
• sampling of decisions and enforcement;
• incident and harm escalation;
• periodic recertification or retirement;
• independent assessment where warranted.

The NIST Cybersecurity Framework 2.0 resource center supports organization-selected cybersecurity outcomes, governance, risk context, and profiles. It does not prescribe this architecture. Similarly, NIST SP 800-53 Rev. 5 offers a flexible, customizable control catalog spanning access, audit, configuration, assessment, monitoring, and other families. Its current page notes a 2025 Release 5.2.0. Selecting or mapping a control does not prove the control was implemented or effective.

A decision vocabulary designed for uncertainty

Binary allow and deny results are sometimes appropriate. Facility operations often need additional states.

A proposed vocabulary might include:

• ALLOW — the bounded action may proceed within the decision scope;
• DENY — the bounded action may not proceed under the current policy;
• REQUIRE_REVIEW — a qualified human disposition is required;
• NOT_APPLICABLE — the policy does not govern this input;
• INDETERMINATE — an error or missing dependency prevented evaluation;
• EXPIRED — the decision is outside its permitted time window;
• OBSERVE_ONLY — calculate and log without enforcement;
• ADVISE — present a recommendation without action authority.

XACML's standard result vocabulary includes Permit, Deny, Indeterminate, and NotApplicable. A self-storage method should not copy those terms carelessly, but it should preserve the same core insight: a decision engine needs an honest state for “the rule does not apply” and “the rule could not determine a result.”

Do not convert INDETERMINATE into ALLOW or DENY by accident. The responsible owner must define fail behavior for each consequence class. A low-consequence display preference may use a different fallback from a credential change, payment release, customer notice, physical-work authorization, or account restriction.

A fictional access-credential example

At fictional Juniper Storage, a role-transition workflow proposes issuing a temporary facility credential.

The policy input says:

• actor role source: current and authoritative;
• facility assignment: current;
• approved access profile: present;
• requested start and end: within the profile limit;
• training field: source unavailable;
• emergency flag: false;
• policy version: 12;
• evaluation mode: enforce.

The policy returns REQUIRE_REVIEW, reason TRAINING_SOURCE_UNAVAILABLE, allowed consequence NONE, review queue FACILITY-AUTHORITY-REVIEW, expiry five minutes.

The enforcement point does not issue a credential. The review queue displays the missing source, policy reason, requested scope, and reviewer authority requirement. A qualified reviewer may return the item for evidence or apply an approved exception. The access system's eventual response is recorded separately from the policy and review records.

This is a fictional control walkthrough. It does not prescribe an access or training rule, demonstrate a deployed product, or claim a safety or security outcome.

What AI may and may not do

AI can help at the edges of the policy stack. It may:

• extract candidate facts with citations;
• classify a request into a candidate policy scope;
• identify missing or contradictory inputs;
• translate a human-readable rule into a draft for review;
• generate test cases and counterexamples;
• explain a deterministic decision in plain language;
• group exceptions by reason and age;
• compare policy versions and flag changed consequences;
• propose a review summary.

AI should not:

• create organizational authority;
• decide which source is authoritative without an approved rule;
• silently fill a missing fact;
• transform a suggestion into executable policy;
• activate a policy version;
• broaden an allowed consequence;
• approve its own exception;
• claim enforcement from a decision response;
• claim effectiveness from log volume;
• convert uncertainty into success.

Keep the AI output in its own evidence class: candidate, proposed, explained, or flagged. A deterministic rule, qualified human, or governed downstream system supplies the next authoritative disposition.

The minimum policy contract

Before an operator allows a policy to influence a facility action, require a contract that names:

1. policy ID, title, owner, approver, and version;
2. purpose, facility scope, entity scope, and prohibited uses;
3. consequence class and allowed decision vocabulary;
4. exact input schema, sources, clocks, freshness, and missing-data behavior;
5. decision logic and reason codes;
6. enforcement target and permitted command shape;
7. human review and exception authority;
8. observe, advise, or enforce mode;
9. tests, coverage expectations, and adversarial cases;
10. activation, expiration, rollback, and retirement rules;
11. logging, masking, access, retention, and replay rules;
12. monitoring, sampling, incident, and reassessment owners.

Then test the contract at beginner, intermediate, advanced, and architect levels. Can a manager explain the difference between a decision and an enforcement? Can an administrator identify the active version? Can a reviewer see an unknown source? Can an architect replay a decision using the exact policy and admissible facts without silently reusing current state?

The companion policy contract register provides 38 fields for authority, scope, fact admission, decisions, enforcement, review, logging, activation, rollback, and monitoring. The 40-case policy readiness suite tests the reference model from basic state separation through distributed version skew, historical replay, semantic migration, AI-derived inputs, emergency change, and decommissioning. The policy-authority reference model gives teams a visual walkthrough. Every row is fictional and requires qualified adaptation.

The architecture test

A policy-as-code system is not mature because its rules compile.

It is mature when an operator can answer:

• Who authorized this rule?
• Which exact version evaluated which exact facts?
• What was unknown, stale, conflicting, or outside scope?
• What bounded decision was returned?
• Which component could enforce it?
• What did that component actually do?
• Which human owned the exception?
• How could the action be stopped, reversed, or reopened?
• What evidence would allow an independent reviewer to reconstruct the chain?

Policy as code earns trust by making authority inspectable. When it hides the human decision behind a technical result, it has automated ambiguity instead of control.

Sources

The package-level source register records the date, exact claim supported, and limitations for every official source used below.

• Artificial Intelligence Risk Management Framework 1.0, NIST, January 26, 2023; current page checked August 22, 2026 and notes the framework is under revision.
• NIST AI RMF Playbook, NIST AI Resource Center, mutable companion checked August 22, 2026.
• Cybersecurity Framework 2.0, NIST, CSF 2.0 released February 26, 2024; current resource center checked August 22, 2026.
• Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Rev. 5, NIST, final December 10, 2020; current page checked August 22, 2026 and notes Release 5.2.0 from August 27, 2025.
• Zero Trust Architecture, SP 800-207, NIST, August 2020.
• eXtensible Access Control Markup Language Version 3.0, OASIS Standard, January 22, 2013.
• How to Deploy OPA, Open Policy Agent official documentation, current mutable page checked August 22, 2026.
• Decision Logs, Open Policy Agent official documentation, current mutable page checked August 22, 2026.