The Service-Memory Record: Ten Questions Every Useful Guest Memory Should Answer

What makes a guest memory usable?

A usable service memory identifies the person, the source, the applicable situation and what the next authorised colleague needs to know before acting. A label such as “likes late dinner” leaves important questions unanswered: who said it, which guest it concerns, whether it was temporary and whether it is still current.

AFG proposes the record below as a practical inspection model for hotels, cruise lines and aviation. It develops the memory lifecycle into an evidence structure that operators can examine. It is a proposed specification for evaluation, not a certified standard or a claim that every field is already implemented in every GuestMemoryOS deployment.

The evidence behind the design

W3C’s provenance work describes how information about the entities, activities and people involved in producing data helps users assess it. AFG applies that general principle to service: a receiving employee needs enough history to understand a memory’s basis. W3C has not evaluated or endorsed this application. [1]

AFG’s published product workflow connects staff observations, individual guest context, relevant guidance and recorded responses. The operating evidence reports activity within that workflow. This proposed record specifies what should be inspectable when evaluating whether the connection is working correctly. [2] [3]

The record should be as small as the service purpose permits. Its purpose is to preserve meaning and responsibility, not to encourage indiscriminate collection of personal information.

Ten questions the record should answer

These questions describe required context, not ten manual fields every employee must type. Some information may come from authorised system links or the interaction itself. A pilot should measure the complete staff burden, including clarification and review, instead of counting only initial note entry.

A worked record: one request, one occasion

If the passenger then asks to eat immediately, the active request changes. The historical statement remains interpretable through its correction history, subject to the agreed retention rules. On a later flight, the old timing should not silently become a new order.

The equivalent hotel example is a request to delay housekeeping for one afternoon; the equivalent cruise example is an earlier dinner for one family member on one evening. The common requirement is to preserve the situation that made the request meaningful. The operator determines the appropriate review and retention rules.

Preserve meaning across language and role changes

AFG’s product description allows staff to contribute in their working language. An evaluated deployment should check whether the interpretation seen by another role preserves the intended subject, timing and qualification. A fluent summary can still be wrong about who asked or whether the request is temporary. [2]

For a synthetic test, introduce an ambiguous pronoun, a quoted family request and a later correction. Check whether ambiguity stays visible and whether the team seeks clarification at the appropriate point. Do not treat model confidence as proof of the underlying fact.

A proposed memory record should make uncertainty useful: “recipient not yet established” is more actionable than a confidently assigned but unsupported preference. The workflow can then ask a specific question before anyone relies on the attribution.

How to inspect the record without confusing completeness with quality

A record can contain every field and still be wrong. Evaluate it against a checked reference: what the guest stated, the intended subject, the applicable situation and the current service decision. Count eligible records, correctly attributed records, timely handovers and unresolved cases separately.

Then change one condition at a time: the payer, room or seat, receiving colleague, current instruction and permission scope. Check whether the active guidance changes appropriately. Use the quality metrics for denominators and the handover protocol for the receiving-team exercise.

NIST’s AI Risk Management Framework provides general context for evaluating systems and their risks during use. AFG’s ten-question record is an original service-specific proposal, not a NIST requirement or certification. [4]

This sheet makes guest memory reviewable. It explains what the next colleague should be able to inspect and gives an operator a concrete way to assess GuestMemoryOS alongside its existing tools.

Sources and evidence notes

Sources reviewed 25 September 2026. Dated announcements retain their original dates. External sources support the specific contextual claims cited; they do not validate GuestMemoryOS’s performance.

[1] W3C. PROV-Overview, 30 April 2013.

General provenance concepts; the service-memory record is AFG’s proposed application.

[2] AFG Holdings. How GuestMemoryOS works.

Company product description; capture, role-specific guidance and recorded guest response.

[3] AFG Holdings. Operating evidence.

Company-reported residence use and activity. Snapshot: 14 July–21 September 2026. Not an airline outcome study.

[4] NIST. AI Risk Management Framework.

General voluntary risk-management framework; not product certification.

Related AFG research and evidence

• Memory lifecycle
• Guest memory quality metrics
• Service handover protocol