Method and evidence boundary: This is an authored facility-identity control method, not legal, safety, accessibility, postal, mapping, marketing, security, employment, or compliance advice. Every facility, company, person, address, phone number, URL, identifier, hour, source, and result in the examples is fictional. Operators must use approved current sources and qualified owners for real facility facts. Never publish internal contacts, credentials, instructions, access details, or sensitive location data merely because a field exists in a template.

A facility manager should be able to answer a basic question quickly: what is this place, right now?

The answer is harder than it looks.

A website may use one name. A sign may use another. A postal file may normalize the address differently. The facility office may open at 9:00 a.m. while the front gate opens earlier. A holiday exception may supersede the regular schedule. A call-tracking number may appear publicly while the operating team uses a different escalation number. A location may be open to current tenants but not staffed for walk-in service.

None of those facts belongs in a manager’s memory alone.

The one-page facility fact sheet is a current operating record that separates identity, public information, internal routing, hours, lifecycle, and provenance. It is not a brochure and it is not a data dump. It is the smallest record from which a manager can explain a facility without guessing.

Start with a stable facility identity

Names, addresses, and phone numbers change. A stable internal facility ID should not.

The first line of the sheet should contain:

• facility_id — a durable portfolio identifier;
• fact_sheet_version — the exact record version;
• effective_at — when the version became authoritative for its stated scope;
• reviewed_at — when a named owner last checked it;
• next_review_at — the scheduled review point;
• current_state — current, change_pending, conflict_open, temporarily_closed, retired, or another approved state.

The facility ID is a correlation key, not an ownership claim. It should connect work orders, content, local listings, maps, analytics, access systems, customer messages, vendor records, and financial workflows without forcing those systems to share one mutable name.

The version matters because a fact sheet without a version cannot be cited. “Use the facility fact sheet” is ambiguous if three copies exist and no one knows which is current.

Block 1: identity names

Keep different kinds of names in different fields.

• Customer-facing name: the approved name used for current public-facing operations.
• Sign name: the name visible at the physical location, with a dated source.
• Internal portfolio name: the operating label used in internal systems.
• Platform display name: the exact name approved for a particular external platform.
• Legal-entity name: include only when a qualified source owner approves its operational use.
• Prior or alias name: historical reference, never silently presented as current.

Do not infer a legal owner, operator, manager, franchise, provider, or brand relationship from a shared name, email domain, website link, map pin, or software record.

Current Google Business Profile guidelines instruct businesses to represent their real-world name consistently and to place address, hours, and categories in their appropriate fields rather than stuffing them into the name. Those are mutable Google-product rules, not a universal identity standard. The useful operating lesson is to store a plain current name with its source and keep marketing language elsewhere.

Block 2: physical and postal location

One address string is not enough.

Record:

• address line 1;
• address line 2 where applicable;
• city or locality;
• state or region;
• postal code;
• country code;
• validated mailing format and validation date;
• public display address;
• map-pin coordinates, precision, source, and review date;
• customer-facing arrival note, if approved;
• entrance or office-location note, if approved;
• address-conflict state and owner.

The physical operating location, mailing address, legal address, map pin, parcel, and emergency-service location may be related. They are not automatically the same record.

The October 2024 edition of USPS Publication 28 describes complete, standardized U.S. mailing-address elements and address-list maintenance. Its scope is postal addressing. A standardized mailing address does not prove who owns a property, where a customer should enter, whether a map pin is accurate, or whether a business is operating there.

The current Schema.org PostalAddress vocabulary similarly exposes separate address components. That can help a website mirror an approved fact record, but vocabulary fields do not validate the address or authorize its publication.

Block 3: contact channels

For each contact channel, record both the value and its purpose.

Public fields may include, when approved:

• main customer phone;
• public email or contact URL;
• canonical facility webpage;
• approved rental or account-support route;
• accessibility contact route;
• after-hours customer-support route.

Internal fields may include:

• responsible facility role;
• regional escalation queue;
• vendor-routing queue;
• data-correction owner;
• outage or incident route.

Do not publish a personal number, private email, security contact, emergency instruction, employee name, credential, alarm detail, access-control topology, or vendor escalation simply because it helps internally.

A phone number also needs lifecycle state: current, forwarded, migration_pending, retired, unverified, or conflict_open. A call that rings does not prove it reaches the intended facility or that the response is correct.

Google’s current guidelines state that a listed phone should connect to the actual business and remain under the business’s direct control. That is a platform-specific rule. The broader control is to test the customer route, record the result and time, and keep technical connection separate from confirmed operational handling.

Block 4: hours without ambiguity

“Hours” is not one field.

Self-storage operations may need to distinguish:

• office hours;
• gate-access hours;
• phone-support hours;
• rental-service hours;
• appointment-only windows;
• vendor or delivery windows;
• temporary or seasonal changes;
• holiday exceptions;
• closures and reopening times.

Google’s current business guidelines specifically say storage facilities should use office hours, or otherwise front-gate hours, for the primary Business Profile hours. That does not mean office and gate hours are interchangeable inside the operating record. The fact sheet should show both and label which schedule each external surface is intended to receive.

Store a named time zone, not only an offset. The IANA Time Zone Database is periodically updated when political bodies change boundaries, offsets, or daylight-saving rules. Its current page lists release 2026c from July 8, 2026. A time-zone identifier helps software calculate local time, but it does not prove the facility’s schedule is current.

For every hours set, preserve:

• schedule type;
• days and local open/close times;
• time-zone identifier;
• effective and end dates;
• special-hours overlay;
• source owner;
• last verification;
• next review;
• public or internal classification.

The current Schema.org OpeningHoursSpecification vocabulary provides fields for days, opening and closing times, and valid-from or valid-through dates. It is a representation vocabulary, not a source of truth. Structured markup should be generated from the approved sheet, not edited as an independent schedule.

Block 5: lifecycle and operating state

A facility can be physically present while its operating state changes.

Use an approved vocabulary such as:

• pre_opening;
• open;
• office_temporarily_closed;
• access_limited;
• temporarily_closed;
• transition_pending;
• closing;
• closed;
• sold_or_transferred_unclassified;
• unknown.

The labels must be defined by the responsible owners. Do not infer a sale, management relationship, legal closure, operational control, or customer-access consequence from a listing change or a website disappearing.

Lifecycle state should include:

• observed fact;
• effective time if known;
• source and authority;
• customer-facing consequence approved for communication;
• open dependencies;
• next verification time;
• responsible owner.

“Sold or transferred unclassified” is deliberately cautious. It records that a transition may exist without claiming its legal form or operating relationship.

Block 6: public claims and operational features

A fact sheet should list only features that have an approved current source.

Examples might include:

• unit types;
• customer-access method;
• office or gate presence;
• climate-related wording;
• vehicle-storage availability;
• delivery acceptance;
• security or monitoring language;
• accessibility features;
• payment methods;
• insurance or protection-plan language.

Each feature needs a state: verified_current, verified_with_limitations, change_pending, not_offered, unknown, or do_not_publish.

Do not copy features across facilities. Do not promote a vendor capability into facility availability. Do not turn a technical component into a safety guarantee. Do not describe a feature as accessible, climate controlled, secure, monitored, available, included, or approved without the qualified source and exact permitted wording.

Schema.org’s current SelfStorage type offers a machine-readable vocabulary for a self-storage facility and inherited place or local-business properties. Its page identifies itself as the development version. Markup can mirror an evidence-cleared facility record; it does not prove ownership, profile eligibility, search inclusion, ranking, or rich-result display.

Block 7: source and change control

Every public or consequential field should answer six questions:

1. What is the exact value?
2. Which source supplied it?
3. Who has authority over that source?
4. When was it observed and when did it become effective?
5. What conflicts or limitations remain?
6. Who owns the next review or correction?

The pinned W3C PROV-O Recommendation defines general concepts for entities, activities, agents, generation, use, derivation, attribution, association, and delegation. Those concepts can link a facility fact to a source and update activity. Provenance does not prove the fact true or the source authorized. It makes the claim chain inspectable.

When two sources disagree, do not choose the newest automatically. The official facility page may lag an approved temporary closure. A listing may contain a pending change. A manager may know a fact but lack publication authority. Resolve the conflict through the source-owner map and preserve the prior value, proposed value, reason, evidence, decision, effective time, and rollback.

Block 8: destination synchronization

The fact sheet is upstream of many destinations. It should record which ones received which version.

Possible destinations include:

• facility website;
• portfolio location page;
• structured data;
• customer messaging templates;
• map or business profiles;
• rental platform;
• call routing;
• internal directory;
• vendor work-order system;
• access or building systems;
• emergency or continuity documentation.

For each destination, track:

• source fact-sheet version;
• intended fields;
• adapter or manual workflow;
• submission or change time;
• sender or operator identity;
• receipt state;
• accepted or review state;
• applied state;
• public readback state;
• current discrepancy;
• rollback action.

Submission is not acceptance. Acceptance is not application. Application is not public readback. Public readback is not search indexing or ranking.

What AI can safely do

AI can help maintain the sheet when its contribution remains visible. It may:

• extract candidate facts from approved sources;
• compare the current sheet with destination readbacks;
• flag stale, missing, or conflicting values;
• normalize a draft address while preserving the source string;
• calculate candidate holiday overlays from an approved schedule;
• draft a correction packet;
• identify destinations still carrying an older version;
• explain a discrepancy in plain language.

AI should not:

• invent a facility relationship;
• infer a feature from another location;
• decide which source has authority;
• publish a corrected address, phone, or hours value;
• classify a legal or operating transition;
• turn an unknown into a current fact;
• expose an internal contact or sensitive operating detail;
• treat a successful API response as a verified public result.

Keep AI output labeled candidate until a qualified source owner admits it into the fact sheet.

A fictional one-page example

Fictional Alder Annex uses FAC-FICTION-ALDER-01 as its stable identity. Version 18 is current.

The customer-facing name and sign name agree. The USPS-formatted mailing address and the public display address contain the same core elements, but the arrival note identifies a different customer entrance. The office schedule is Monday through Saturday; the gate schedule is broader. Both use America/Denver, and a date-bounded holiday overlay is attached.

The main phone passed a technical connection check. Operational handling is awaiting a separate sample, so its state is connected_handling_unverified. The website and one listing display version 18. A second listing still displays version 17 and has an open correction record. One advertised feature remains unknown because the source owner has not approved the wording.

The sheet does not resolve that uncertainty by guessing. It tells the manager what is known, what is not, where the discrepancy exists, and who owns the next action.

No part of the example proves a real facility, product, listing, profile, feature, or operating result.

The manager’s five-minute test

Choose one facility and open the current fact sheet.

In five minutes, a manager should be able to answer:

1. Which facility identity and version am I using?
2. What customer-facing name, address, phone, website, office hours, and gate hours are current?
3. Which fields are public, internal, unknown, conflicting, or held?
4. Which source and owner support each consequential field?
5. Which destinations still disagree, and who owns each correction?

If the answer depends on memory, an old email, a search result, or “what the other site uses,” the facility does not yet own its identity.

Use the companion one-page facility fact-sheet template, 10-row fictional facility identity register, and 36-case readiness suite to create the first governed version. The facility fact-sheet anatomy provides a visual walkthrough. Keep the sheet compact enough to use and structured enough to verify. The value is not the page count. The value is that every important fact has a source, a state, and an owner.

Sources

The package-level source register records the date, exact claim supported, and limitations for every official source used below.

• Guidelines for representing your business on Google, Google Business Profile Help, current mutable page checked August 22, 2026.
• Publication 28: Postal Addressing Standards, United States Postal Service, October 2024 edition.
• Time Zones, IANA, current page checked August 22, 2026; latest listed release 2026c from July 8, 2026.
• SelfStorage, Schema.org current development vocabulary checked August 22, 2026.
• PostalAddress, Schema.org current development vocabulary checked August 22, 2026.
• OpeningHoursSpecification, Schema.org current development vocabulary checked August 22, 2026.
• PROV-O: The PROV Ontology, W3C Recommendation, April 30, 2013.

The post The One-Page Facility Fact Sheet Every Manager Should Own first appeared on modSTORAGE | Blog.

Method and evidence boundary: This is an authored customer-message control method, not legal, privacy, accessibility, advertising, collections, emergency, safety, or communications advice. Every customer, facility, employee, vendor, message, account, transaction, amount, date, channel, source, and outcome in the examples is fictional. Qualified owners must define applicable law, policy, consent, recipient scope, content, accessibility, channel, timing, retention, review, and escalation requirements before any real message is sent.

An AI draft is not a customer message.

It is proposed language generated from an input context. Before it becomes communication, an operator must be able to show which claims it contains, where those claims came from, when they were true, who had authority to release them, what the recipient may reasonably do because of them, and what happens if the message is wrong.

That proof should travel with the draft.

Without it, human review becomes a writing critique. The reviewer checks whether the message sounds professional while the important questions remain hidden: Is the facility actually closed? Is the amount current? Is this the right customer? Is the offered action available? Is the deadline approved? Is the channel permitted? Is a correction possible?

The release gate must inspect the message as an operating action, not a paragraph.

Begin with a message identity

Every proposed message needs a stable identity before review.

Record:

• message_id and version;
• message class and approved purpose;
• facility and legal-entity scope where applicable;
• recipient population definition;
• customer or account identifiers in a protected system, not the public review copy;
• requested channel;
• requested send window and time zone;
• consequence tier;
• drafting actor and AI-system contribution;
• current owner and next action.

Version the message whenever a claim, recipient rule, date, amount, action, link, template, source, or consequence changes. Grammar-only edits may follow a lighter rule if the qualified owner approves one, but they still need a traceable disposition.

“Final draft” is not a useful state. Use candidate, source_incomplete, review_ready, returned, approved_for_queue, queued, provider_accepted, delivery_reported, delivery_failed, recipient_response_received, corrected, withdrawn, or another approved vocabulary.

The ten-part release packet

The reviewer should see ten blocks beside the message.

1. Audience and recipient rule

Define who is intended to receive the message and who must not.

The rule might reference:

• a specific facility;
• an approved account state;
• a lease or transaction relationship;
• a service request;
• a preference or consent state;
• language or accessibility needs;
• a time-bounded event;
• explicit exclusions and suppression lists.

Do not paste a raw customer list into an AI prompt or review packet merely because the system can accept it. Use the minimum protected identifiers necessary for the approved workflow.

The population query needs a version, source, cutoff time, owner, and row count. A saved list can become stale between review and send. If the population is rebuilt, the message release must decide whether the prior approval still applies.

2. Purpose and allowed action

State what the message is intended to accomplish.

Examples include:

• confirm receipt of a request;
• announce approved office-hour changes;
• request missing information;
• provide an approved service update;
• explain a bounded transaction state;
• route the recipient to an approved support channel.

Also state what the message may not do. A service update may not create a payment promise. A receipt confirmation may not claim completion. A general reminder may not become an account-specific determination. A safety-related draft may not be released without the authority and source rules defined for that consequence.

3. Claim ledger

Break the draft into claims rather than reviewing it as one block.

For each sentence or material phrase, record:

• claim ID;
• exact text span;
• claim type: identity, status, amount, date, time, feature, obligation, availability, instruction, link, contact, or another approved class;
• source record and field;
• source owner;
• observed and effective times;
• freshness horizon;
• transformation from source to wording;
• limitation or uncertainty;
• release disposition.

The ledger may reveal that one sentence contains four separate claims. “Your refund has been completed and should arrive within three days” contains at least a transaction identity, completion state, future receipt implication, and time estimate. One provider response may support only one of them.

The current FTC advertising and marketing guidance states at a high level that advertising claims must be truthful, non-deceptive, non-unfair, and evidence-based, and notes that specialized rules may apply. That is general federal business guidance, not a determination that a particular facility message is advertising or lawful. The bounded operating lesson is straightforward: do not release claims that outrun their evidence.

4. Source and freshness packet

The release packet should show the exact sources used to build the message.

For each source, include:

• system and record identity;
• source version;
• field names;
• source authority;
• observed time;
• effective time;
• current read state;
• freshness rule;
• conflict state;
• access or retrieval error;
• approved citation or internal locator.

Never treat a source read failure as confirmation of the last known value. Use unknown_source_unavailable or another explicit state. A cached fact may remain usable under an approved horizon for a low-consequence message, while a consequential account, facility, payment, or access statement may require a fresh authoritative read.

The pinned W3C PROV-O Recommendation defines general relationships among entities, activities, agents, generation, use, derivation, attribution, association, and delegation. Those concepts can link a message claim to a source and drafting activity. Provenance does not prove that the source is true, current, authorized, or sufficient. It makes the chain inspectable.

5. Authority and reviewer scope

The release packet must name who may approve this message class for this facility, entity, population, channel, and consequence.

Record:

• policy or procedure reference;
• message owner;
• source-owner approvals;
• content reviewer;
• privacy or legal review where required;
• operational authority;
• channel authority;
• segregation rule;
• approval expiry;
• exception authority.

Access to a composer or campaign tool is not publication authority. A facility manager may be authoritative for today’s office hours but not for a financial amount, lease interpretation, accessibility determination, emergency instruction, or marketing claim. Authority is claim-specific.

The NIST AI RMF 1.0 is a voluntary, non-sector-specific framework. It supports a governed, documented, role-aware approach across the AI lifecycle. NIST states that the framework is under revision. It does not approve a message or certify a review process.

The mutable NIST AI RMF Playbook includes voluntary suggestions for differentiating human-AI roles, documenting oversight, and tracking risk information. It is not a universal checklist. The practical lesson is to show the reviewer where AI contributed and where a qualified human decision is required.

6. Consequence and correction plan

Classify what could happen if the message is wrong, late, incomplete, inaccessible, sent to the wrong population, or acted upon literally.

A proposed tiering model might consider:

• informational inconvenience;
• customer effort or missed service;
• account or financial consequence;
• access or physical consequence;
• privacy exposure;
• deadline or rights consequence;
• safety or emergency consequence;
• irreversible or difficult-to-reverse action.

The method does not assign universal tiers. Qualified owners do.

For the chosen tier, define:

• required sources and reviewers;
• allowed channels;
• send-window limits;
• preview and test-send requirements;
• pause or cancel control;
• correction template;
• affected-population reconstruction;
• support and escalation owner;
• incident and retention record.

A correction plan should exist before release, not after a mistake.

7. Privacy and data minimization

Show which personal or account data enters the drafting, review, queue, provider, log, and archive stages.

For each field, record:

• purpose;
• minimum necessary representation;
• protected-system locator;
• whether AI can access it;
• masking or tokenization rule;
• channel exposure;
• retention and deletion rule;
• access owner;
• incident path.

The NIST Privacy Framework 1.0 is a voluntary enterprise risk-management tool and explicitly lacks the force of law. It recognizes that data processing can create consequences for individuals and organizations. It does not prescribe consent, retention, or message content. The bounded lesson is to manage the privacy consequence of the data flow, not only the text that reaches the customer.

Do not copy customer data into an evidence package intended for broad internal access. The review packet can show population logic, protected locators, counts, and masked examples without duplicating the recipient file.

8. Channel and delivery semantics

Each channel has different technical and operating states.

For email, text, portal, app, phone, printed mail, or another approved channel, distinguish:

• content approved;
• population approved;
• queued;
• accepted by a provider;
• delivery reported;
• delivery failed;
• opened or viewed when such data is approved and meaningful;
• recipient responded;
• recipient action completed;
• corrected or withdrawn.

Provider acceptance is not delivery. Delivery is not reading. Opening is not comprehension. A response is not acceptance of the message’s claim. A completed action needs its own authoritative record.

The channel packet should show sender identity, reply route, link destinations, expiration, unsubscribe or preference treatment where applicable, provider-specific limitations, and the owner of failures.

9. Accessibility and comprehension

The message and its action path should remain usable across supported channels.

Review:

• plain and specific subject or opening;
• clear facility identity;
• readable dates, times, currency, and time zone;
• descriptive link names;
• text alternatives for meaningful non-text content;
• logical heading and reading order;
• sufficient contrast in rendered templates;
• zoom and mobile layout;
• keyboard and screen-reader behavior for linked actions;
• language and translation ownership;
• a reachable help route.

The pinned WCAG 2.2 Recommendation contains testable criteria for accessible web content, including text alternatives, perceivable information, understandable operation, and compatible controls. A message may span non-web channels, and testing selected criteria is not a full conformance or legal-compliance claim. Use the standard where applicable and verify the complete recipient path.

10. Final disposition

The final reviewer should return a structured disposition:

• approved_for_exact_queue;
• approved_with_expiry;
• returned_for_source;
• returned_for_population;
• returned_for_wording;
• returned_for_accessibility;
• returned_for_authority;
• denied;
• withdrawn.

The record should name the approved message version, recipient-query version, channel, send window, reviewer, authority scope, reason, limitations, and expiry. Any change to those items may require a new review.

A fictional message review

Fictional Cedar Loop Storage prepares this AI draft:

The office will be closed Monday. Your gate access is unchanged. Call us at the number below if you need help.

The release packet separates three claims.

Claim 1: office closure
An approved special-hours record supports the office closure for the exact date and facility. State: source_current.

Claim 2: gate access unchanged
The gate schedule source was last verified before a recent system change and is outside its freshness horizon. State: unknown_source_stale. The sentence is held.

Claim 3: support phone
The number passed a technical connection test, but operational handling is not verified for the closure window. State: connected_handling_unverified. The reviewer must use an approved route or return the message.

The AI draft is not rejected because AI wrote it. It is returned because two material claims lack the evidence required for release.

No part of this fictional review proves a real facility schedule, access state, phone route, message, or customer outcome.

What AI may and may not do

AI may:

• draft language from an approved fact packet;
• extract candidate claims from its own draft;
• link candidate claims to supplied sources;
• flag missing dates, amounts, time zones, contacts, and limitations;
• compare a draft with an approved template;
• generate plain-language alternatives;
• propose accessibility and mobile checks;
• summarize reviewer changes;
• prepare a correction draft after a governed incident.

AI should not:

• select recipients;
• infer consent or channel eligibility;
• decide source authority;
• fill missing account, facility, or transaction facts;
• invent a deadline, amount, feature, status, or promise;
• approve its own message;
• send, schedule, or publish without the exact authorized gate;
• treat provider acceptance as delivery or customer action;
• decide that a message is legally compliant or accessible in every context.

The NIST Generative AI Profile, AI 600-1, is a voluntary cross-sector companion to AI RMF 1.0, published July 26, 2024; its page was updated April 8, 2026. It supports identifying and managing generative-AI risks across design, development, use, and evaluation. It does not prescribe this release packet or validate a particular AI system.

The operator exercise

Choose one recurring message class and sample ten recent drafts or sends using approved protected records.

For each item, answer:

1. Which exact message and recipient-query versions were used?
2. What claims did the message make?
3. Which source supported each claim, at what time?
4. Which claims were unknown, stale, conflicting, or transformed?
5. Who held authority for the source, message, population, and channel?
6. What could happen if the message was wrong?
7. Which personal data crossed each system boundary?
8. What accessibility and comprehension checks were performed?
9. What did the provider report, and what did it not prove?
10. Could the team pause, correct, and reconstruct the affected population?

Use the companion human-review template, review-packet template, and readiness suite to test ordinary, stale-source, wrong-facility, duplicate, inaccessible, high-consequence, provider-failure, correction, and AI-assisted cases. The release-chain diagram gives teams a compact visual for training and tabletop review.

The release question

Before a message leaves the facility’s control, the reviewer should be able to say:

I know what this message claims, where each claim came from, when it was true, who may release it, who should receive it, what the channel can prove, and how we will correct it if it is wrong.

If the packet cannot support that sentence, the draft is not ready to send—no matter how polished it sounds.

Sources

The companion source register records source owner, publication or version date, retrieval date, durable locator, claim supported, limitation, and provenance note.

• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, NIST, published July 26, 2024; page updated April 8, 2026.
• Artificial Intelligence Risk Management Framework 1.0, NIST, January 26, 2023; current page checked August 22, 2026 and notes the framework is under revision.
• NIST AI RMF Playbook, NIST AI Resource Center, mutable companion checked August 22, 2026.
• NIST Privacy Framework 1.0, NIST, January 2020; current page checked August 22, 2026.
• Web Content Accessibility Guidelines 2.2, W3C Recommendation, December 12, 2024.
• Advertising and Marketing, Federal Trade Commission business guidance, current page checked August 22, 2026.
• PROV-O: The PROV Ontology, W3C Recommendation, April 30, 2013.

The post What an AI-Drafted Customer Message Must Show Before It Is Sent first appeared on modSTORAGE | Blog.