The Facility Change-Impact Graph: Test the Operational Blast Radius Before Release

Method and evidence boundary: This is Jared Mastroianni's authored proposed method. Harbor Annex and every facility, record, dependency, consequence, threshold, action, test, and result in the examples are fictional. A complete-looking graph, canary, rollback plan, passing test, or readback record is not proof of authority, completeness, safety, compliance, performance, or outcome.

Most facility changes are reviewed as isolated edits.

A manager changes access hours. An analyst renames a unit type. A software team updates a prompt. A regional operator replaces a vendor mapping. Someone adds a field to an integration, edits a workflow rule, changes a user entitlement, or loads a new policy document into an AI retrieval index.

The edit may be small. The operating effect may not be.

The real question is not, “Did the configuration save?” It is, “Which people, locations, systems, decisions, messages, and physical actions can now behave differently?”

That is a graph problem.

A facility change-impact graph is an operating method for tracing a proposed change through the things it can affect before the change is released. It connects the exact change to its dependencies, consequence paths, tests, release cells, rollback target, and post-change evidence. It is not a prediction that nothing will go wrong. It is a disciplined way to expose what must be known, tested, held, or watched.

This matters in self storage because one facility instruction can exist in many places at once: the property-management system, access-control platform, website, call-center script, tenant message template, internal knowledge base, reporting layer, and AI retrieval corpus. Those copies may update at different speeds and under different owners. A clean change in one system can therefore create an inconsistent operating state across the portfolio.

The graph makes that inconsistency reviewable before it becomes an incident.

Open the full-size accessible diagram.

Governed companion package

Inspect the impact register and release gates.

These exact files contain an authored method and fictional or blank-contract examples. They do not establish factual authority, dependency completeness, product deployment, customer use, performance, safety, compliance, certification, or independent validation.

Download the source and limitations register ↓Download the change-impact register ↓Download the release-test suite ↓Download the accessible change-impact SVG ↓Download the change-impact PNG ↓

A diff is not an impact assessment

Traditional change review begins with the object being changed: a line of code, configuration value, policy paragraph, schema, model version, prompt, source file, or entitlement. The reviewer sees the before state, the after state, and perhaps a ticket explaining why the change is needed.

That is necessary, but it is only the first node.

Google’s current SRE guidance describes configuration as an interface for changing system behavior and recommends separating configuration from resulting data, preserving ownership and version history, validating meaning rather than syntax alone, and supporting gradual application, stop controls, and rollback. Its canary guidance defines a canary as a partial, time-limited deployment evaluated against a control and stresses representative populations, attributable measures, isolation, staged expansion, and rollback. These are useful foundations, but facility work needs an additional boundary: software-release methods do not automatically authorize experiments on tenants, building occupants, access, life-safety systems, financial transactions, or regulated workflows.

In facility operations, the same apparent edit can have several classes of downstream effect:

1. Representation: a label, identifier, unit attribute, or facility name changes.
2. Information: a report, page, message, or answer presents different content.
3. Recommendation: a queue, score, or AI response changes what a person is asked to consider.
4. Authorization: a rule changes what a person or system is allowed to approve.
5. Execution: a system can change physical access, dispatch work, send a notice, post a charge, or alter another consequential state.

The farther the path travels, the stronger the evidence and human authority should become. A typo correction in an internal label and an access-hours rule may both be “configuration,” but they do not belong in the same release class.

The graph should make that difference visible.

Start with an exact change packet

The graph is only as reliable as its starting node. “Update the chatbot” is not a change packet. Neither is “fix access hours” or “deploy the new model.”

Use an exact packet with at least these twelve fields:

1. Change ID: one immutable identifier for the proposal.
2. Change type: policy, configuration, code, schema, data, model, prompt, retrieval corpus, connector, identity mapping, entitlement, workflow, or other.
3. Before identity: the exact version, hash, record ID, effective interval, or source state being replaced.
4. After identity: the exact proposed version, hash, record ID, effective interval, or source state.
5. Business intent: the operating problem the change is supposed to address.
6. Facility scope: exact locations, portfolios, units, assets, channels, and user groups in scope.
7. Explicit exclusions: locations, objects, people, or actions that must not change.
8. Authority source: the person, policy, agreement, approved record, or governing system allowed to authorize the change.
9. Consequence ceiling: the most consequential action the changed state may influence or perform.
10. Release window and owner: who controls the release and when.
11. Rollback target and owner: the exact prior state and person allowed to restore it.
12. Readback plan: evidence that will show what actually changed after release.

If any of those fields is unknown, record unknown. Do not silently convert missing information into an assumption. In the graph, unknown is a first-class state because it changes the release decision.

The packet also needs a stable fingerprint. For a file or artifact, that may be a cryptographic hash. For a database or configuration object, it may be an immutable version or a canonical serialized snapshot. For a bundle of records, it may be a manifest of exact identities and values. The goal is simple: the team must be able to prove which change it reviewed, which change it released, and which prior state it can restore.

Build the graph from six node types

The graph should stay small enough to operate. Six node types cover most facility change paths.

1. Change nodes

The proposed policy, configuration, data, code, model, prompt, connector, entitlement, or identity change.

2. Source nodes

The records and authorities that justify or supply the change: an approved facility schedule, system-of-record value, signed instruction, documented policy, asset register, model card, source dataset, or access-control role.

3. Processing nodes

The systems and transformations that consume or alter the changed state: imports, rules, formulas, queues, APIs, retrieval pipelines, AI models, human review, scheduled jobs, and manual copying.

4. Presentation nodes

The places where people or systems see the result: websites, dashboards, call-center screens, notices, tenant portals, reports, work orders, mobile apps, AI answers, and exports.

5. Action nodes

The decisions or executions that can follow: approve, deny, dispatch, notify, charge, unlock, lock, escalate, publish, or update another source.

6. Evidence nodes

The records that demonstrate what happened: immutable logs, post-change exports, screenshots with provenance, acknowledgments, reconciliations, physical readback, exception records, and rollback receipts.

These nodes are connected by labeled edges. reads_from, transforms, copies_to, retrieves, recommends, authorizes, executes, notifies, writes_back, and proves are useful starting labels. The label matters because adjacency alone is ambiguous. A dashboard that reads access hours and a controller that executes them are both connected to the same value, but they create different operational consequences.

W3C PROV-O provides stable general concepts for entity, activity, agent, derivation, generation, attribution, revision, and invalidation. Those concepts can help structure lineage. They do not decide whether a record is true, whether a person has authority, or whether a facility change is safe. The change-impact graph adds those operating questions rather than treating lineage as approval.

Trace four dependency horizons

Do not attempt to map the whole enterprise for every change. Trace the graph outward in four bounded horizons.

Horizon 0 — the changed object. Verify the exact before and after state, syntax, schema, ownership, and intended scope.

Horizon 1 — direct consumers. Identify every known system, person, job, prompt, report, rule, or interface that directly reads the changed object.

Horizon 2 — operational decisions. Identify the recommendations, approvals, work orders, messages, financial actions, and physical controls that can change because a direct consumer behaves differently.

Horizon 3 — portfolio and external propagation. Identify copies, exports, caches, vendors, public channels, shared models, cross-location rules, and write-back paths that can preserve or spread the changed state.

Each horizon should end with one of four labels:

• mapped: the dependency and test are known;
• not_applicable: the reviewer recorded why the path cannot apply;
• held: the path exists but the change will not be allowed to reach it;
• unknown: the dependency cannot yet be resolved.

An unexplored path is not not_applicable. It is unknown.

This gives the graph a useful stop rule: traversal may stop when all outward edges are mapped, explicitly held, or bounded as not applicable. If a consequential action remains reachable through an unknown edge, the release is not ready for that consequence class.

Classify consequence before choosing a release method

Use consequence classes to prevent a low-risk test from becoming authorization for a high-risk rollout.

Class	Highest reachable effect	Default release boundary
C0	Internal representation only	Peer review and exact readback
C1	Informational display or report	Audience-bounded release and content comparison
C2	Recommendation or prioritization	Shadow mode or human confirmation before action
C3	Authorization, financial, tenant-facing, or physical workflow	Named approver, reversible cell, live monitoring, manual stop
C4	Life safety, emergency control, legal disposition, or another severe or irreversible outcome	No autonomous canary on people or property; specialist governance and validated non-production evidence required

The class is the highest effect reachable through the graph, not the label attached to the changed object. A prompt edit that can only draft an internal note may be C1. The same prompt edit connected to automatic tenant notices or work-order dispatch may be C3.

This is also where AI changes should be treated as system changes, not copy edits. A model, prompt, embedding, retrieval source, ranking rule, guardrail, tool permission, or entitlement can change which information is selected, how it is summarized, who can see it, what action is recommended, and whether the output is executed. NIST AI RMF 1.0 is voluntary, non-sector-specific, and use-case agnostic; NIST’s current program page notes that version 1.0 is being revised. NIST AI 600-1 is a voluntary Generative AI profile with suggested actions around human-AI configuration, information integrity, component integration, data and content lineage, testing, third-party effects, monitoring, override, recovery, and change management. Those documents support disciplined risk work, not a declaration that a particular facility AI system is trustworthy or compliant.

Convert every consequential edge into a test

A graph that only documents dependencies is a picture. An operating graph turns every consequential edge into a test.

For each edge, record:

• the exact upstream and downstream node;
• the expected transformation;
• the facility and user scope;
• the consequence class;
• the test input and expected result;
• prohibited changes;
• the evidence source;
• the test owner;
• the pass, fail, hold, or unknown rule;
• whether the test is pre-release, canary, post-release, or rollback.

Tests should cover more than the happy path. At minimum, include:

1. Scope test: only the named facilities, objects, and users are affected.
2. Exclusion test: explicitly excluded locations and roles remain unchanged.
3. Authority test: the change originates from the named authority source.
4. Version test: reviewed, released, and rollback identities match exactly.
5. Semantic test: the changed value means what the receiving system assumes it means.
6. Copy test: caches, replicas, exports, and derived records update or remain held as designed.
7. Entitlement test: users and automated tools can access only permitted state.
8. Negative-path test: missing, stale, conflicting, or malformed inputs stop safely.
9. Cross-location test: a local change cannot leak into another facility through defaults, shared groups, or reused identifiers.
10. Execution test: no recommendation becomes an action without the authority required by its consequence class.
11. Readback test: the actual resulting state can be observed independently of the release command.
12. Rollback test: the prior state can be restored and its propagation verified.

NIST SP 800-218 provides a high-level secure software-development framework that can inform preparation, protection, production, and response practices. It is not a facility operations standard and does not certify this method. Its practical lesson here is that change evidence should be part of the development and release process, not improvised after an incident.

Release by consequence, not convenience

The safest release cell is not always “one location.” A location may share a call center, access-control group, website template, identity directory, data warehouse, integration credential, or AI corpus with the rest of the portfolio. A nominal one-site release can therefore have portfolio-wide edges.

Define a release cell as the smallest group of nodes and edges that can be changed and observed without contaminating the control or exposing an unapproved consequence.

A valid release cell records:

• exact location and object membership;
• shared dependencies;
• user population;
• time window;
• expected event or query volume;
• control population, if a comparison is valid;
• metrics and evidence attributable to the change;
• stop authority;
• rollback authority;
• consequence ceiling.

Use production canaries only where the consequence is reversible, the population is appropriate, the test is attributable, and the affected people or property are not being used as an unapproved experiment. For tenant communications, access, financial workflows, physical controls, and other C3 or C4 paths, prefer non-production simulation, historical replay with protected data, shadow evaluation, manual confirmation, or a deliberately isolated test environment. A gradual rollout does not cure a bad authority model.

Before release, freeze unrelated changes that would contaminate attribution. If two prompts, a pricing rule, an access schedule, and a connector all change together, a good or bad result cannot be assigned cleanly. The graph should either split the bundle or document why the bundle is inseparable and test it as one versioned unit.

Readback must be independent of the command

A successful API response, save button, deployment job, or configuration status proves only that a command was accepted or a process completed. It does not prove that the intended operating state exists everywhere it matters.

Post-change readback should travel the graph in the forward direction and then reconcile backward:

1. confirm the exact changed object;
2. inspect every direct consumer in the release cell;
3. exercise the defined decision or presentation paths;
4. verify that prohibited paths did not change;
5. collect action and evidence receipts;
6. compare the resulting state with the change packet;
7. record unexplained differences as exceptions;
8. stop expansion until exceptions are resolved or accepted by named authority.

The readback source should be as independent as practical from the mechanism that issued the change. If the deployment job says a configuration was applied, inspect the consumer’s effective configuration. If a message workflow says a notice was sent, inspect the exact message record and recipient scope. If an AI pipeline says a corpus was refreshed, test retrieval identity, entitlement, source version, and the output’s consequence path. If an access schedule was changed, verify both the system’s effective rule and a safe, authorized functional test.

Rollback needs the same discipline. Restoring a prior value is not complete until the graph shows that caches, consumers, recommendations, messages, and action paths have returned to the governed prior state. A rollback receipt without operational readback is another command acknowledgment.

A fictional self-storage example

Harbor Annex is fictional. Its names, systems, timing, values, and outcomes are teaching data only.

Suppose Harbor Annex changes tenant gate access from 06:00–22:00 to 05:00–23:00. The approved facility schedule is the authority source. The property-management record is the intended system of record.

A diff shows one field changing. The impact graph finds more:

• the access-control connector reads the field every fifteen minutes;
• the tenant portal copies the hours into an information panel;
• a call-center knowledge article contains a manually copied version;
• the website has a separately managed facility-hours field;
• an AI assistant retrieves both the system-of-record value and the stale call-center article;
• an exception rule prevents access for a specific held unit regardless of facility hours;
• a regional default can overwrite a facility-level value during nightly synchronization;
• the audit export records the effective controller rule one hour after change.

The highest reachable effect is physical access, so the change is C3 even though the starting node is a text-like schedule field.

The graph creates a release plan:

1. verify the approved schedule, facility identity, and effective date;
2. test the connector mapping in an isolated environment;
3. confirm the held-unit exception still overrides the schedule;
4. update or hold the manually copied article and website field;
5. remove the stale article from AI retrieval until its source identity matches;
6. prove the regional default cannot overwrite the facility value;
7. schedule a named operator and rollback owner;
8. perform a safe authorized access test at a boundary time;
9. inspect the controller’s effective rule, portal, article, website, AI answer, and delayed audit export;
10. record any mismatch in an exception ledger and stop portfolio expansion.

This method does not predict that access will work, that the change is legally sufficient, or that the facility should adopt the hours. It exposes the dependencies and evidence needed for an authorized operator to decide.

The 45-minute facility change drill

The companion register and release-test suite support a practical review at four levels.

Beginner — 10 minutes

Choose one real but low-consequence pending change. Write the before state, after state, facility scope, exclusions, authority source, and rollback target. If the team cannot identify those six facts, stop there; the change is not ready.

Intermediate — 10 minutes

List every direct consumer. Include manual copies, scheduled jobs, exports, caches, shared defaults, AI retrieval sources, and human scripts. Mark each as mapped, held, not applicable, or unknown.

Advanced — 15 minutes

Trace each consumer to a recommendation, authorization, message, financial action, or physical effect. Assign the highest consequence class. Convert every C2–C4 edge into a named test with pass, fail, hold, and unknown criteria.

Architect — 10 minutes

Define the release cell, control or comparison boundary, stop authority, rollback owner, independent readback, propagation horizon, and evidence-retention rule. Ask one final question: “Which hidden shared dependency would make this apparently local change portfolio-wide?” Record the answer or record unknown.

The output is not a score. It is a decision packet: release, release with holds, return for evidence, or do not release.

Five failure patterns to reject

The save-button fallacy. The system accepted the edit, so the team assumes the operating state changed correctly.

The one-site illusion. A shared default, credential, corpus, or integration makes a facility-scoped change portfolio-wide.

The green-dashboard shortcut. Aggregate measures look normal while the affected path is too small, delayed, or mixed with control traffic to be visible.

The reversible-value myth. The configuration can be rolled back, but messages, exports, physical actions, or external copies cannot.

The AI copy-edit exception. A prompt or retrieval change is treated as prose even though it can alter recommendations, entitlements, disclosures, or execution.

The common problem is not lack of documentation. It is failure to connect the exact change to the operational consequences it can reach.

The operating standard

No facility change should advance farther than its graph supports.

If the team knows the change but not its consumers, stop at Horizon 0. If it knows the consumers but not the consequence paths, stop at Horizon 1. If a C3 or C4 path lacks named authority, rollback, or independent readback, hold that path. If the release cell shares an unmeasured dependency with the control, do not call the comparison a canary result. If an unknown edge can reach a consequential action, treat the unknown as part of the blast radius.

This can feel slower than changing the field and watching the dashboard. It is faster than discovering after release that the field was never local, the dashboard was not attributable, the rollback did not propagate, or the AI answer was reading a stale source.

The facility change-impact graph turns change management into an operational proof chain:

exact change → mapped dependency → consequence class → test → bounded release → independent readback → reconciled evidence

That chain does not eliminate risk. It gives operators a credible basis for deciding what may change, where, under whose authority, with what stop condition, and how they will know what actually happened.

Companion tools

• Facility change-impact register template — a 20-field fictional example spanning the exact change, sources, consumers, presentations, actions, evidence, horizons, consequence classes, release cells, tests, rollback, and unknowns.
• Facility change release-test suite — 30 beginner-to-architect tests covering identity, scope, authority, dependencies, entitlement, conflict, shadowing, attribution, stop controls, rollback, independent readback, and closure.
• Facility change-impact graph diagram and PNG rendering — an accessible five-stage visual from exact change through reconciled evidence.

Primary sources and limitations

• Google SRE Workbook — Configuration Design and Best Practices — general system-configuration guidance; not a self-storage control standard or facility deployment result.
• Google SRE Workbook — Canarying Releases — general software-release and evaluation guidance; not authorization to experiment on people, property, access, life-safety, financial, or regulated workflows.
• NIST Artificial Intelligence Risk Management Framework 1.0 and current AI RMF program page — voluntary, cross-sectoral risk-management guidance; version 1.0 is being revised and does not certify this method or any facility system.
• NIST AI 600-1 — Generative Artificial Intelligence Profile — voluntary suggested actions requiring contextual tailoring; not a deployment authorization, legal conclusion, or trustworthiness certificate.
• NIST SP 800-218 — Secure Software Development Framework 1.1 — general secure software-development practices; not a facility operations standard or compliance conclusion.
• W3C PROV-O Recommendation — stable general provenance vocabulary; lineage does not establish truth, authority, entitlement, safety, approval, or legal sufficiency.

This is an authored proposed method by Jared Mastroianni. All facility examples are fictional. The paper does not report a modSTORAGE or Facily.ai deployment, customer result, product capability, performance result, service level, certification, legal conclusion, publication, indexing outcome, independent coverage, or recognition.