Expert architecture paper · 23 August 2026

The Facility Work Graph: An Operational Ontology for Self-Storage

Keep facilities, records, observations, events, decisions, authorizations, work, evidence, source authority, and effective time distinct before automation or AI acts.

By Jared Mastroianni17 min read

A self-storage operator can have clean tables and still have a broken operating model.

The facility table says “location.” The access system says “site.” The work-order platform says “property.” The utility portal identifies a meter account. The rental system identifies units. The camera platform identifies channels and zones. A reporting layer joins the records by name and address, then an artificial intelligence system recommends work against the joined result.

The data may be syntactically valid. The meaning may still be wrong.

An operational ontology addresses that failure at a deeper level than a field map. It defines the kinds of things the business is talking about, the relationships that may connect them, the states and times that qualify those relationships, the sources allowed to assert them, and the tests that determine whether a graph is usable for a particular operation.

This article proposes a self-storage-specific facility work graph. It is an authored design method, not an industry standard, a product description, or evidence of a deployed system. Its purpose is to help operators make facility work intelligible before they ask automation or AI to act on it.

Open the full-size accessible diagram.

Governed companion package

Inspect the ontology, shapes, and acceptance tests.

These exact files contain an authored proposed ontology and fictional teaching artifacts. They do not establish an industry standard, product deployment, customer implementation, interoperability result, certification, external review, coverage, recognition, or operational truth.

Download the owned source and limitations register Download the ontology acceptance tests Download the Turtle starter model Download the Turtle SHACL shapes Download the accessible facility-work SVG Download the facility-work PNG

A graph is not automatically an ontology

A graph can connect anything to anything. That flexibility is useful, but it is not governance.

The W3C Resource Description Framework defines a graph as a set of subject-predicate-object triples. A statement such as “Gate 2 serves Facility 104” can be represented as a subject, a relationship, and an object. RDF also supports named graphs, which can keep statements from different sources separate. Its identifiers, called IRIs, have global scope. Its graphs are atemporal snapshots even though a vocabulary can describe events and time. Those are strong foundations, but RDF does not decide whether “Gate 2” is a gate lane, a controller, a door group, a vendor record, or a label reused in four systems.

An ontology adds meaning. It says that a Facility is not a StorageUnit, a PhysicalAsset is not the SystemRecord that describes it, an Observation is not a Decision, and a Decision is not an Authorization. It states which relationships are legitimate and which distinctions the operation must preserve.

An operational ontology goes one step further. It makes those distinctions enforceable at the points where work, access, money, safety, customer impact, or public reporting can change.

That final step matters because semantic-web reasoning and operating controls answer different questions. The OWL 2 Primer explains that OWL follows an open-world assumption: a missing fact may simply be unknown. It also does not assume that two different names identify two different individuals. Those properties are appropriate for distributed knowledge. They are dangerous if an operator interprets “no authorization found” as “authorization was unnecessary” or allows a similarity model to treat two records as one facility.

For operational use, open-world representation needs explicit closed-world acceptance tests.

Start with twelve types, not twelve thousand fields

The first version of a facility work ontology should be small enough to explain on one page. The following twelve types cover a useful operating core.

Type	What it represents	Self-storage example	What it must not be confused with
Organization	An accountable organization or operating unit	An operating company or approved service provider	A software account or display brand
Facility	A governed operating location	One self-storage facility	A parcel, building, mailing address, or vendor location record
SpatialZone	A physical or logical area within a facility	Building, floor, drive aisle, access zone, climate zone	A rentable unit or access-control group
StorageUnit	A rentable physical unit identity	Unit B-214	A rental agreement, tenant, door, or current occupancy state
PhysicalAsset	A maintained physical thing	Gate operator, keypad, camera, HVAC unit, meter	The system record, sensor point, or work order describing it
ExternalRecord	A provider- or source-scoped record	Vendor location 101 or access panel record 44	The enterprise facility or asset itself
RoleAssignment	A dated assignment of authority or responsibility	Regional manager for Facility 104 from May through August	A person identity or timeless job title
Observation	A recorded signal or assertion	Gate current exceeded threshold at an observed time	A root cause, decision, authorization, or completed repair
OperationalEvent	A bounded occurrence relevant to work	Access lane failed to open	The raw observation or the later response
Decision	A chosen course based on evidence	Inspect controller before dispatching vendor	Permission to execute the work
Authorization	An explicit grant under a role and policy	Approve after-hours vendor entry for a named scope	A recommendation, confidence score, or work result
WorkRecord	Requested, scheduled, performed, verified, or closed work	Inspect, repair, test, and close the gate issue	Evidence that the work succeeded

Two supporting types should be added early even if they sit outside the twelve-type core:

an EvidenceArtifact, such as a photograph, reading, invoice, call log, test result, or signed attestation;
a PolicyOrRule, which defines an allowed transition, required evidence, decision right, or validation constraint.

This is not an exhaustive model of self-storage. It intentionally omits legal conclusions, customer identity, payment logic, rental terms, insurance, accounting, and jurisdiction-specific obligations. Those domains require their own owners, sources, privacy controls, and review.

The crucial separation: thing, record, assertion, and authority

Most damaging integration errors begin by collapsing four layers.

The thing is the facility, unit, gate operator, camera, meter, or other entity in the operating world.

The record is one system's representation of that thing. It has a provider, namespace, identifier, schema, and effective period.

The assertion is a claim about the thing or record. It has a source, time, method, and confidence or evidence boundary.

The authority determines whether that source is allowed to make that claim for that purpose.

Consider a utility portal that calls a service point “River Campus.” The portal can be authoritative for its account number and perhaps for billed consumption within its published scope. It is not automatically authoritative for the enterprise facility name, rentable square footage, unit inventory, ownership, operating status, or physical containment of the meter.

A field map often copies the label. An ontology records the relationship:

Utility account U-883 is an ExternalRecord issued by Source S. It is asserted to serve Meter M during Interval T. Meter M is located within Facility F under an approved source and effective-dated mapping.

The longer statement is not bureaucracy. It is the minimum structure needed to decide which conclusions are permitted.

Names are labels; identity is a governed decision

An operator should adopt two identity rules that appear contradictory until both are enforced:

the same label does not prove the same entity;
different labels do not prove different entities.

“Main Gate” might refer to a lane, a gate leaf, a motor, a controller, a keypad group, or an entire entry system. Conversely, “North Annex,” “River Campus,” and vendor location “101” may refer to one facility across different periods and sources.

OWL's lack of a unique-names assumption is useful here: two names are not automatically two things. But equivalence must not be guessed. A merge should be a first-class decision with:

both candidate identifiers;
match evidence;
source authority;
effective time;
approver and role;
systems affected;
confidence if a model assisted;
rollback or separation path;
preserved prior records.

AI can rank candidates. It should not silently promote similarity into identity authority.

For public structured data, Schema.org provides useful descriptions such as Place, containedInPlace, branchCode, and identifier. That vocabulary can help describe an evidence-supported public location. It is not a master-data system and should not be used to infer internal ownership, legal relationships, source precedence, or equivalence among operating records.

Relationships carry more risk than classes

Teams often spend too much time debating names for classes and too little time governing edges. In operations, the edge is where the decision usually hides.

The facility work graph needs a controlled relationship vocabulary. A practical first set is:

contains and containedBy for spatial hierarchy;
serves for an asset, meter, or system relationship with explicit scope;
describedBy for a physical thing and its source record;
identifiedBy for a source-scoped identifier;
observedBy for a signal and its producer;
occurredAt for an event and facility, zone, unit, or asset;
affected for work or an event and the impacted entity;
derivedFrom for a transformed assertion and its inputs;
decidedBy and authorizedBy for distinct decision-right records;
usedEvidence for a decision or verification and its evidence packet;
supersedes for a correction that preserves history;
distributedTo for an approved change and a downstream consumer;
hasBeginning and hasEnd for the effective period of a relationship.

Brick is relevant but narrower. Its current documentation models building entities such as equipment, points, locations, and logical collections as nodes connected by relationships in an RDF graph. The current official distribution page lists version 1.4.4, released May 1, 2025, separately from a nightly build. That makes Brick a useful alignment candidate for building equipment and location metadata. It does not by itself represent self-storage rental operations, approval rights, work evidence, customer impact, or the decision boundary proposed here.

The right design is often alignment, not replacement: reuse stable external concepts where they fit, then define a small operational layer for the distinctions the business must enforce.

Time has two clocks

A reliable facility graph needs at least two times for changing facts.

Effective time answers: when was this true in the operating world?

Recorded time answers: when did this system learn or store it?

Suppose a gate controller was replaced on August 4, but the asset register was corrected on August 9. A single timestamp forces the system to choose between two truths. A two-clock record can say:

controller B became effective on August 4;
the replacement assertion was recorded on August 9;
controller A remains the prior identity and is not reused;
work and readings from August 4 onward attach to controller B after reconciliation;
reports produced before August 9 remain reproducible from the earlier recorded state.

The stable 2017 OWL-Time Recommendation supplies general concepts for instants, intervals, beginnings, ends, duration, and ordering. The current /TR/owl-time/ page observed in 2026 is a Candidate Recommendation Draft, so durable public claims should cite the dated stable Recommendation unless a draft feature is explicitly required and labeled.

Time alone is not enough. Every timestamp also needs a timezone or declared temporal reference, precision, and a rule for unknown or approximate values. Midnight without a zone is not an auditable operating boundary.

Provenance is not a source URL pasted into a note

The W3C PROV-O Recommendation begins with three classes: Entity, Activity, and Agent. It connects them with relationships for use, generation, derivation, attribution, association, and time. That pattern is useful because it distinguishes a report from the activity that generated it and from the agent responsible for the activity.

For facility work, a provenance packet should answer:

What assertion or artifact exists?
Which activity generated or changed it?
Which inputs did that activity use?
Which human, organization, system, model, or rule participated?
Which version was active?
When did the activity occur and when was it observed?
What authority allowed the resulting assertion to become operational?

This prevents an AI summary, derived metric, vendor export, and source-system record from appearing equally authoritative merely because all four are visible on one dashboard.

Provenance also makes correction possible. If a released metric was derived from a broken facility crosswalk, the operator can identify affected versions, recompute from corrected inputs, issue a correction note, and preserve the prior result. Without lineage, a correction becomes an unexplained overwrite.

Validation should test the graph, not repair it in place

An ontology without validation becomes an illustrated glossary.

SHACL, the W3C Shapes Constraint Language, provides a useful model: a data graph and a shapes graph enter validation, and a validation report comes out. The specification requires those input graphs to remain unchanged during validation. That separation is operationally sound. A validator should detect a missing authorization, invalid state, ambiguous identifier, or broken effective period. It should not silently rewrite the evidence it is judging.

A starter facility graph should fail validation when:

a Facility lacks a stable identifier;
a source-scoped external identifier lacks its issuing source;
an effective-dated relationship has no beginning;
a current relationship has two conflicting authoritative values without an exception state;
a WorkRecord affects an entity that cannot be resolved;
an Authorization lacks actor, role, policy, scope, or time;
an AI-proposed assertion lacks model version, evidence, confidence, and disposition;
a correction has no superseded assertion;
a closed work item lacks the required verification artifact;
a public export includes a relationship classified as internal or sensitive.

Passing those tests does not prove that the real-world fact is true, safe, current, or legally sufficient. Validation establishes conformance to declared rules. Source accuracy, operational acceptance, privacy, security, and legal review remain separate gates.

The companion package includes a small Turtle data graph, a separate SHACL shapes graph, an accessible SVG relationship diagram, a PNG rendering, and the operator-to-architect acceptance tests. They are teaching artifacts, not a production schema. A conforming validation run proves only that this sample meets the declared structural shapes; the included negative check removes an observation time and confirms that the validator reports the resulting failure.

A fictional gate incident, represented correctly

Consider a fictional self-storage facility with a vehicle gate that fails to open at 6:42 a.m.

A conventional ticket might contain one row:

Main gate — failed — vendor called — fixed.

The facility work graph represents a chain of distinct facts:

Facility F-104 contains Access Zone Z-2.
Gate Operator A-17 serves Z-2 during an effective interval.
Access Record R-44 is one provider's description of A-17.
Observation O-901 records a fault code from R-44 at the observed time.
Event E-310 states that entry through Z-2 did not complete at the occurred time.
Decision D-88 selects local inspection before vendor dispatch and cites O-901 plus a staff report.
Authorization A-55 grants the on-duty manager permission under Policy P-7 to inspect and, if needed, dispatch a named vendor within a defined scope.
Work W-600 records requested, scheduled, performed, tested, and closed states separately.
Evidence V-72 preserves the post-work functional test.
Verification Q-19 concludes that the defined acceptance test passed; it is not the same thing as the photograph or vendor note.

Now imagine a model proposes that R-44 refers to Gate Operator A-17 with 0.94 confidence. That proposal becomes another assertion with a model version and evidence. It does not replace the approved crosswalk, authorize dispatch, or prove repair.

The example is intentionally fictional. It demonstrates a representation pattern, not a product feature, operating result, staffing recommendation, safety procedure, or customer case.

The six competency questions

An ontology should be designed against questions, not aesthetics. Before adding a class or relationship, the team should be able to name the query it enables.

A minimum facility work graph should answer:

Which open work affects assets that currently serve a named access zone?
Which work was authorized by a role that was valid at the authorization time?
Which closed work lacks the evidence required by the policy version then in force?
Which facility metrics depend on assertions derived from a superseded identity mapping?
Which external records probably describe the same physical asset but remain unapproved match candidates?
Which approved master-data changes have not been reconciled to every required downstream system?

If the graph cannot answer these questions, adding more types will not make it operational.

Beginner to architect: an implementation ladder

Beginner: name the things

Choose one facility and one recurring workflow. Create stable identifiers for the facility, one zone, one unit, and one maintained asset. Separate each physical thing from the records that describe it. Record current and legacy labels without deleting either.

The beginner outcome is not a knowledge graph platform. It is a small identity register that no longer joins work by display name.

Intermediate: name the edges and authority

Add effective-dated containment, service, source-record, role, decision, authorization, evidence, and correction relationships. Publish a source-authority matrix that says which role or system may assert each critical fact.

The intermediate outcome is a trace that distinguishes what happened, what was observed, what was decided, what was authorized, what work occurred, and what evidence supports closure.

Advanced: make conformance executable

Write validation shapes or equivalent rules for identity, cardinality, time, authority, provenance, state transitions, and correction. Store validation results separately. Add a bitemporal query that can reproduce what was effective and what was recorded at a past checkpoint.

The advanced outcome is a release gate. Invalid graphs enter an exception queue rather than production joins.

Architect: govern evolution

Separate ontology version, validation version, data snapshot, inference rules, and source schema. Define namespace ownership. Run competency queries before release. Test migration and rollback. Preserve asserted and inferred graphs separately. Create public, internal, restricted, and synthetic graph views.

The architect outcome is not a universal vocabulary. It is a controlled semantic contract that can evolve without rewriting history.

AI belongs at the assertion layer

The ontology creates several productive places for AI:

propose candidate identity matches;
classify unstructured work descriptions into controlled types;
extract possible assets, locations, times, and evidence references;
identify missing provenance or contradictory relationships;
explain validation failures in operator language;
prioritize a reconciliation queue.

It also creates a hard stop. A model output is a proposed assertion. Promotion to an authoritative fact requires the authority, evidence, and review defined for that fact type.

At minimum, a model-assisted assertion should retain:

model and prompt or rule version;
input references and allowed-use status;
generated time;
confidence or other uncertainty representation;
proposed subject, relationship, and object;
reviewer and decision;
resulting authoritative assertion, if approved;
rollback or correction path;
excluded sensitive or synthetic inputs.

NIST AI RMF 1.0 is a useful governance anchor because it is voluntary, use-case agnostic, and organized around Govern, Map, Measure, and Manage. NIST also states that version 1.0 is being updated. The framework does not certify this ontology, prescribe self-storage workflow, or prove that a model is safe or effective.

The practical acceptance test

The companion Facility Work Ontology Acceptance Tests file contains 32 checks across beginner, intermediate, advanced, and architect levels. Each test names:

the acceptance question;
pass criteria;
required evidence;
a self-storage failure example;
the first remediation;
a suggested owner;
the trigger for re-review.

The file is diagnostic, not a maturity score. An operator should mark a test Passed only when the named evidence exists. Partial, unknown, and not-applicable states should remain explicit. A failed test should create a bounded remediation item; it should not be averaged away by unrelated passes.

Start with one workflow. A gate-access exception, climate-control alert, unit-door repair, delinquency handoff, vendor invoice exception, or facility rename is enough. Run the first sixteen tests manually. The gaps will usually reveal which distinctions the current systems are erasing.

What not to centralize

The facility work graph should not become a copy of every source field.

Keep source-specific detail in the source when the enterprise does not need to govern it. Do not centralize secrets, credentials, raw access histories, personal data, camera footage, payment data, or legal documents merely because a graph can link them. Represent the minimum reference, classification, retention rule, and access boundary needed for the operating purpose.

Do not publish the internal graph as public structured data. A public Place description and an internal authorization graph serve different audiences and carry different risks.

Do not allow ontology work to postpone known operational corrections. If a facility is mapped incorrectly today, correct it through the current governed process. The ontology should make future corrections safer; it is not a reason to wait for architectural perfection.

The design test

A facility work ontology is ready for a pilot when a manager can inspect one fictional or approved workflow and explain, without opening five systems:

which real-world entities are involved;
which records describe them;
which source asserted each fact;
when each relationship was effective and recorded;
what was observed;
what occurred;
what was decided;
who or what authorized action;
which work was performed;
which evidence supports the outcome;
what changed after a correction;
which downstream systems reconciled the change.

If those answers remain compressed into one status field, the operation does not have a shared model of work. It has a collection of labels.

The point of the facility work graph is not to make self-storage sound more technical. It is to prevent technical systems from erasing the distinctions operators need to remain accountable.

Limitations and release boundary

This is a proposed educational method authored by Jared Mastroianni. All operating examples are fictional. The paper does not establish an industry standard, product capability, customer implementation, deployment, adoption, performance result, legal conclusion, safety procedure, compliance status, certification, interoperability guarantee, staffing requirement, publication, indexing, coverage, recognition, or expert-status outcome.

The companion tests require adaptation by the relevant operational, data, security, privacy, records, finance, legal, and technical owners before use in a live environment.