Some features cannot run in guest mode because they need a durable identity

What it is

Some acts are bound, in mechanism, to “this will still be the same person tomorrow”: continuing a thread across devices, granting rights to someone else, paid entitlements, legal liability, accountability after a report. Unavailable in guest mode means those acts stay closed without a durable identity, and the entry explains that identity is missing—not that the feature is broken. This entry draws the feature boundary. It does not encourage guest mode to fake them, and it does not treat the boundary as an excuse to lock all core experience—core experience belongs on the guest-mode leaf.

Why it happens

A durable identity supplies a stable primary key, an accountable contact channel, and recoverable credentials. Without those three, a share link survives on someone else’s device after this one is wiped, refunds cannot find a contracting party, and abuse cannot be handled. If the product “does them anyway” as a guest, promises cannot be kept, and the debt surfaces at registration or complaint. The line should follow identity semantics, not conversion: what needs a durable identity is “give a colleague edit rights on this piece,” not “finish using the filter.” Lock the latter and guest mode is a name only; open the former and the system keeps objects it cannot govern.

Studying it

Split the catalog into “must have durable identity” and “guest-ok,” let people try both kinds of entry as guests, and see whether closure is understood and whether high-risk acts leak through.

Independent variables: how closure is presented (disabled with reason, register after tap, pretend-to-work then fail halfway), whether the split is public. Dependent variables: attribution of “why I cannot,” treating closure as a bug, guest completion of acts that should have been closed.

Do not use “guest conversion” as quality of the split. Trust and safety work should try to finish share-grants, payment, and reports as a guest and see whether the system actually blocks. Disputes over classification should be arbitrated with written tests (stable key? accountable channel?), not opened privately against growth metrics.

Where it stops holding

If regulation allows guest checkout with a one-shot contact for fulfillment, settlement can skip a full account—but that is a one-shot contract identity, still not a durable account to come back to; the UI must not read “you are registered.” Read-only consumption of public content almost never needs a durable identity; locking it behind login is a registration wall, not this boundary. Enterprise SSO has no guest; this card does not apply. Features change class across versions; the closed list must share a source with capability flags in code.

Applying it

• Label features with a written rule: guest-writable / guest-read-only / needs durable identity. Identity-needed entries stay visible but closed in guest, with copy that says “an account is required to remember the recipient or the responsibility,” plus sign-up now.
• Do not let guest finish payment that changes rights, cross-device grants, or moderation of others’ content; refuse on the server, not only by hiding a button.
• Do not mark filters, reading, or a one-shot calculation as identity-needed when they have no durable semantics.
• Verify: take the identity-needed list and call those APIs with a guest token; all should refuse. Tapping those entries in the UI should show an identity reason, not a generic error. Take the core-experience list and confirm they still complete as a guest; the boundary must not swallow the product.

Related

• Within the group: H6.09.1 Guest mode lets people try core features before registering · H6.09.2 Guest data must merge cleanly after registration · H6.09.3 Guest data retention must be stated
• Adjacent: H6.01 Registration friction · H4.03 Degradation after denial
• Search terms: durable identity · guest feature gating · accountability