The Facility Event Spine

An event bus can move a message across a portfolio. It cannot decide whether the message is true, whether the sender had authority, whether the receiving system changed state, or whether the operation is complete.

That distinction matters in self-storage because one operating fact can cross a property-management system, access platform, call center, work-order tool, public website, accounting process, sensor, and an AI-assisted workflow before a regional operator sees it. If every message is treated as equivalent, the portfolio becomes fast at distributing ambiguity.

A multi-location operator needs more than event transport. It needs a governed facility event spine: a pattern that separates observations, commands, policy decisions, derived projections, and reconciliation evidence while preserving stable facility identity across them.

This paper proposes that pattern. It is a reference architecture and operator method, not a description of a deployed product, a self-storage industry standard, a customer result, or a claim about scale or reliability.

Open the full-size facility event-spine diagram.

Do not let the word “event” erase operating meaning

In ordinary implementation conversations, teams may call every message an event. That shortcut is expensive. A door controller observation, a request to close a facility, an approval to publish different hours, and a readback confirming the public page changed are not interchangeable records.

Use five explicit roles:

Record role	What it asserts	What it does not prove
Observation event	A source reported that something occurred or was observed.	That the report is authoritative, current, unique, or complete.
Command	An authorized actor or service requested a bounded state change.	That the receiver accepted, executed, or reconciled the change.
Policy decision	A named policy version evaluated a defined request and returned allow, deny, stop, or review.	That enforcement occurred or the operating result followed.
Projection	A derived view assembled from events and other sources for a declared purpose.	That the view governs every underlying field.
Evidence record	A receipt, readback, inspection, posted result, or other record supports one defined state transition.	More than the evidence source and method can actually establish.

This vocabulary prevents a common architectural failure: an observation enters a stream, a consumer updates a dashboard, and the dashboard silently becomes the authority. The event spine should make that promotion impossible unless a declared policy and source-of-truth rule allow it.

The spine has six governed layers

The pattern is logical, not vendor-specific. A small operator could implement parts of it with a database, queue, workflow tool, and disciplined records. A larger portfolio may use brokers, schema registries, policy services, stream processors, and dedicated evidence stores. The control boundaries should remain visible in either case.

1. Facility identity and partition

Every material record begins with a stable, opaque facility_ref. Public names, street addresses, management labels, legal entities, software-account IDs, device groups, and third-party location IDs are attributes or translations—not substitutes for the stable reference.

The partition also carries the facility’s lifecycle state, local timezone, applicable operating region, and identity-map version. A command for FAC-DEMO-101 must not be routed by fuzzy name matching to “Airport,” “Main Street,” or whichever record looks closest.

Portfolio-wide work should declare its scope as a set of stable facility references or a governed group version. “All facilities” is not a durable target if properties can enter or leave the portfolio while a workflow is running.

2. Message contract and envelope

The contract layer defines the required context for every record role. CloudEvents is a useful vendor-neutral starting point for event data: its core specification requires id, source, specversion, and type; it defines time as an optional RFC 3339 timestamp for the occurrence; and it allows optional subject, dataschema, and extension attributes.

CloudEvents also states that source plus id identifies a distinct event and may be reused when a duplicate is resent. That is a delivery-level deduplication key. It is not automatically a business idempotency rule. Two distinct events can still describe the same underlying occurrence, and one occurrence may produce more than one event.

A facility contract therefore adds governed semantics such as:

• record_role and facility_ref;
• aggregate_type, aggregate_ref, and expected version;
• correlation_ref for a shared operating case;
• causation_ref for the immediate record that caused this one;
• occurred_at, observed_at, emitted_at, and received_at when each is known;
• policy_ref, authority scope, and consequence class;
• schema URI and compatibility classification;
• sensitivity, retention, and safe evidence references; and
• replay, retry, and idempotency metadata.

AsyncAPI 3.0 can describe the messages, channels, and operations of a message-driven API without prescribing one protocol or broker topology. It can also distinguish messages that behave as events, commands, requests, or responses. The document is valuable as a machine-readable contract surface; it does not determine self-storage authority, field ownership, reconciliation, or operating policy.

3. Command gateway

Observations should not directly mutate consequential operating state. A command gateway is the point where a proposed change becomes a bounded request. It validates facility scope, actor or service authority, policy version, expected state, expiration, idempotency key, and consequence class.

A good command is narrow and testable. close_facility is too vague if it might mean changing office staffing, tenant access, rentals, public hours, phone routing, or maintenance dispatch. The gateway should accept smaller commands such as:

• publish_temporary_office_hours;
• suspend_new_move_in_appointments;
• create_weather_inspection_task;
• request_access_schedule_review; or
• notify_approved_contact_group.

The gateway should reject a command when the target facility, expected version, authority, required evidence, or rollback owner is missing. A duplicate with the same idempotency key should return the existing result rather than repeat the side effect.

4. Policy and authority plane

The policy plane answers who or what may decide, for which facility, under which conditions, and with what limits. It should preserve the input facts, policy reference and version, effective time, decision, reason code, required reviewer role, and enforcement point.

AI belongs behind this boundary. A model may classify an incoming observation, summarize a weather bulletin, identify affected procedures, recommend commands, or assemble a review packet. Unless the declared policy grants a narrower automated action, its output remains a recommendation.

The policy plane should be able to return more than allow or deny. stop_missing_evidence, review_required, allowed_with_expiration, and denied_out_of_scope are more useful operating states. A missing policy is not an implicit allow.

5. Projections and operational views

Projections turn message history into useful views: current facility exception state, open inspections, temporary-hours status, unreconciled commands, AI recommendations awaiting review, or facilities with stale source data.

A projection is disposable and rebuildable. It should record its input boundary, projection version, watermark, last successful rebuild, source gaps, and freshness state. If two projections disagree, neither wins because it rendered first.

Separate at least three times:

• occurrence time: when the source says the underlying occurrence happened;
• ingestion time: when the spine received the record; and
• effective time: when an operating rule or commanded state is intended to apply.

Local time still matters for office hours, tenant access schedules, and staffing. Store the facility’s IANA timezone and the original offset-bearing timestamp. Use UTC for comparison and transport; do not discard the local-zone context that determines what “after hours” means.

6. Evidence and reconciliation plane

The evidence plane closes the distance between requested state and observed state. It links the command, receiver acknowledgment, execution record, governing-source readback, visible user-path verification, exception, rollback, and final disposition.

W3C PROV-O offers a durable conceptual model for provenance: entities, activities, and agents, with relationships describing how records were generated, used, derived, or attributed. A facility spine need not implement the entire ontology. It should preserve the same practical questions: what record existed, what transformed it, who or what was responsible, and which new record resulted.

Closure is a claim. It should name the exact evidence that supports it. A queue acknowledgment proves receipt by a queue. A provider response may prove acceptance. A work-order state may prove administrative closure. A fresh governing-source readback or physical inspection may be required to prove the intended operating result.

Four clocks, three identifiers, two kinds of order

Distributed facility work rarely arrives in a clean sequence. A controller may reconnect after a network interruption. A manager may enter an inspection after returning to the office. A provider webhook may arrive before a scheduled source readback. A projection may rebuild while new records continue to arrive.

Design for that reality:

• Event identity: use source plus id to detect a resent event envelope.
• Business idempotency: use a separately governed key for a command whose side effect must occur at most once.
• Aggregate version: use an expected version or sequence when a command must apply only to a known prior state.
• Causal order: preserve the immediate cause even when delivery is delayed.
• Processing order: record when a consumer handled the message without pretending that was when the occurrence happened.

A late record should not automatically overwrite a newer governing state. The consumer should apply a declared rule: ignore for state but retain as evidence, rebuild a bounded projection window, open a conflict, or request human review. “Last message wins” is only valid when the relevant source owner approved that exact rule.

Schema evolution is an operating change

An event contract can be syntactically valid and still change business meaning. Renaming closed to unavailable, changing minutes to seconds, replacing local time with UTC, or expanding a facility-scope field can alter decisions without breaking JSON parsing.

For each message type, govern:

• schema owner and semantic owner;
• schema URI and version;
• backward, forward, or full compatibility expectation;
• field units, enum meaning, null behavior, and default behavior;
• consumer inventory and retirement date;
• projection rebuild requirements;
• privacy and retention impact; and
• rollback or dual-publish window.

CloudEvents dataschema can identify the payload schema and recommends a different URI for incompatible changes. The specification does not define the domain semantics or decide compatibility for the operator. That ownership remains local.

Replay must not become re-execution

Replaying an event history can rebuild a projection, test a consumer, or recover from a processing failure. It should not quietly repeat customer messages, access changes, refunds, public-content changes, vendor dispatches, or other side effects.

Every consumer should declare one of three replay behaviors:

1. Projection-safe: may rebuild derived state without external side effects.
2. Dry-run only: may calculate proposed outcomes but cannot emit commands.
3. Side-effecting: requires a new authorized command through the gateway; historical events alone are insufficient.

Replay records should carry a replay identifier, original envelope reference, reason, operator or service role, bounded range, and destination. The historical occurred_at remains unchanged; the new received_at and replay context explain why the record is being processed again.

Poison messages are operating exceptions

A malformed, unauthorized, unresolvable, or repeatedly failing message should not vanish into a dead-letter queue that only engineers can see. It represents incomplete operating work.

The exception record should preserve:

• safe envelope metadata and payload checksum;
• facility and message type when resolvable;
• failure class and consumer version;
• first and latest failure times;
• retry count and next permitted action;
• accountable owner and response clock;
• whether a business side effect may already have occurred;
• reconciliation requirement; and
• final disposition: corrected, replayed, superseded, quarantined, or unresolved.

Do not copy reusable credentials, gate codes, payment data, raw customer communications, or unnecessary personal data into the exception store. Preserve a protected evidence reference instead. A facility event spine can increase privacy risk by making data easy to distribute; minimization and access boundaries must be designed into the contract.

A fictional three-facility weather incident

The following tabletop is fictional. It describes no real facility, vendor, deployment, customer, or measured result.

A severe-weather bulletin is observed near three demonstration facilities: FAC-DEMO-101, FAC-DEMO-102, and FAC-DEMO-103. The bulletin is an observation. It does not itself close any office, change tenant access, cancel an appointment, or publish new hours.

An AI-assisted workflow extracts the affected area, compares it with the governed facility identity map, and recommends a review packet. One facility is outside the bulletin geometry. One has a current onsite inspection indicating normal conditions. One has no fresh inspection.

The policy plane classifies public-hours changes and access-schedule changes separately. A regional reviewer authorizes a temporary office-hours notice for two facilities, requests an inspection for the third, and does not authorize a tenant-access change. The command gateway emits one command per facility and per requested effect, each with its own expiration, expected prior state, idempotency key, and rollback owner.

The public-content system accepts both notice commands. Acceptance moves each case to accepted_not_verified. A fresh public-page readback confirms one notice, while the other page still shows normal hours. The first facility reaches reconciled_with_expiration. The second opens public_readback_mismatch and remains active. The third stays awaiting_inspection.

A portfolio dashboard can now show three different truthful states instead of one green “weather workflow completed” count. The spine did not make the operating decision. It preserved enough identity, authority, time, command, and evidence to make the decision reviewable.

Where AI helps—and where it must stop

In an event-driven portfolio, AI can usefully:

• classify unstructured observations into a governed candidate type;
• map a claimed location to possible facility references while exposing ambiguity;
• summarize related evidence into a review packet;
• recommend commands that remain behind the authority boundary;
• identify missing fields, stale sources, schema drift, or causal gaps;
• explain why a policy stopped a workflow; and
• help an operator reconstruct an unresolved case.

It should stop when facility identity is ambiguous, a required source is stale or missing, the authority scope is absent, a high-consequence command lacks review, a schema cannot be interpreted, a replay could repeat a side effect, or closure evidence does not match the requested state.

NIST AI RMF 1.0 is a voluntary, rights-preserving, non-sector-specific framework for managing AI risk. Its Govern, Map, Measure, and Manage functions are useful reminders that AI risk is organizational and contextual, not only a model test. It does not certify this architecture or prescribe a self-storage event spine.

Operational queries the spine should answer

Before calling the architecture useful, verify that an operator can answer:

1. Which commands are accepted but not reconciled, by facility and consequence class?
2. Which projections are operating beyond their freshness or completeness threshold?
3. Which events were duplicated, late, out of order, or quarantined?
4. Which commands were denied or stopped, under which policy version and reason?
5. Which AI recommendations reached a command, and which were modified or rejected by a human reviewer?
6. Which replay jobs touched side-effect-capable consumers?
7. Which schema changes still have active consumers on the prior semantic version?
8. Which closed cases lack a governing-source readback or declared limitation?

Counts require definitions. Publish the period, population, numerator, denominator, exclusions, retry and duplicate rules, late-arrival window, and known instrumentation gaps. A message count is not automatically a facility count, occurrence count, command count, or completed-work count.

The release gate

Do not let a facility event spine govern consequential work until:

• stable facility identity and portfolio-scope versioning are in place;
• observation, command, policy decision, projection, and evidence roles are distinct;
• every message type has a technical and semantic owner;
• occurrence, ingestion, processing, and effective times are defined;
• delivery deduplication, business idempotency, and aggregate versioning are separate;
• correlation and direct causation are preserved;
• authority scope, consequence class, review, expiration, and rollback are enforceable;
• schema compatibility includes meaning, units, timezone, nulls, and enum behavior;
• late, duplicate, out-of-order, and poison-message paths are tested;
• replay-safe, dry-run, and side-effecting consumers are labeled;
• sensitive data is minimized before transport and exception storage;
• projections expose watermarks, gaps, and freshness;
• provider acceptance and governing-source reconciliation are separate states; and
• a second operator can reconstruct one case without reading source code.

Run the event-spine tabletop

Download the facility event-spine contract template. It contains six fictional records covering an observation, AI recommendation, policy decision, command, provider receipt, and reconciliation outcome for a demonstration facility within a fictional portfolio.

1. Replace the fictional workflow with one bounded multi-location process.
2. Assign a stable facility reference, message role, semantic owner, and governing policy to every record.
3. Deliver the observation twice. Confirm the envelope is deduplicated without losing the retry evidence.
4. Deliver an older observation after a newer one. Confirm the projection applies its late-arrival rule.
5. Replay the history into a test projection. Confirm no external command can execute.
6. Remove the authority scope from the command. Confirm the gateway rejects it.
7. Return a successful provider receipt and a mismatched governing-source readback. Confirm the case remains open.
8. Change a field’s unit or semantic meaning without changing its name. Confirm the compatibility review blocks release.
9. Quarantine one malformed message. Confirm an operator—not only an engineer—can see the unresolved operating state.

The exercise succeeds when the team can explain what was observed, what was requested, who was allowed to decide, what changed, and what evidence supports the final state.

Sources and limitations

Observed August 22, 2026:

• CloudEvents core specification main branch, titled version 1.0.3-wip when observed, for the vendor-neutral event envelope, required context attributes, occurrence/event distinction, duplicate identity, schema reference, subject, and timestamp semantics.
• AsyncAPI Specification 3.0.0, for protocol-agnostic descriptions of message-driven APIs, including messages, channels, and operations.
• W3C PROV-O, W3C Recommendation dated April 30, 2013, for general provenance concepts and relations.
• NIST Cybersecurity Framework 2.0, published February 26, 2024, for voluntary cybersecurity risk outcomes and governance.
• NIST AI Risk Management Framework 1.0, published January 2023, for voluntary, non-sector-specific AI risk management.

CloudEvents standardizes event context, not delivery guarantees, facility identity, policy authority, or business completion. The observed main specification is work in progress. AsyncAPI describes interfaces; it does not require a topology or determine operating truth. PROV-O is a general ontology, not a self-storage implementation profile. NIST CSF 2.0 and AI RMF 1.0 are voluntary, high-level frameworks; neither certifies this method or defines a self-storage architecture. The facility event spine, field set, state model, and tabletop are proposed here and require local technical, operational, privacy, legal, and security review.

Disclosure

I am Chief Operating Officer of modSTORAGE and CEO and Co-Founder of Facily.ai. This paper is an authored reference architecture. It is not a Facily OS ownership or provider statement, a product-availability claim, a modSTORAGE facility or legal-relationship claim, a customer case study, or a measured performance result.