The Facility Intervention Contract: Prove What an AI-Requested Action Actually Changed

Method and evidence boundary: This is Jared Mastroianni's authored proposed method. Every facility, system, device, point, command, person, event, value, observation, and result in the examples is fictional. A proposal, authorization, transport receipt, service result, controller report, schema-conforming record, or current-looking observation does not establish physical effect, safety, security, compliance, deployment, performance, or closure.

An AI system recommends that a self-storage gate remain unlocked fifteen minutes longer. An authorized operator approves the recommendation. An integration sends the command. The vendor endpoint returns success. The activity log says complete.

Did the gate actually remain unlocked?

That question cannot be answered by any of those records alone.

The recommendation proves what the AI proposed. The approval proves what a person authorized. The outbound request proves what an integration attempted. The response proves what one system reported about processing the request. None of them necessarily proves the physical effect, the duration of that effect, the state seen by a tenant at the keypad, or restoration to the governing schedule.

This gap matters wherever software can change a facility: access control, doors, gates, lighting, HVAC, cameras, alarms, signage, elevators, payment restrictions, overlocks, notifications, and public operating information. It matters more when AI assembles or proposes the action because fluent intent can hide weak authority, stale state, uncertain execution, and missing readback.

I use a facility intervention contract to close that gap. It is a versioned evidence packet that binds one proposed real-world change to its target, authority, preconditions, consequence class, command identity, delivery evidence, execution evidence, independent observation, reconciliation, and reversal state.

This is an authored operating method, not a description of a released product or a claim about any facility deployment. Every facility, device, event, person, value, and result in the examples is fictional.

Open the full-size accessible diagram.

Governed companion package

Inspect the intervention contract and readback gates.

These exact files contain an authored method, blank controls, and entirely fictional examples. They do not establish physical effect, factual authority, product deployment, customer use, performance, safety, security, compliance, certification, or independent validation.

Download the source and limitations register ↓Download the intervention register ↓Download the conformance suite ↓Download the JSON Schema ↓Download the fictional JSON record ↓Download the readback runbook ↓Download the accessible intervention SVG ↓Download the intervention PNG ↓

A successful request is not a successful intervention

The distinction begins with the system boundary.

NIST SP 800-82 Rev. 3 describes operational technology as programmable systems and devices that interact with the physical environment or manage devices that do. Its examples include building automation and physical access control. That makes a facility intervention a cyber-physical claim, not merely an application transaction.

The application can prove that it produced a request. A broker can prove that it accepted a message. A controller can prove that it accepted or processed an operation. A sensor can report an observed state. An operator can inspect a physical condition. These are related facts, but they are not interchangeable.

The separation is visible in primary protocol sources. MQTT 5.0 limits its quality-of-service flows to delivery of an application message between a sender and receiver. It explicitly notes in the QoS 1 flow that the receiver need not complete onward delivery before acknowledging the message. OPC UA Part 4 separates a service-call result from the status of individual operations inside that call. Those semantics are useful precisely because they show why a transport or service receipt must not be promoted into proof of the physical outcome.

An intervention therefore needs at least four proof boundaries:

1. decision proof — what was proposed, on which evidence, for which purpose;
2. authority proof — who or what was allowed to approve that exact action and scope;
3. execution proof — what command a specific target accepted or performed;
4. effect proof — what independently observed condition changed, for how long, and whether governing state was reconciled.

If a workflow stops at boundary three, its honest state is execution reported, not effect verified.

Nine states, not one completed flag

A single completed=true field erases the information an operator needs most. The contract uses nine explicit states.

1. Proposed

The proposal has an immutable identity, purpose, requested change, supporting evidence, limitations, and a generating actor. An AI-generated proposal is labeled as such. It does not inherit authority from the model, prompt, user interface, or system that displayed it.

2. Qualified

Identity, current governing state, source authority, effective time, conflicts, safety constraints, privacy limits, and dependency conditions have been checked. Qualification can reject the proposal or narrow its permissible scope.

3. Authorized

An identified principal approves a specific action envelope: target, value, time window, maximum duration, consequence class, allowed route, stop conditions, and reversal plan. Approval of a general objective is not approval of any action an agent might infer from it.

4. Dispatched

The system records the exact command, destination, protocol, correlation identity, idempotency rule, preconditions, expiry, dispatch time, and retry policy. A dispatched command might never reach the intended target.

5. Accepted

The receiving system returns a transport, service, or operation-level receipt. The receipt records who produced it and what it actually means. HTTP 200, an MQTT acknowledgement, or an OPC UA Good result is preserved as that protocol's evidence—not rewritten as “gate open” or “temperature changed.”

6. Executed

The target reports that it applied, scheduled, clamped, rejected, or partially applied the requested change. Target-reported execution is stronger than transport acceptance, but it can still be wrong, stale, simulated, delayed, or disconnected from the physical mechanism.

7. Effect observed

An allowed readback source observes the postcondition inside the required window. The contract records source identity, measurement time, quality, independence grade, expected value, observed value, tolerance, and uncertainty. A command echo is not an independent readback.

8. Reconciled

The observed state is compared with the authorized postcondition and the governing source. Any schedule, cache, work item, notification, exception, or subsequent action is updated. A temporary intervention also proves its expiration or restoration.

9. Closed, compensated, or unresolved

Closure is typed. verified_closed means the intended effect and governing state agree. compensated means the initial effect diverged and an authorized compensating action was independently verified. accepted_residual means an accountable owner accepted a bounded residual with an expiry. unresolved means the system lacks enough evidence to claim success or safe reversal.

These states should advance monotonically through new records. Do not overwrite a failed or superseded attempt. Preserve it and link the next attempt.

The contract is a claim graph

A facility intervention is not one event. It is a set of claims produced by different actors.

The AI claims, “this action serves the stated objective.” The policy service claims, “this action is allowed under this policy version.” The operator claims, “I authorize this envelope.” The integration claims, “I dispatched this command.” The endpoint claims, “I accepted or executed it.” The sensor claims, “I observed this value.” The governing system claims, “this is the current operational state.”

W3C PROV-DM provides a useful vocabulary for entities, activities, agents, generation, use, derivation, attribution, and invalidation. It can describe how the proposal, authorization, command, receipt, observation, and reconciliation record relate. Provenance does not make any claim true, however. The contract must still state which source is authoritative for which field and what evidence is required before moving to the next state.

The minimum graph has these immutable identities:

• intervention ID;
• proposal ID and proposal version;
• authorization ID and policy version;
• command ID and attempt ID;
• target facility, system, device, and point IDs;
• transport or service receipt ID;
• target execution record ID;
• independent observation ID;
• reconciliation ID;
• reversal or compensation ID, when used.

Correlation links these records. It does not collapse them.

Authority must bind the physical consequence

An access-control proposal has several possible principals: the person asking for the change, the role permitted to approve it, the organization responsible for the location, the vendor system enforcing it, and the person accountable for the physical consequence.

The intervention contract resolves those principals before dispatch. It records:

• the requester and generating actor;
• the approving principal and delegated role;
• the facility and target scope;
• the allowed action and prohibited side effects;
• the policy or operating rule and version;
• the start, expiry, maximum duration, and local-time interpretation;
• the consequence class;
• required human review;
• readback method and timeout;
• stop, rollback, and escalation owners.

NIST SP 800-53 Rev. 5, current Release 5.2.0 is not a facility intervention specification, but its access-control, audit, configuration-management, contingency, incident-response, and system-integrity control families reinforce the need to keep authorization, accountability, change control, recovery, and monitoring explicit. The contract borrows those disciplines without claiming certification or control implementation.

Consequence class determines the gate. A read-only draft can tolerate different uncertainty than an unlock command, an alarm change, a payment restriction, or a public-hours update. The paper's companion register uses four teaching classes:

• C0 informational — no direct operational effect;
• C1 reversible low consequence — bounded change with reliable independent readback;
• C2 material operational — customer, access, revenue, privacy, or service consequence requiring named human authority;
• C3 safety, security, legal, financial, or broad irreversible consequence — automation stops; specialist and accountable authority are required.

Those labels are a proposed method. Each operator must define its own classes with qualified legal, safety, security, financial, and operational owners.

Preconditions are part of the command

A correct command against the wrong state can be an unsafe intervention.

Suppose a fictional facility's access schedule is version 44 when an AI evaluates it. An operator later changes the schedule to version 45. If the earlier command still executes without a version precondition, it may erase the newer decision.

The contract binds a command to preconditions:

• expected target identity and lifecycle state;
• expected current value or version;
• required source freshness;
• allowed execution window;
• required device, network, power, and sensor quality;
• absence of a conflicting active intervention;
• maximum acceptable clock uncertainty;
• allowed policy version;
• expiry after which the command must be rejected.

If a precondition changes, the command is not retried as though nothing happened. It returns to qualification.

RFC 9110 Section 9.2.2 defines an HTTP method as idempotent when multiple identical requests have the same intended effect on the server as one request. That definition is intentionally scoped to the intended server effect. It does not prove that a facility device acted once, that the state stayed correct, or that a non-HTTP side effect is idempotent. The intervention contract therefore records both protocol idempotency and operational idempotency.

Operational idempotency asks: if this exact command is applied twice, can the real-world consequence exceed the authorized envelope? “Set schedule version 46 to this complete value if current version is 45” is easier to reason about than “extend access another fifteen minutes.” The second phrasing can accumulate on retry unless the target and deduplication semantics are precise.

Delivery semantics stop at their boundary

The receipt taxonomy has five grades:

Grade	Evidence	What it does not prove
R0	Local request constructed	dispatch, receipt, execution, or effect
R1	Transport accepted or connection write completed	correct target, application acceptance, execution, or effect
R2	Broker or service accepted the message	onward delivery, device execution, or effect
R3	Target operation reported success, partial success, clamp, or asynchronous completion	independent physical state or duration
R4	Independent observation matched the authorized postcondition	continued correctness, restoration, or global reconciliation

These grades are not rankings of vendors. They are labels for evidence strength in one bounded intervention.

OPC UA StatusCode guidance requires clients to inspect good, uncertain, and bad result states. The same discipline belongs in any facility integration: preserve the native receipt, code, qualifier, and diagnostic context. Do not coerce uncertain, clamped, scheduled, accepted, or completes asynchronously into a generic success.

OpenTelemetry's tracing API defines span status for an operation and leaves Unset as the default. A trace can connect proposal, authorization, dispatch, response, observation, and reconciliation. But a green span still reflects the convention used by the instrumentation. It is observability evidence, not an automatic physical attestation.

Independent readback has degrees

“Read after write” is not enough if the read comes from the same cache or command echo.

The contract uses an independence grade:

• I0 echo — the response repeats the requested value;
• I1 same-service state — the same service reports its stored post-command value;
• I2 separate subsystem — another subsystem reports the target state;
• I3 separate physical measurement — a sensor or device path independently observes the effect;
• I4 qualified human observation — an identified person inspects the relevant condition using a defined procedure.

Higher is not always better. A human may be unable to verify a controller register, and a sensor may be poorly calibrated. The right grade depends on consequence, latency, precision, and failure modes. The contract records why the selected readback is sufficient and what it cannot see.

A readback includes:

• observation source and owner;
• observed-at and received-at times;
• quality or confidence flag supplied by the source;
• expected value, tolerance, and measurement unit;
• maximum observation delay;
• required persistence duration;
• conflicting observations;
• independence grade and rationale;
• evidence link and retention rule.

For a temporary intervention, two readbacks may be required: entry into the authorized state and restoration after expiry.

Reversal is another intervention

Rollback is often described as a button. In a physical facility, reversal is a new consequential action against a changed world.

If a gate-open extension was applied, a reversal must first determine whether closing the gate is safe now. A vehicle could be present. An emergency override could have become active. The local manager could have issued a newer instruction. The device might be offline. The original preconditions may no longer hold.

A reversal therefore receives its own proposal, authority, preconditions, command identity, receipt, readback, and reconciliation. It links to the original intervention as compensation or restoration, but it does not reuse stale approval.

NIST SP 800-160 Vol. 1 Rev. 1 distinguishes verification and validation within the engineering of trustworthy systems. The intervention method applies a practical version of that separation: verify that the specified command path behaved as designed, then validate that the observed facility condition is acceptable for the operating purpose and context. The NIST publication does not certify this authored contract or any implementation of it.

A fictional gate-hours walkthrough

Consider Harbor Annex, a fictional self-storage facility used only for teaching.

At 17:40 local time, a fictional manager asks an AI assistant whether the outbound gate should remain available until 18:15 because a moving truck is delayed. The AI retrieves the current access schedule, an active storm alert, the maintenance state of the exit loop, and the manager's delegated role. It proposes a fifteen-minute extension from 18:00 to 18:15, subject to a clear exit lane and no active emergency override.

The proposal is not sent directly to the access controller. It enters the intervention contract.

Qualification discovers that the loop detector's last health reading is outside the allowed freshness window. The contract stops at qualified_failed. The manager can choose a qualified human inspection or abandon the change. A fictional attendant inspects the lane, confirms it is clear, and records the observation under a site procedure. The manager then authorizes exactly one schedule version, one facility, one gate direction, and one expiry.

The integration dispatches the versioned command. The endpoint returns an accepted receipt. The controller later reports that schedule version 46 is active. A separate gate-status path reports the outbound gate operating under the extended schedule. At 18:16, a restoration readback confirms the standard schedule is governing again.

The honest record contains all of those facts. It does not say the AI “kept the facility open successfully.” It says:

• the AI proposed a bounded change;
• an authorized manager approved it after a qualified observation;
• the command was accepted and target execution was reported;
• an allowed independent path observed the intended state;
• the standard schedule was later restored and reconciled.

If the second readback had been missing, the intervention would remain unresolved even if the first command returned success.

AI belongs upstream of authority and downstream of evidence

AI can add useful structure without becoming the source of authority. It can:

• assemble candidate context;
• identify missing preconditions;
• detect conflicting state;
• draft an intervention packet;
• classify consequence under an approved rubric;
• propose readback sources;
• compare expected and observed values;
• summarize unresolved evidence;
• route the packet to the accountable person.

It should not silently expand scope, infer authority, invent a physical state, convert a receipt into an effect, or close an intervention because the narrative sounds coherent.

NIST AI RMF 1.0 is a voluntary, non-sector-specific framework organized around Govern, Map, Measure, and Manage. NIST also states that AI RMF 1.0 is being revised. The contract uses the released 1.0 framework as risk-management context, not as certification.

NIST AI 600-1 is a voluntary cross-sectoral profile for generative AI. It supports explicit human oversight, documentation, monitoring, and incident considerations, but it does not prescribe facility controls or prove a model fit for physical operations.

NIST CSF 2.0 provides outcome-oriented Govern, Identify, Protect, Detect, Respond, and Recover functions. A facility intervention contract can map its authorization, monitoring, exception, response, and restoration practices to those outcomes. The mapping remains an internal design aid, not a claim of conformity.

Measure proof quality, not automation volume

Counting commands can reward the wrong behavior. Better measures expose evidence quality and unresolved consequence.

Useful operating measures include:

• proposals by consequence class;
• proposals rejected for missing identity, authority, freshness, or preconditions;
• authorized interventions by human and automated route;
• commands with unique idempotency and attempt identities;
• receipts by R0–R4 grade;
• interventions with sufficient independent readback;
• time from dispatch to observation;
• restoration-readback pass rate for temporary changes;
• unresolved, compensated, and accepted-residual counts;
• duplicate, late, expired, clamped, and partially applied commands;
• interventions whose governing state diverged after physical effect;
• manual overrides that invalidated pending automation.

Do not convert those internal controls into claims of safety, reliability, savings, occupancy impact, or customer benefit without a separately designed and executed evaluation.

A practical adoption sequence

Beginner: stop saying done too early

Pick one low-consequence workflow. Replace done with proposed, authorized, dispatched, accepted, effect observed, reconciled, and closed. Make the evidence visible to the operator.

Intermediate: define the intervention packet

Use the companion facility intervention register. Assign identity, authority, consequence, preconditions, receipt semantics, readback, expiry, restoration, and exception ownership. Run the readback runbook for one fictional case.

Advanced: test failure and retry

Run the conformance suite. Test duplicate delivery, stale approval, late execution, partial success, clamped values, out-of-order observations, sensor disagreement, missing restoration, manual override, provider outage, and irreversible effects. Require the system to stop or degrade honestly.

Architect: make proof a first-class interface

Adopt a versioned contract such as the companion JSON Schema and fictional instance. Separate command and observation channels where consequence warrants it. Preserve native receipts. Model compensation as a new intervention. Test clock quality, partition behavior, replay, retention, access control, evidence confidentiality, and the exact boundary of each assurance claim.

The architect exercise

Choose one proposed facility action and answer these questions without using the word “success”:

1. What exact physical or governing state is supposed to change?
2. Which identity is the target, and how was it resolved?
3. Who may authorize that consequence at that facility and time?
4. Which preconditions must still hold when the command executes?
5. What does each transport, service, and device receipt actually prove?
6. Which observation is sufficiently independent of the command path?
7. How long must the effect persist, and what tolerance is allowed?
8. What newer state or manual override invalidates the intervention?
9. What evidence is required to restore or compensate safely?
10. Who owns an unresolved effect after the integration times out?

If the packet cannot answer those questions, the correct architecture is not more automation. It is a visible stop state with an accountable owner.

The operating principle

AI intent, human authorization, system acceptance, target execution, physical effect, and governing-state reconciliation are six different claims.

A mature facility operating system preserves each claim, its producer, its time, its limitations, and its evidence. It does not promote one receipt into the next state. It does not call a physical change closed because an API call ended. It does not treat rollback as timeless. And it does not let the model write the final line of the audit trail merely because the model wrote the first line of the proposal.

The facility intervention contract is the bridge between digital action and operational truth: not “the command worked,” but what changed, who was allowed to change it, how we know, what remains uncertain, and what happens next.

Source and evidence boundary

The companion source register records the exact primary or official sources, dates, claims supported, and limitations used in this paper. All cited standards and frameworks remain the work of their publishers. The intervention contract, states, receipt grades, independence grades, consequence classes, fictional Harbor Annex walkthrough, tools, and exercises are Jared Mastroianni's proposed method.

Nothing here establishes a released Facily.ai or Facily OS capability, a modSTORAGE deployment, a customer result, service level, security or safety outcome, legal or financial conclusion, certification, industry-standard status, external review, publication acceptance, indexing, ranking, coverage, recognition, or independent validation.