The Multi-Location Policy Compiler: Turn One Operating Rule Into Site-Specific Controls Without Erasing Local Reality

Method and evidence boundary: This is an authored operating method. The portfolio, facilities, systems, people, schedules, and results in the example are fictional. The method is not evidence of a product deployment, customer result, legal conclusion, security posture, certification, or service level. A compiled control is a candidate artifact—not permission to activate it.

Multi-location operators often write one rule and then discover that they operate many realities.

The rule might be simple: after the office closes, route new access anomalies to a human before changing a tenant's access state. At one facility, the access system exposes a reliable event feed. At another, the only timely signal is a vendor report. A third uses a different timezone, has no after-hours reviewer, and cannot reverse the same action remotely. The portfolio policy is one sentence. The safe operational behavior is not.

Most organizations solve this with either copy-and-paste or improvisation. Copy-and-paste produces site documents that drift. Improvisation leaves the policy in a handbook while each system, manager, and automation interprets it differently. Neither approach tells an operator exactly which source version, local facts, exception, and authority produced the control that is active at a facility.

The better model is a policy compiler.

A policy compiler takes a versioned portfolio rule, a versioned description of a site's capabilities, and explicitly governed local overlays. It validates those inputs, refuses forbidden combinations, and emits a site-specific control artifact plus a machine-readable explanation of how it was derived. That artifact still must pass tests, authorization, staged activation, readback, and rollback gates.

The goal is not to make facility operations look like software engineering. The goal is to stop treating local variation as invisible prose.

Open the full-size accessible diagram.

Governed companion package

Inspect the policy source, site manifest, and conformance gates.

These exact files contain an authored method and fictional or blank-contract examples. They do not establish a product deployment, customer result, source authority, activation decision, conformance outcome, performance level, certification, or independent validation.

Download the source and limitations register ↓Download the policy source and site-manifest template ↓Download the policy-compiler conformance suite ↓Download the accessible policy-compiler SVG ↓Download the policy-compiler PNG ↓

The distinction that makes the model useful

A policy is not a configuration, and a configuration is not an observed operating state.

• Policy says what must remain true and who may decide.
• Site facts say what the location can actually observe, execute, reverse, and staff.
• An overlay adapts an allowed parameter without rewriting the policy's invariant.
• An exception is a governed, time-bounded departure with its own authority and exit condition.
• A compiled control artifact is the exact site-specific result of combining pinned inputs.
• Activation is a separate authorized change.
• Readback is evidence of what the facility or downstream system actually accepted and did.

Those states should never collapse into a single word such as deployed.

This separation has strong technical precedents, although none is a facility standard. Google's configuration-design guidance recommends separating a high-level interface from generated static data, preserving ownership and version history, validating semantics, and distinguishing a configuration change from its application. It also emphasizes gradual application, the ability to stop, and rollback (Google SRE, 2018). Open Policy Agent demonstrates the narrower architectural pattern of evaluating structured inputs against declarative policy while keeping decision-making separate from enforcement (OPA documentation).

I am borrowing those patterns. I am not arguing that a self-storage operator must install OPA, use a particular language, or convert a property into a software project.

Start with invariants, not settings

The first mistake in a portfolio rule is to lead with a system field: set review mode to manual after 6 p.m. That is already an implementation choice. It may make sense at one site and be impossible or unsafe at another.

Start with the invariant:

A new access anomaly must not cause an irreversible access-state change when the evidence is incomplete or the required review authority is unavailable.

The invariant describes what the operation must preserve. Parameters can vary around it:

• the local definition of after-hours;
• which anomaly classes require review;
• which evidence fields are mandatory;
• the reviewer role and escalation path;
• the allowed temporary state;
• the maximum exception window;
• the permitted rollback mechanism.

Some variation is legitimate. Some would defeat the policy. The source rule has to declare the difference.

The 12-field policy source

I use a compact source object with twelve fields:

1. policy_id — a stable identity that does not change when wording changes.
2. policy_version — the exact approved version.
3. intent — the operational outcome the rule is trying to preserve.
4. scope — facilities, event classes, systems, and time windows to which it applies.
5. invariants — conditions no local overlay may weaken.
6. parameters — values that must be resolved for each site.
7. allowed_overlays — fields local authority may add, replace, or narrow.
8. prohibited_overrides — changes the compiler must refuse.
9. required_evidence — facts that must be fresh enough and traceable enough to compile.
10. authority — who may approve the policy, an overlay, an exception, and activation.
11. exception_contract — required reason, compensating control, expiry, review, and exit condition.
12. effective_window — when the version becomes eligible and when it is superseded or withdrawn.

The source object should be readable by an operator and structured enough to validate. A rule that cannot say which fields are invariant is not ready for automated compilation.

Give each site a capability manifest

The compiler cannot safely infer a site's reality from its name, region, or software vendor. It needs a versioned capability manifest.

The manifest should answer operational questions:

• Which source is authoritative for tenant identity, access state, unit identity, operating schedule, and staff availability?
• Which events can the site observe, and at what latency and confidence?
• Which actions are supported: notify, hold, queue, change, reverse, or only recommend?
• Which actions require a local person, a vendor console, a physical visit, or a second approval?
• Which device or integration versions are actually present?
• What is the site's timezone, and how are daylight-saving transitions handled?
• What is the independent readback path for each consequential action?
• What rollback target exists, and has that rollback path been tested for the exact control family?
• Which capabilities are unknown, stale, temporarily unavailable, or disputed?

Unknown is a first-class value. It must not silently become false, unsupported, or safe.

A manifest is not a marketing inventory. It is a dated assertion about what a site can support, with source, observer, confidence, and expiry. If a capability comes from a vendor document, the manifest should say so. If it comes from a local test, it should identify the test. If the test is old, the compiler should see the age.

Local overlays need a grammar

“Apply the local settings” is not an overlay contract. It is an invitation to ambiguity.

An overlay should identify:

• overlay ID and version;
• target policy and version range;
• site or site class;
• exact field path;
• operation—add, replace, remove, narrow, or declare unsupported;
• old value and proposed value when relevant;
• reason and supporting evidence;
• approving authority;
• effective and expiry timestamps;
• conflict priority;
• required tests;
• rollback or removal instruction.

The merge semantics must also be explicit. RFC 7396 is useful precisely because it exposes how much a small word like merge can hide: in JSON Merge Patch, object members may be added, replaced, or removed with defined behavior, while a non-object patch replaces the target and arrays cannot be partially patched under that format. A facility policy system does not need to use JSON Merge Patch, but it does need equivalent precision.

For example, if required_evidence is a list, does a local overlay append one item, replace the whole list, or remove one item? If the rule does not say, the compiler should refuse the overlay.

Overlays are not exceptions

An overlay stays inside the parent policy's allowed variation. An exception does not.

Suppose the portfolio rule permits a facility to choose a review window between 15 and 45 minutes. Setting Site B to 30 minutes is an overlay. Operating for two days without the required second reviewer because that reviewer is unavailable is an exception. Calling both “local settings” destroys the audit trail.

Exceptions should be rare, visible, expiring, and paired with a compensating control. Expiry must have behavior: revert, refuse, or escalate. “Review later” is not an expiry behavior.

The IETF's YANG 1.1 model offers a useful analogy. It supports conditionally implemented features, revision-pinned imports, and explicit deviations when an implementation cannot faithfully support a model. It also says the resulting data model must remain valid after declared deviations (RFC 7950). That does not make YANG a facility standard. It illustrates a discipline worth preserving: variation should be declared, versioned, and validated rather than hidden.

The compile order must be deterministic

If the same inputs can produce different outputs depending on who clicks first, the process is not a compiler. It is a negotiation engine.

Use one published order:

1. Load the exact policy version.
2. Load the exact site-manifest version.
3. Load every eligible overlay and exception by identity and version.
4. Verify signatures or recorded authorities and effective windows.
5. Validate the structure and required fields of every input.
6. Resolve site capabilities and explicitly mark unknown or stale facts.
7. Apply overlays in a fixed precedence order.
8. Reject conflicting overlays that address the same field without an explicit resolver.
9. Evaluate non-overridable invariants.
10. Evaluate exception conditions and expiries.
11. Produce either a compiled artifact or a refusal report.
12. Run the conformance suite against the exact artifact.

The compiler should be deterministic: identical pinned inputs should produce identical canonical output and the same content hash. Time, live lookups, and model responses should not leak into compilation unnoticed. If current external data is required, fetch it before compilation, record it as a versioned input, and give it a freshness rule.

This is the difference between the weather API said something during the run and the compiler used observation OBS-204, captured at 14:02 UTC, valid for ten minutes, from source S-7.

The output is a control artifact, not a verdict

A useful compiled artifact contains more than final settings. It should carry its derivation:

• artifact ID and canonical hash;
• policy ID and version;
• site-manifest ID and version;
• overlay and exception IDs and versions;
• compiler version;
• compiled timestamp;
• resolved values;
• inherited values;
• deliberately omitted controls;
• unresolved facts;
• invariant evaluations;
• test-suite version and results;
• required activation authority;
• activation mode and release cell;
• independent readback method;
• rollback target and trigger;
• expiry and supersession behavior.

The artifact should also distinguish four outputs:

• compile-pass — the inputs were structurally and semantically resolvable;
• test-pass — the candidate passed its defined conformance cases;
• activation-authorized — a named authority approved an exact artifact;
• observed-conformant — post-activation readback matched the intended state within a declared window.

None implies the next.

A structured validation report is more useful than a red banner. The W3C's SHACL recommendation validates a data graph against explicit shapes and produces results that can identify a focus node, path, value, severity, and source constraint (W3C SHACL). A facility compiler can borrow that reporting shape without using RDF: say which site, field, input, constraint, severity, and remediation caused refusal.

The conformance suite should try to break the rule

Policy review usually asks whether the happy path sounds reasonable. A conformance suite asks whether the rule still holds at the edges.

At minimum, test these cases:

1. Missing manifest version — compilation refuses rather than selecting “latest.”
2. Stale authority fact — an expired capability observation blocks the affected control.
3. Unsupported action — the site cannot execute or reverse the requested action.
4. Invariant override — a local overlay attempts to weaken a non-overridable condition.
5. Ambiguous merge — two overlays target the same field without a resolver.
6. Expired exception — the exception cannot leak past its end time.
7. Timezone edge — the rule is tested across midnight and daylight-saving transitions where applicable.
8. Partial evidence — missing or contradictory evidence produces a hold or refusal, not a guessed value.
9. Deterministic rebuild — recompiling the same pinned inputs produces the same canonical hash.
10. Version incompatibility — an overlay written for policy 2.x cannot silently apply to 3.x.
11. Activation without readback — the operational state remains unverified until the independent observation arrives.
12. Rollback dependency — the system refuses activation if the rollback target or authority is unavailable.

OPA's official documentation is one concrete example of treating policy as testable and running positive, negative, and data-driven cases (OPA policy testing). The transferable lesson is not a command-line tool. It is that policy logic deserves executable counterexamples.

A fictional three-site compilation

Consider a fictional portfolio called Northline Storage. Its policy ACCESS-ANOMALY/3.2 says:

When an access anomaly has incomplete identity evidence, no automated process may make an irreversible access-state change. The system may create a review packet, notify an authorized reviewer, and place the case in a reversible temporary state only if the site manifest confirms that the state and rollback path are supported.

The policy permits local overlays for review hours, reviewer roles, notification channels, and a temporary hold duration from 15 to 60 minutes. It prohibits removing the identity-evidence requirement or authorizing an irreversible change.

Site Alder

Alder's current manifest shows a structured anomaly feed, a reversible temporary hold, a tested remote rollback, and an after-hours reviewer. Its overlay selects a 20-minute hold and two notification channels.

The compiler emits the review-packet and temporary-hold controls. Tests pass. That does not activate them; an authorized person still approves the exact artifact, a limited release cell receives it, and independent readback must confirm the accepted state.

Site Birch

Birch can observe the anomaly but cannot independently confirm a rollback after hours. The policy's invariant does not permit the compiler to pretend otherwise.

The output is narrower: create the review packet and notify the on-call person, but do not emit the temporary-hold action. The artifact records the omitted action and the missing rollback capability. This is not a failed facility. It is an honest compilation.

Site Cedar

Cedar's manifest is expired, and two overlays disagree about the reviewer role. The compiler refuses to produce an activatable artifact. Its report identifies the stale manifest, the conflicting field, both overlay IDs, and the authorities needed to resolve the conflict.

The refusal is the safe output. A system that always produces configuration is not necessarily more automated. It may simply be less truthful.

Where AI belongs—and where it does not

AI can help with the messy work around compilation:

• extracting candidate parameters from a policy draft;
• mapping site documents into a proposed capability manifest;
• detecting inconsistent terminology;
• proposing edge cases for the test suite;
• explaining a refusal report in operator language;
• comparing two compiled artifacts and summarizing the differences.

Those are proposed uses, not evidence of deployed performance.

AI should not silently decide which source is authoritative, invent a missing capability, approve its own exception, or transform a probabilistic answer into a deterministic policy fact. Model output belongs in a candidate lane with source references, confidence, and human disposition. If it becomes an input, that promotion should be explicit and attributable.

The NIST AI RMF 1.0 is useful here because it treats AI risk as contextual and lifecycle-wide and describes separation between building or using AI and verification or validation as a best-practice pattern. It is voluntary and non-sector-specific. NIST's current program page also says version 1.0 is being revised, so any implementation should date the version it actually used rather than calling the framework permanently current (NIST AI RMF program page, checked August 22, 2026).

Architecture controls that keep the compiler honest

An advanced implementation should preserve eight properties.

1. Pinned dependencies

Every policy, manifest, overlay, schema, test suite, and compiler build has an exact identity. “Latest” is a discovery convenience, not a reproducible input. YANG's revision-specific import behavior is a useful precedent: a dependency does not change merely because a newer revision appears.

2. Canonical serialization

The same resolved artifact must serialize the same way before hashing. Otherwise, harmless field ordering can look like an operational change, or a meaningful change can hide inside unstable output.

3. Hermetic compilation

Compilation should not depend on unrecorded live state. Google's configuration guidance notes that external resources which can change outside the versioned environment make rollback difficult. Capture required observations as governed inputs with freshness limits.

4. Authority-aware fields

Authority is scoped. The person allowed to set office hours may not be allowed to change an access-state invariant. The compiler should validate authority at the field and action level, not merely ask whether someone has an administrator account.

5. Refusal as a product feature

Unknown capability, unresolved conflict, expired exception, failed invariant, or missing rollback must produce a useful refusal artifact. Operators need a path to resolution, not a mysterious error code.

6. Diff before activation

Show the exact difference between the current active artifact and the candidate: changed values, added or removed actions, authority changes, newly stale inputs, and rollback implications. Review the consequence, not just the text.

7. Staged activation and independent readback

Compilation is offline reasoning. Activation affects a real facility. Use a bounded release cell, stop conditions, and a readback source independent enough to detect non-application or misapplication.

8. Rollback as a compiled dependency

Do not append rollback after approval. Resolve the rollback target, authority, supported mechanism, and confirmation method during compilation. If any is missing, the candidate should not be activatable for a consequential control.

A 60-minute operator-to-architect exercise

Use the companion policy-source-and-site-manifest-template.csv and policy-compiler-conformance-suite.csv.

Beginner — 10 minutes

Choose one portfolio rule. Rewrite it as an outcome and one invariant. Circle every word that is actually a local parameter: time, role, device, threshold, channel, or evidence source.

Deliverable: one sentence that must remain true at every location.

Intermediate — 15 minutes

Pick two sites that differ. Complete their capability rows using only facts that have a source and check date. Use unknown where evidence is missing. Do not infer a capability from the vendor name.

Deliverable: two versioned site manifests with at least one meaningful difference.

Advanced — 15 minutes

Write two overlays. Make one valid and make the other attempt to weaken an invariant. Define exact merge operations, authorities, effective windows, and expiry behavior.

Deliverable: one compile-pass candidate and one deliberate refusal.

Architect — 20 minutes

Run twelve conformance cases. Produce a candidate artifact with pinned input identities, canonical hash placeholder, resolved and omitted controls, validation results, activation authority, readback method, and rollback target. Then change one manifest fact and predict the exact diff.

Deliverable: an explainable artifact and a deterministic refusal report—not a live activation.

What this method does not solve

A policy compiler cannot prove that source facts are true, that a person has proper authority, that a downstream vendor will behave as documented, or that a physical mechanism will work when needed. It cannot replace legal review, security engineering, safety analysis, accessibility review, labor judgment, vendor validation, or local operational expertise.

It can make the boundaries visible.

It can show which rule version was used, what the facility was believed to support, where local variation entered, which exception was active, which tests ran, and why the system emitted or refused a control. That is a meaningful improvement over a policy PDF, a spreadsheet of undocumented settings, and a manager's memory.

One policy across many facilities should not mean one undifferentiated configuration. It should mean one governed intent, compiled against explicit local reality, with variation made visible and authority kept intact.

---

Source and artifact note

The dated source register is available in source-register.csv. The companion tools are policy-source-and-site-manifest-template.csv and policy-compiler-conformance-suite.csv. The fictional examples in those files are exercises only.