v0.1 Draft: Private Session Surfaces for Language-User Interfaces

Summary

This is a public draft, not a final standard. It defines an interaction contract for a class of applications that are already emerging: language-user interfaces where natural-language conversation coordinates structured visual and interactive surfaces. The protocol is called the Session-Surface Protocol, or SSP, and v0.1 defines one primitive: the private session surface.

If you are not planning to implement the protocol, the next 1,000 words are written for you. They explain what SSP is, what v0.1 does, what v0.1 deliberately does not do, and why those choices matter. The full specification follows. Implementers should read both. Non-implementers can stop after this section and still understand what is being argued.

What SSP is

SSP defines how consequential actions on private conversational surfaces remain valid, expire, refresh, recover, and stay scoped to the user and session that created them. The narrower frame matters. Action validity inside a drift-prone session is the wedge. Surface lifecycle, access scoping, and the surface-artifact distinction all serve that wedge.

The protocol is designed for applications where conversation and structured interface elements work together — appointment booking, document approval, commerce, workflow automation, customer support, incident response, data analysis, agent orchestration, and other interaction patterns where chat alone is insufficient but page-based navigation is no longer the natural center.

SSP treats the conversational session as the organizing primitive. Surfaces are structured instruments rendered inside that session. They may display information, collect input, support comparison, request consent, or invoke actions against external systems. SSP does not specify what surfaces look like or how they are rendered. It specifies how they live, how long their actions remain valid, what happens when they expire, how they recover from execution failures, and how they enforce private access.

The most important rule in v0.1 is that a surface may persist inside a session, but the world it depicts may drift. Therefore, any action declared on a surface must be time-bounded. SSP calls that time boundary an action window. Within the window, the action may fire. Outside the window, the action expires and must be refreshed against current world state before it can fire again.

What v0.1 deliberately does not do

SSP v0.1 defines the private session surface and stops there. A private session surface is created inside a session, belongs to that session, is available only to the authenticated user in that session, and is destroyed when the session ends or the surface is retired. It is not shareable. It is not bookmarkable. It is not citable. It is not archival. It is not persistent beyond its session.

That boundary is intentional, and the reason matters. Shareable durable surfaces are a different primitive, not a private surface with a share button added later. Sharing introduces consent, revocation, durability, citation, archival, identity, permission, and social convention. Each of those concerns has design pressure that conflicts with the optimization targets of a private session surface. A protocol that tried to handle all of these in one primitive would compromise all of them.

The page primitive in the graphical web bundled many properties together: interaction, addressability, durability, sharing, citation, and archival. That bundle was powerful. It also hid trade-offs that are now showing up at scale, particularly around who controls memory and what gets remembered for whose benefit. The session era should not inherit that bundling by default. It should design separate primitives for separate concerns and let them compose where composition serves the user.

SSP v0.1 therefore defines the simpler primitive first. Shareable durable surfaces are future work. They are described in §12 as a separate primitive with separate design pressures, and a future version of SSP will define them with the care they deserve.

Why this matters

The conversational era is in its early-nineties moment. Every major AI product is inventing its own version of memory, state, tools, surfaces, permissions, context, and persistence. None of it interoperates. Users are accumulating context inside whichever vendor's system they happen to use, and that context is increasingly the substrate of how they work. If the conversational era follows the page era's path, shared primitives will eventually emerge. If it does not, fragmentation will harden into a set of incompatible proprietary substrates, and the convergence that made the web possible will not happen for the conversational era.

SSP is a proposal for one piece of what shared primitives could look like. It is not the only such proposal that will or should emerge. It is a serious attempt to make the architectural argument concrete enough to implement, debate, and improve.

The companion essay, After the Page, makes the case for why the session is becoming the organizing primitive of the conversational era. SSP makes the case for what rules private surfaces inside that session should follow.

What the protocol commits to

Three commitments shape every decision in this draft.

Session over URL. The organizing unit is the ongoing conversational interaction, not the addressable document. SSP does not claim that pages disappear. It claims that, for this class of application, the session becomes the primary unit of interaction.

Separation over false unification. Private interaction surfaces, durable artifacts, and public citable surfaces are not the same thing. Treating them as one primitive with different flags risks compromising all of them. SSP v0.1 separates the private primitive from future shareable durable surfaces and refuses to bundle them.

Humane over machine-tidy. When clean machine state and humane user experience diverge, SSP favors the human. Users should not be punished because a network round-trip completed a few milliseconds after a countdown elapsed. Users should not watch a button silently mutate beneath them because the system decided to refresh state on its own. Users should not be stranded inside a broken surface when an action fails for reasons they cannot see. The action window, the tap-down intent rule, refresh-on-request, and conversational failure handoff all follow from this stance.

How to read what follows

The full specification is organized as twenty sections. Sections 1 through 5 cover what SSP is, what it is not, the design stance, key terms, and the explicit scope of v0.1. Sections 6 through 11 specify session lifecycle, surface lifecycle, action windows, execution failure handoff, access scoping, and chat-surface choreography. Section 12 describes the future shareable durable surface primitive and explains why it is out of scope for v0.1. Sections 13 through 16 contain four worked examples — appointment booking, document approval, generated artifact preview, and incident response — that illustrate the protocol's mechanics in realistic flows. Section 17 summarizes the normative MUST and SHOULD requirements. Section 18 names the open questions for v0.1 review. Section 19 is the changelog. Section 20 names the channels for feedback.

Implementers should read all of it. Reviewers focused on the architectural argument can read sections 1 through 5 plus section 12 and the worked examples in 13 through 16. The requirements summary in section 17 is the index for compliance work.

This is a draft. The protocol is meant to improve through public review, implementation, and pushback. Comments, objections, and counter-proposals are welcomed in the comment thread on this spec's post; see §20 for the rationale and channels.

1. What SSP is

SSP defines how consequential actions on private session surfaces remain valid, expire, refresh, recover, and stay scoped to the user and session that created them. Action validity inside a drift-prone session is the wedge.

It is designed for applications where conversation and structured interface elements work together: appointment booking, document approval, commerce, workflow automation, customer support, incident response, data analysis, agent orchestration, and other interaction patterns where chat alone is insufficient but page-based navigation is no longer the natural center.

SSP treats the conversational session as the organizing primitive. Surfaces are structured instruments rendered inside that session. They may display information, collect input, support comparison, request consent, or invoke actions against external systems.

The most important rule in v0.1 is this: a surface may persist inside a session, but the world it depicts may drift. Therefore, any action declared on a surface must be time-bounded.

SSP calls that time boundary an action window.

2. What SSP is not

SSP is deliberately narrow.

It is not a rendering specification. It does not prescribe visual design, component libraries, layout systems, or UI frameworks.

It is not a transport specification. It assumes but does not define the underlying session-state store, messaging protocol, authorization system, or authentication mechanism.

It is not a model-orchestration specification. It is agnostic to which language models, agents, tools, or pipelines generate surfaces and conversational turns.

It is not a replacement for URLs, documents, or durable web resources. Public knowledge still needs durable, addressable artifacts. Journalism, law, science, commerce, documentation, and institutional memory all depend on things that can be cited, shared, archived, disputed, and returned to.

It is not a shareable-surface specification. v0.1 surfaces are private and ephemeral by design. They do not leave the session.

SSP defines a first primitive for the conversational era: the private surface inside the session.

3. Design stance

Three commitments shape this draft.

3.1 Session over URL

The organizing unit is the ongoing interaction, not the addressable document.

In the graphical web, the user moved from page to page. In language-user interfaces, the user often remains inside a continuous conversational session while the application renders temporary surfaces as needed.

SSP does not claim that pages disappear. It claims that, for this class of application, the session becomes the primary unit of interaction.

3.2 Separation over false unification

The page bundled many things into one primitive: interaction, addressability, durability, sharing, citation, and archival.

That bundle was powerful. It also hid trade-offs.

In the session era, those properties should not be assumed. A private interaction surface, a durable artifact, and a public citable surface are not the same thing. Treating them as one primitive with different flags risks compromising all of them.

SSP v0.1 therefore separates private session surfaces from future shareable durable surfaces.

Private session surfaces are optimized for privacy, freshness, trust, and action.

Shareable durable surfaces will need to be optimized for stability, addressability, consent, citation, integrity, and long-term meaning.

Those are different design centers. They deserve different primitives.

3.3 Humane over machine-tidy

When clean machine state and humane user experience diverge, SSP favors the human.

This is not decorative language. It determines protocol behavior.

Users should not be punished because a network round-trip completed a few milliseconds after a countdown elapsed. Users should not watch a button silently mutate beneath them because the system decided to refresh state on its own. Users should not be stranded inside a broken surface when an action fails for reasons they cannot see.

The action window, the tap-down intent rule, refresh-on-request, and conversational failure handoff all follow from this stance.

4. Key terms

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119.

Language-user interface

An application interface in which natural language is a primary mode of user intent, coordination, and state continuity, often combined with structured visual or interactive surfaces.

SSP is designed for language-user interfaces. The conversational session is the organizing primitive; surfaces are structured instruments rendered inside that session.

Session

A bounded period of conversational interaction between a user and an SSP-speaking application.

A session has a beginning, a conversational history, a state store, and a termination event. Private session surfaces exist within a session and cannot outlive it.

Private session surface

A structured, rendered instrument inside a session.

A private session surface may be a form, table, selector, preview, approval flow, data view, comparison tool, decision instrument, or other interface object generated in response to conversational intent.

It is private to the authenticated user. It is scoped to the session. It is destroyed when the session ends or the surface is retired. In v0.1, private session surfaces MUST NOT persist beyond their session, MUST NOT be shareable, MUST NOT be bookmarkable, MUST NOT be citable, and MUST NOT be archival.

For readability, this draft often uses surface as shorthand for private session surface.

Shareable durable surface

A future primitive, out of scope for v0.1.

A shareable durable surface would outlive the session that created it and would be designed for some combination of sharing, citation, archival, public access, or long-term reference.

This is not treated as an extension of the v0.1 surface. It is a separate primitive with its own lifecycle and semantics.

Artifact

A durable object that may be created, edited, displayed, or referenced through a surface but is not itself a v0.1 surface.

Examples include documents, reports, files, records, images, dashboards, saved plans, tickets, invoices, calendar events, and other application-defined objects.

This distinction is important. SSP v0.1 defines the lifecycle of private session surfaces, not the lifecycle of durable artifacts. A surface may be destroyed when a session ends while an artifact created through that surface persists under its own application-defined rules. The relationship between surfaces and artifacts is specified in §7.4.

Action

An invocable operation declared on a surface that mutates world state, commits user intent, triggers external execution, or otherwise carries consequence outside the surface itself.

Booking an appointment, sending a message, approving a document, transferring value, submitting an order, or changing a configuration are actions under this spec. These are write-consequential actions: they change the world.

Some actions are read-consequential rather than write-consequential. Accessing privileged data, revealing sensitive content, executing a costly query, or initiating analysis over private systems may be actions even when they do not mutate external state. Disclosure, computation, and exposure carry consequence too. Read-consequential actions are subject to the same v0.1 rules as write-consequential actions: action windows, refresh semantics, access scoping, and execution failure handoff.

Purely local interface operations — sorting a table, expanding a row, switching tabs, filtering a view — are not actions under this spec unless they invoke external execution, commit consequential state, or disclose privileged content.

Action window

The declared duration for which a specific action, once rendered, remains valid and may fire.

World state

State that lives outside the session, in external systems, databases, APIs, files, institutions, markets, calendars, inventories, or the physical world.

Actions may read from or write to world state.

Execution layer

The components that carry out actions against world state.

The execution layer is outside SSP's scope, but SSP defines how execution-layer failure returns to the session.

Surface origin

The application, agent, tool, or runtime component responsible for generating a surface and declaring its actions.

Surface origin is the identity behind a surface: who or what is asking the user to act. In single-application contexts, the origin is straightforward — the host application is both the generator and the responsible party. In multi-agent systems, embedded apps, third-party tools, plugins, enterprise workflows, or delegated automations, the origin may be distinct from the host application the user thinks they are interacting with.

v0.1 names surface origin as a concept and recommends that implementations preserve it (§17.2). Full provenance semantics — chains of origin across nested agents, attestation, and trust delegation — are deferred to a future version, where multi-agent contexts will require more developed treatment.

5. Scope of v0.1

SSP v0.1 focuses on private session surfaces and the validity of actions declared on them.

5.1 In scope

• Session lifecycle semantics.
• Surface lifecycle semantics.
• Action windows.
• Refresh semantics for expired actions.
• Execution failure handoff from the execution layer back to the conversational layer.
• Long-running execution semantics, including session state at completion.
• Access scoping for private, non-shareable surfaces.
• The relationship between surfaces and durable artifacts.
• Chat-surface choreography at a high level.

5.2 Out of scope

• Sharing, bookmarking, or discovery of surfaces.
• Persistence of surfaces beyond the session.
• Multi-user collaboration on a single surface.
• Atomic multi-step action semantics with rollback on partial failure (see §5.3 for v0.1 guidance on compound user intent).
• Cross-session state transfer or session migration.
• A conformance test suite.
• Durable artifact lifecycle beyond the surface relationship defined in §7.4.
• Shareable durable surface lifecycle.
• Consent semantics for public or semi-public surfaces.
• Citation, archival, and revocation semantics.
• Rendering and component specifications.

5.3 Why these deferrals

Each deferred concern is a real problem. None is this version's problem. The reason is not that those problems are secondary. Some are harder than the problems v0.1 solves.

Three deferrals deserve specific note because they are the ones implementers are most likely to confront immediately.

Compound multi-step action semantics. Most real applications involve action chains: book the appointment AND send the confirmation AND update the CRM. Compound actions raise rollback questions (what happens when step three fails after steps one and two committed?) that v0.1 cannot resolve cleanly. Atomic compound semantics will be addressed in a future version.

In v0.1, applications composing compound actions face a design choice that the protocol is silent on but that materially affects user experience. The wrong default produces two distinct failure modes.

The first failure mode is UI fatigue. If a developer expresses a single user intent as a sequence of independent SSP actions, the user experiences multiple confirmations, multiple countdowns, and multiple refresh cycles for what is, from their perspective, one decision. The protocol's per-action discipline becomes hostile when applied to intent the user expressed as a single commitment.

The second failure mode is flow disruption. If a step in an action chain completes, expires, or requires refresh while the user has moved on to a different concern, the system interrupts the user's current attention to handle a stale thread from an earlier intent. The user said "do this and that," already moved on, and is now being asked to revisit something they mentally finished.

The protocol's recommendation, pending compound action work in a future version, is that compound user intent SHOULD be expressed as a single SSP action whose internal execution is the application's concern. The user's surface presents one decision, one window, and one outcome. The application orchestrates the constituent steps internally and surfaces a single execution result through the §9 failure handoff if any step fails. Sequential SSP actions exposed to the user should be reserved for cases where the steps are genuinely independent decisions the user should make separately — not as a default for any operation that internally requires multiple calls. This recommendation is formalized as a normative SHOULD in §17.2; see §11.5 for the user-facing pattern.

Shareable durable surfaces. Shareability is not a flag on a v0.1 surface. It is a separate primitive with its own design pressures: consent, revocation, durability, citation, archival, social convention. A half-designed answer to those problems would be worse than no answer. v0.1 keeps the private primitive clean and leaves the public primitive for later work. See §12.

Durable artifact lifecycle. v0.1 specifies the relationship between surfaces and artifacts (§7.4) but does not define how artifacts themselves are stored, versioned, or retrieved. Artifacts persist according to application-defined rules. SSP names the boundary; applications own what lies on the artifact side of it.

6. Session lifecycle

The session is the organizing primitive. Surfaces are scoped to the session that created them.

6.1 Session states

An SSP session may be active, idle, or terminated.

Active

The session is current. New conversational turns and surfaces may be generated. Previously rendered surfaces may remain available for re-focus.

Idle

The session has received no user input for an implementation-defined idle interval.

Surfaces may remain available. Actions within them follow their own action-window rules, which may have expired independently.

The session MAY be brought back to active by user input.

SSP v0.1 treats idle as a user-interaction state, not a guarantee that no background execution exists. Background execution semantics are outside this draft's scope.

A session MAY also return to active state through system-initiated conversational turns, including completion announcements for long-running actions (per §9.6), surface refresh prompts, or other application-driven communications. System-initiated turns MUST be clearly attributable to system action rather than user input, so the user is not confused about who originated the message. Implementations SHOULD use system-initiated turns sparingly. An idle session that frequently wakes itself produces UX as hostile as a session that auto-refreshes expired actions.

Terminated

The session has ended, either by explicit user action, idle-timeout policy, or application decision.

On termination, all private session surfaces within the session are destroyed. Surface access keys are invalidated.

Durable artifacts created, modified, or displayed through surfaces may persist according to application-defined rules. They are not governed by the surface lifecycle. See §7.4.

6.2 Idle and termination policy

Implementations MUST define an idle-timeout interval and a termination policy.

SSP v0.1 does not prescribe specific durations. Implementations SHOULD communicate termination policy to users in general terms, so users understand how long a session persists without interaction.

Draft note. v0.1 does not set default idle or termination durations. A later version may recommend non-normative defaults.

7. Surface lifecycle

Private session surfaces are session-scoped. They persist within their session and are destroyed on session termination. They are private, non-shareable, and non-bookmarkable in v0.1.

7.1 Surface instantiation

A surface is instantiated by the application in response to conversational intent.

Instantiation produces:

• A surface identifier, unique within the session.
• An access key or equivalent access-control binding scoped to the authenticated user and session.
• A render payload describing the surface's structure, content, and declared actions.
• A render timestamp, which is the reference point for action-window durations declared on the surface.

7.2 Surface persistence within the session

Once instantiated, a surface persists for the duration of its session unless explicitly dismissed or retired.

The user MAY return to a previously rendered surface while the session is active or idle.

Informational content on the surface may remain visible across return. Action affordances follow action-window rules and may have expired.

7.3 Surface destruction

A surface is destroyed when:

• The session terminates.
• The application explicitly retires the surface.
• The user dismisses the surface through an implementation-defined affordance.

Destroyed surfaces are unreachable. Their access keys or equivalent access-control bindings are invalidated. Surface state is not preserved by SSP.

Applications SHOULD retire surfaces whose underlying intent has clearly been superseded by later conversation, but SHOULD do so visibly rather than silently. A retiring action SHOULD be reflected in the conversational stream so the user understands what changed.

Durable artifacts created or modified through a surface may persist separately. The surface-artifact relationship is specified in §7.4.

Surface destruction MUST be propagated to the surface origin (§4) where the origin is distinct from the runtime that holds the surface. The origin SHOULD discard ephemeral state corresponding to the destroyed surface — the rendered payload, the user's interactions with options, intermediate selections that did not commit as actions, and any working memory the origin held about the surface's content.

The discard obligation applies to ephemeral surface state, not to durable artifacts (which persist under §7.4) or to audit metadata (which §9.7 explicitly permits implementations to retain). Origins MAY retain the minimum metadata required to satisfy §9.7's audit boundary; they SHOULD NOT retain rendered content, option-set snapshots, or interaction traces beyond what audit demands.

Without this rule, a surface's ephemeral guarantee is only enforced at the user-facing layer. The user reasonably expects destruction to mean the surface is gone everywhere it was held, including in the runtime state of any third-party agent or tool that generated it. The protocol's privacy posture depends on origins honoring the surface lifecycle they participated in.

7.4 Artifacts and surfaces

A surface is a structured instrument inside a session. An artifact is a durable object the surface may create, modify, or reference. They are distinct concepts with distinct lifecycles, and the protocol's failure mode is most likely to occur where implementers blur them.

This section establishes minimum rules for the surface-artifact boundary. The intent is to prevent fragmentation between implementations on the question of what survives a surface's destruction.

7.4.1 Independence of artifact lifecycle

Artifacts referenced or produced through a surface persist according to application-defined rules. Their lifecycle is independent of the surface lifecycle.

Destroying a surface MUST NOT destroy artifacts referenced through it. A surface holds a view onto an artifact; it does not hold the artifact itself.

When a session terminates and surfaces are destroyed, artifacts created through those surfaces remain available through application-defined access mechanisms. The protocol does not specify those mechanisms; it specifies that they exist independent of SSP.

7.4.2 Distinguishing surface content from artifact content

Surfaces SHOULD make clear which content is artifact-backed and which is surface-only.

A user reviewing a surface should be able to understand which elements will outlive the surface (artifact-backed) and which will be lost when the surface is destroyed (surface-only). The specific affordance is left to implementations, but the principle is normative: the user should not be surprised by what disappears.

Examples of artifact-backed content: a generated document the user has saved, a calendar event that has been booked, an order that has been submitted, a record that has been created in an external system.

Examples of surface-only content: a comparison view, a transient form, a draft preview that has not been committed, a scratchpad of options the user is considering.

7.4.3 Modifying artifacts through surface actions

When a surface action modifies a referenced artifact, the modification follows execution-layer semantics, not surface-lifecycle semantics.

Surface destruction does not roll back artifact modifications. If a user submits an order through a surface action and the surface is later destroyed, the order remains submitted. If a user approves a document through a surface action, the approval remains in effect.

The conversational layer SHOULD reflect artifact modifications back to the user so the durable consequence of the action is visible after the surface is gone.

7.4.4 Re-instantiating surfaces from artifacts

A surface MAY be instantiated with its initial state bound to an existing durable artifact. The artifact serves as the source of the surface's content; the surface provides the structured interface for viewing, modifying, or acting on that content.

Such a surface is a new surface under SSP. It has no protocol-level relationship to any prior surface that referenced the same artifact. Action windows on the new surface measure from its own render timestamp. Access scoping binds to the new surface's session and user. The new surface's lifecycle follows §7.3 — it is destroyed when its session terminates, regardless of whether the underlying artifact persists.

This rule prevents implementations from accumulating surface history across sessions in ways that would compromise the ephemeral guarantee. The artifact carries durable state; the surface is always fresh.

8. Action windows

Every action declared on a surface carries a time-bounded window.

Within the window, the action may fire. Outside the window, the action is retired and must be refreshed against current world state.

8.1 Rationale

A session-scoped surface can persist. The world it depicts may not.

Between render and action, world state may drift. Appointment slots fill. Prices change. Documents are edited. Permissions expire. Inventory moves. Policies update. A user may return to a surface that still looks coherent but no longer reflects the world against which the action would execute.

SSP does not allow an old action affordance to silently reconcile itself with a drifted world.

Reconciliation must be explicit: the action expires, the user requests current state, and the action region is re-rendered.

This mirrors interaction patterns users already understand from checkout timers, fare quotes, reservation holds, and verification codes. It requires no new mental model.

8.2 Action window declaration

Every action declared on a surface MUST include an action_window field specifying the duration for which the action remains valid.

The duration is measured from the surface's render timestamp, unless the action region has been refreshed. If refreshed, the new action window is measured from the refresh timestamp.

Action windows are declared per action. A surface may contain multiple actions with distinct windows.

A surface may also contain informational content with no actions. Informational content is not time-bounded by SSP and may persist for the lifetime of the surface.

8.2.1 Actions versus options within an action

An action window governs the validity of an action, not the validity of each option presented within that action. This distinction matters because surfaces commonly present the user with a set of alternatives — slots, items, candidates, quotes, contractors — among which the user is being asked to choose. The act of choosing is the action. The alternatives are the option space.

A surface that asks the user "Book a time" and presents three available slots is rendering one action with three options. The action window governs the validity of the rendered option set as a whole — how long the slots remain a faithful representation of current availability. When the window expires, the option set is stale; refresh re-renders the set against current world state. The user's selection from the set, made within the action window, is what fires.

Implementations MUST NOT treat each option in a selection as a separate action with its own window. Three slots do not warrant three countdowns; one comparison set does not warrant N independent action windows. The world-state representation is the unit that drifts, and the action window protects that representation. Multiple action windows are appropriate when the actions are genuinely independent decisions the user could invoke separately or in any combination — not when they are alternatives within a single choice.

The test is whether the user is being asked to commit to one of several options (one action) or to invoke any subset of independent operations (multiple actions). The first is one action with one window. The second is multiple actions, each with its own window.

8.3 Action states

An action exists in one of two states.

Live

The action window has not elapsed. The action may fire.

Expired

The action window has elapsed. The action is retired and MUST NOT fire.

8.4 The tap-down intent rule

An action is considered live if user intent to invoke it is registered before the action window elapses, even if execution completes after the window has elapsed.

The canonical timestamp is the moment of user intent: tap-down, click-down, keypress-down, or equivalent initial input event.

The canonical timestamp is not the moment of action completion.

This rule is load-bearing. Implementations MUST capture the moment of user intent as the timestamp used to determine action-window validity.

The rule honors human reaction time and network latency. A user should not be punished for acting at the edge of a window.

For actions presenting multiple options (per §8.2.1), the canonical timestamp is the moment the user commits the action, not the moment they select among options. Tapping a slot, highlighting a candidate, or otherwise indicating a tentative selection is local interface manipulation; it does not register intent under this rule. Intent is captured only when the user commits the action — for example, by tapping the action affordance ("Book selected time") rather than the individual option. Implementations MUST capture the action commitment as the canonical timestamp, not the option selection.

8.5 Communicating remaining validity

Action affordances must communicate remaining validity in a way that is appropriate to the action window's duration and to the modality through which the user is interacting. Two regimes apply.

8.5.1 Short windows

For action windows of five minutes or less, live actions MUST continuously communicate remaining validity to the user. "Continuously" means the user can perceive the remaining time at any moment without having to interrogate the affordance.

In visual modalities, the canonical pattern for satisfying this requirement is a continuously visible countdown — numeric timer, progress bar, ring, fading element, or equivalent. Voice and ambient modalities may satisfy the requirement through periodic spoken updates, audio cues, or other modality-appropriate continuous indication. Implementations SHOULD use the canonical visual countdown when the surface is rendered in a visual UI.

Without continuous validity communication, the user has no way to know the window is closing. The protocol's MUST is on the communication; the specific affordance is implementation-defined.

8.5.2 Long windows

For action windows longer than five minutes, continuous communication of remaining validity becomes hostile UX (a 25-minute timer ratcheting down on screen, or repeated voice updates over a long interval, produce anxiety without serving the user). Implementations MAY suppress continuous indication for long windows. However:

• Implementations MUST surface remaining time when the user interrogates the action affordance — whether by hovering, tapping, asking, or other modality-appropriate query.
• Implementations MUST communicate impending expiration in the final two minutes of the window, regardless of total window length, so the user has clear notice that the action is about to expire. The specific affordance for this final-window communication is implementation-defined; in visual modalities the canonical pattern is a countdown.

This rule prevents long windows from expiring without warning while avoiding the UX cost of long visible countdowns. The MUSTs are modality-neutral; the canonical patterns are visual UI defaults.

8.5.3 Expired states

Expired actions MUST be unambiguously distinct from live actions. The user MUST NOT be able to confuse an expired action with an invocable one.

In visual modalities, expired states SHOULD lose chromatic emphasis through desaturation, muting, opacity reduction, or equivalent treatment. Voice and ambient modalities should communicate expired state through corresponding modality-appropriate cues. The specific visual or auditory language is left to implementations. The requirement of unambiguous distinction is normative.

8.6 Refresh

An expired action MUST present a refresh affordance.

The session MUST NOT auto-refresh expired actions.

Refresh is initiated by the user. This preserves agency and prevents the surface from appearing to act on its own.

When invoked, the refresh affordance re-renders the action region against current world state. A new action window begins at refresh time.

Refresh is scoped to the action region, not necessarily the entire surface. Informational context the user has already consumed SHOULD be preserved where possible.

The refresh affordance SHOULD occupy the spatial region previously occupied by the countdown or remaining-validity indicator, preserving continuity for the user's attention.

When refresh produces a materially different state — a changed price, a different available slot, a new document version, an altered permission, a modified consequence — the session SHOULD make the change explicit before allowing commitment. A user who taps "Check current fare," sees a re-rendered price, and reflexively accepts may not realize the price changed. The disclosure of material change protects against accidental commitment to drifted state. The specific affordance is left to implementations: a brief conversational note, a visual marker on the changed element, an explicit confirmation step, or equivalent. The protocol's MUST is on the change being communicated; the implementation is free.

8.7 Refresh affordance labeling

The refresh affordance's label MUST describe the refresh operation in terms of the user's intent, not the mechanical operation.

"Refresh" is not sufficient.

Correct labels include:

• "Check current slots"
• "Recheck availability"
• "Check current fare"
• "Validate latest version"
• "Update approval status"
• "Check current inventory"

A user reading the label should understand what the refresh will produce, not merely what button they are pressing.

This rule is central to SSP's coherence between conversational and surface modes. The surface should speak in the language of the user's task.

8.8 Choosing an action window duration

Action window duration is declared by the surface generator and reflects how long the underlying world state is expected to remain valid.

SSP does not prescribe universal durations. Implementations SHOULD consider both state volatility and action consequence.

Volatile state warrants shorter windows. Stable state may support longer windows. High-consequence actions should generally use shorter windows, even when the state itself is relatively stable, to reduce the probability of uninformed consent after user inattention.

Non-normative examples:

• Live availability (book an appointment slot): 30 seconds to 5 minutes.
• Live pricing (accept fare, quote, or bid): 15 seconds to 2 minutes.
• Inventory (reserve item or quantity): 30 seconds to 5 minutes.
• Document approval (approve current version): 5 to 30 minutes.
• Configuration change (save system setting): 5 minutes to session idle timeout.
• High-consequence action (transfer funds, sign contract): short window plus additional confirmation or re-authentication.

Window durations are design decisions, not correctness guarantees.

A window too long produces stale actions. A window too short produces user friction.

8.9 What action windows do not cover

Action windows protect against drift in world state that the action directly depends on.

They do not fully protect against:

• Changes in the user's authority to perform the action.
• Changes in upstream system availability.
• Changes in policy or rate limits.
• Execution-time validation failures.
• Conflicts created by concurrent edits or actions.

These concerns are the responsibility of the execution layer.

SSP requires that execution-layer failures return structured context to the session. See §9.

9. Execution failure handoff

When an action fires and fails for reasons outside the action window, control returns to the conversational layer with enough structured context for the session to resolve the failure intelligibly.

9.1 Rationale

Action windows protect against one class of stale interaction. They cannot protect against every execution failure.

An action may be live when invoked and still fail. The user's authority may have changed. An upstream provider may be unavailable. A policy check may reject the action. A field may fail validation. A document may have changed since the surface rendered. A booking slot may disappear between refresh and execution.

These failures are inevitable.

The question is whether they produce comprehensible UX or silent breakage.

SSP requires execution-layer failures to return to the session with structured context. The conversation can then explain the failure, propose alternatives, ask for corrected input, or render a new surface.

The surface layer does not attempt to self-heal silently. The conversational layer owns recovery.

This is how the conversational substrate earns its role as the site of continuity: when surfaces break, the conversation catches them.

9.2 Required failure context

When an action fires and the execution layer returns a failure, the runtime MUST return the following to the session:

• A failure category.
• A human-readable failure reason suitable for inclusion in a conversational response.
• Structured failure data where applicable.
• A remediation hint where applicable.

Recommended v0.1 failure categories:

• authorization
• availability
• conflict
• policy
• validation
• execution
• other

Structured failure data MAY include the specific rule that rejected the action, the unavailable upstream system, the field that failed validation, the conflicting version, or the resource that changed.

Remediation hints MAY include retry, re-authenticate, adjust input, refresh state, contact administrator, or choose an alternative.

9.3 Conversational resolution

On receiving a failure handoff, the session SHOULD:

• Surface the failure to the user in conversational form.
• Explain the failure in terms of the user's intent.
• Offer remediation where remediation is possible.
• Re-render a corrected surface where useful.
• Avoid blaming the user for failures not caused by user input.

The surface from which the action fired MAY remain visible, but the failure narrative belongs in the conversation.

9.4 Example: authorization failure

A user asks to schedule a contractor walkthrough.

The application renders available calendar slots. The user selects 3:30 PM while the action is live.

The execution layer attempts to create the calendar event, but the user's calendar authorization has expired.

The failure handoff returns:

• Category: authorization
• Reason: "Your calendar connection expired before the appointment could be booked."
• Structured data: calendar provider, expired credential identifier
• Remediation hint: re-authenticate

The session responds conversationally:

"I couldn't book 3:30 PM because your calendar connection expired. Reconnect your calendar and I'll check that slot again."

The recovery happens through the session, not through a cryptic surface error.

9.5 Example: conflict failure

A user reviews a document approval surface.

The approval action is still live. The user taps "Approve current version."

During execution, the document system rejects the action because a newer version was saved after the surface rendered.

The failure handoff returns:

• Category: conflict
• Reason: "This document changed after the approval view was generated."
• Structured data: rendered version ID, current version ID
• Remediation hint: refresh state

The session responds:

"This version is no longer current. The document changed after I showed it to you. I can show the latest version before you approve."

The system may then render a new approval surface against the latest artifact.

9.6 Long-running execution

Action execution may take longer than the action window itself. Local inference, agentic reasoning chains, multi-step tool orchestration, and external system latencies can produce execution times measured in seconds or minutes. The action window governs validity at the moment of intent (§8.4); it does not govern execution duration.

Three cases apply to long-running execution.

If the session remains active when execution completes, the result returns to the conversational layer normally.

If the session is idle when execution completes, the runtime MUST be able to deliver the completion to the conversational layer when the session next becomes active. Implementations MAY surface system-initiated conversational turns that announce completion of long-running actions; if they do, those turns MUST be clearly attributable to system action rather than user input (per §6.1).

If the session has terminated when execution completes, the action's effect on world state still applies (the booked appointment is booked, the saved document is saved), but the session is no longer available to receive a conversational completion message. The runtime SHOULD record the completion in a manner the user can reach in a subsequent session — through the application's notification system, an artifact (per §7.4) representing the completed action, or other application-defined mechanism. The runtime MUST NOT lose the completion silently.

Implementations MUST define a maximum execution timeout beyond which the runtime returns a structured failure (per §9.2, category execution) even if the action would have eventually completed. The timeout duration is implementation-defined but SHOULD be communicated to users when actions are likely to approach it.

9.7 Audit trail boundary

SSP does not define an audit-log format. Audit logging is the implementation's concern, governed by application requirements, regulatory frameworks, and operational practice.

However, the tap-down intent rule (§8.4) is load-bearing: it determines whether an action was valid at the moment of invocation, and disputes about that validity may arise after the fact. If a user disputes whether they invoked an action before its window expired, the system needs an audit record to resolve the dispute.

Implementations SHOULD record action invocation metadata sufficient to reconstruct what surface action was invoked, by whom, in which session, at what tap-down intent timestamp (§8.4), against which declared action window, with what surface origin (§4), and with what execution result. The protocol does not specify how this record is stored, retained, or accessed; it specifies that the record be sufficient to make the protocol's load-bearing facts auditable.

Without a minimum audit record, the protocol's reliance on tap-down intent timestamps becomes unaccountable. With it, disputes can be resolved against the protocol's own semantics.

10. Access scoping

Surfaces in SSP v0.1 are private to the authenticated user within the session that created them.

They are not shareable by URL or link.

10.1 Threat model

SSP surfaces may carry sensitive content: financial, personal, medical, legal, operational, commercial, or otherwise privileged information.

The protocol assumes that surface identifiers and link structures may be accidentally disclosed through screen sharing, copy-paste, browser history, logs, screenshots, or analytics tools.

Access MUST NOT be grantable by knowledge of a surface identifier alone.

SSP access scoping governs access to the live surface and its runtime payload. It cannot prevent disclosure through screenshots, screen sharing, local device compromise, copying, or other forms of representation that occur outside the protocol's reach. Implementations handling sensitive content SHOULD consider additional controls — watermarking, screenshot detection, content-loss-prevention policy, device-attestation requirements, or equivalent measures — outside SSP. The protocol secures the live surface; it does not secure all possible representations of what the user saw.

10.2 Access property

Every surface MUST be associated with an access-control binding scoped to:

• The authenticated user of the session.
• The session itself.
• The lifetime of the surface within the session.

Possession of a surface identifier without the corresponding session-scoped authorization MUST NOT grant access.

Invalidation on session termination or surface destruction MUST be enforced at the access layer, not merely hidden at the rendering layer.

10.3 Mechanism

SSP v0.1 defines the required access property, not a specific cryptographic construction.

Implementations may satisfy this property through signed session-bound tokens, server-side key lookup, short-lived access grants, authenticated session checks, or equivalent mechanisms.

Draft note. A future version may define a recommended construction or conformance profile.

10.4 Non-shareability

Surfaces in v0.1 are explicitly non-shareable.

The protocol does not define a mechanism for granting another user access to a surface. Applications MUST NOT provide affordances that imply shareability, including copy-link, share-to, public preview, or bookmark affordances for v0.1 surfaces.

Future versions of SSP may define a separate shareable durable surface primitive with its own lifecycle, consent, revocation, citation, archival, and access semantics.

That primitive is not this primitive.

11. Chat-surface choreography

The conversational stream is the session's center of gravity.

Surfaces are instruments within the conversation. They rise, focus attention, collect or display structured information, support action, and then return continuity to the conversational layer.

11.1 When to render a surface

A surface SHOULD be rendered when:

• The user's intent requires structured input that would be tedious or error-prone in conversation.
• The application needs to present structured state for review, comparison, manipulation, or consent.
• The user needs to act on a specific representation of world state.
• An action requires explicit consent on structured content.

Examples include multi-field forms, selection from large sets, ranked priorities, quote comparisons, calendar availability, document approvals, data tables, incident timelines, and generated artifact previews.

11.2 When not to render a surface

A surface SHOULD NOT be rendered when a conversational response would be equally or more usable.

Surface proliferation is a failure mode.

A language-user interface should not become a slot machine of transient widgets. Surfaces should appear because structure helps the user think, decide, review, or act.

11.3 Returning from surface to conversation

After a surface action fires, expires, refreshes, fails, or is dismissed, the session SHOULD return the user's attention to the conversational stream with an appropriate message.

The surface MAY remain visible, but the conversation is the site of continuity.

Examples:

"I booked the 3:30 PM slot and sent the invite."

"Those times expired, so I checked current availability."

"The quote changed before you accepted it. I pulled the current fare."

"That document changed after I showed it to you. I can show the latest version."

The surface does not need to narrate itself. The session does.

11.4 Harder cases

Some interaction patterns complicate the chat-surface relationship.

Long-form authoring may make the surface feel like the primary workspace. Multi-agent orchestration may require surfaces that show intermediate state, progress, confidence, or produced artifacts. Approval gates may make a surface the decisive instrument of consent.

SSP v0.1 does not fully solve these cases.

The recommended distinction is:

• The session coordinates continuity.
• The private session surface provides structured interaction.
• The artifact persists beyond the surface when durability is required.
• The shareable durable surface is a future primitive for public or semi-public reference.

Worked examples for long-form authoring, multi-agent orchestration, and approval gates are candidates for a companion document or v0.2.

11.5 Compound intent and surface composition

Where user intent is compound — book the appointment AND send the invite AND update the tracker — the surface SHOULD represent the intent as a single decision affordance, not as a chain of independent surfaces.

The user's view is one action with one window. The application's internal execution may involve multiple system calls, sequential or parallel. If any internal step fails, the §9 failure handoff returns a single failure to the conversational layer with structured context describing which constituent step failed and what state has or has not been committed.

Multi-surface chains are appropriate when the steps are genuinely separate decisions: review the contract, then approve it; choose the contractor, then schedule the walkthrough. Multi-surface chains are inappropriate when the user has already expressed a single compound intent and the chain exists only because the implementation is composed of multiple system calls.

When in doubt, the test is whether the user expects to make separate decisions. If yes, separate surfaces are correct. If no, the surface should be compound and the orchestration should be internal.

12. Future primitive: shareable durable surfaces

SSP v0.1 intentionally does not define shareable surfaces.

A shareable durable surface is not simply a private surface with broader access. It is a separate primitive.

Private session surfaces are optimized for:

• Privacy.
• Freshness.
• Session continuity.
• Trust at the moment of action.
• Human recovery when execution fails.

Shareable durable surfaces would need to be optimized for different properties:

• Stability.
• Addressability.
• Versioning.
• Consent.
• Revocation.
• Citation.
• Archival.
• Attribution.
• Integrity.
• Long-term meaning.

Those properties create a different design space.

A shareable surface requires the owner's consent to be shared. But consent is not binary. A user who permits someone to read a surface has not necessarily permitted that reader to reshare it, cite it, archive it, train a model on it, remix it, or preserve it after revocation.

A durable surface must outlive the session that created it. But durability is not just storage. The surface must remain accessible, renderable, and meaningful over time.

A citable surface must have stable identity, versioning, provenance, and temporal anchoring.

An archival surface must negotiate the tension between preservation and consent.

A revoked surface must be honest about what revocation can and cannot do. Future access can often be blocked. Cached copies, citations, archives, and training data may not be reachable.

These are not implementation details. They are defining semantics.

For that reason, SSP v0.1 refuses to hide them behind a shareable: true flag.

The page era gave the web a public commons by bundling addressability, durability, citation, linking, and archival into a single primitive. The conversational era will not inherit that commons automatically. If it needs a commons, it will need primitives designed for one.

That is future work.

13. Worked example: appointment booking

A user says:

"Find me a time with the plumber tomorrow afternoon."

The session checks the relevant calendar and renders a surface offering the user a selection from available slots. The action is "Book a time" — the act of selecting a slot from the rendered set. The action carries a single action window of two minutes, because availability may change.

The surface shows:

• 2:00 PM
• 3:30 PM
• 4:15 PM

Book selected time — 1:58 remaining

The user is choosing among three options inside one action. The countdown applies to the action, not to each slot.

The user steps away.

When the user returns, the action window has expired. The slot list may remain visible, but the booking action no longer fires. The action region offers an intent-labeled refresh affordance:

"Check current slots"

The user taps "Check current slots."

The action region re-renders against current calendar state. The 3:30 PM slot is still available; the 2:00 PM slot has filled and no longer appears; a 4:45 PM slot has opened and is now in the set. A new two-minute action window begins.

The user selects 3:30 PM and taps "Book selected time" with one second remaining.

Even if execution completes after the countdown reaches zero, the action is valid because intent was registered before expiration.

The session responds:

"I booked 3:30 PM tomorrow and sent the invite."

The booked appointment becomes a calendar event — a durable artifact under §7.4 — that persists after the surface is destroyed.

14. Worked example: document approval

A user says:

"Show me the final contractor scope before I approve it."

The session renders an approval surface showing the current document version, key changes, cost, schedule, and approval action.

The approval action has a 15-minute window. The document is relatively stable, but approval carries consequence. Per §8.5.2, validity communication is suppressed by default and becomes active in the final two minutes; in this visual UI implementation, the canonical countdown pattern is used.

The user reviews the surface and taps "Approve current version."

The action is live.

During execution, the document system rejects approval because a collaborator saved a newer version two minutes earlier.

The action window did not fail. The execution layer did.

SSP requires a structured failure handoff. The session receives a conflict failure and responds:

"This scope changed after I showed it to you. I don't want you approving an old version. I can show you what changed."

The session may then render a comparison surface.

The important point is that the user is not trapped in a dead approval interface. The conversation absorbs the failure and restores continuity.

15. Worked example: generated artifact preview

A user says:

"Turn this research into a client-ready summary."

The session generates a draft summary and renders it in a surface for review. The surface lets the user scan the structure, expand sections, request edits, and approve export.

The surface is private and ephemeral. It belongs to the session.

The generated summary, however, may become an artifact if the user chooses to save or export it. The artifact can persist after the surface is destroyed, per §7.4.

The surface and the artifact are not the same thing. The surface is the review instrument; the artifact is the saved document.

If the user asks for revisions, the session may update the surface. If the user approves export, the execution layer may create a durable document in the application's storage system.

The approval action may carry an action window. If the underlying source material changes while the user is reviewing, the approval may expire or fail with a conflict handoff.

But when the session ends, the private review surface is destroyed. The exported artifact remains.

This distinction prevents SSP from confusing temporary structured interaction with durable recordkeeping.

16. Worked example: incident response

A security analyst on the night shift opens an SSP-speaking incident response application and says:

"Show me the affected hosts from the alert that fired ten minutes ago and isolate the compromised endpoint."

The session queries the security data layer and renders a surface showing the alert details, the eight affected hosts, the suspected compromised endpoint, the attack chain reconstructed from telemetry, and three actions: isolate the compromised endpoint, escalate to the incident commander, and generate a triage artifact for handoff.

This single surface demonstrates several SSP mechanics in concert.

The host list is read-consequential content (§4). It exposes privileged operational data from production systems. Although it does not mutate world state, the act of disclosing the host list is itself an action subject to access scoping and audit. The user's authorization to view this content is verified at surface instantiation; if the analyst's session-level permission to query this data class were to change mid-session, the surface would expire and require refresh.

The isolate action is high-consequence and write-consequential. Isolating a compromised endpoint disconnects it from the network, halting potential lateral movement but also potentially disrupting legitimate work if the analyst's diagnosis is wrong. The action carries a 90-second action window — short, because endpoint state changes rapidly during active incident response, and because isolating the wrong host has operational cost. The window is short enough to require a continuously visible countdown per §8.5.1.

The escalate action carries a longer 10-minute window. Escalation is reversible and lower-consequence; the action allows the analyst time to gather context before committing. Per §8.5.2, the countdown is hidden by default and becomes visible in the final two minutes.

The generate triage artifact action produces a durable artifact (§7.4) — a structured incident report containing the host list, attack chain, observed indicators, actions taken, and timestamps. The artifact persists after the surface is destroyed; it becomes the record passed to the incident commander, the basis for post-incident review, and the input to compliance reporting.

The analyst taps "Isolate compromised endpoint" with 12 seconds remaining on the action window. The tap-down intent timestamp (§8.4) is captured at the moment of action commitment, even though execution against the endpoint management system takes 23 seconds to complete and the 90-second window has nominally expired by the time the isolation succeeds.

During execution, the endpoint management system rejects the isolation because a different analyst on the day shift just initiated isolation of the same endpoint forty seconds earlier. The execution layer returns a structured failure (§9.2):

• Category: conflict
• Reason: "This endpoint is already being isolated by another analyst's action."
• Structured data: conflicting analyst identifier, conflicting action timestamp, current isolation state
• Remediation hint: refresh state

The session responds conversationally:

"Another analyst started isolating that endpoint forty seconds before you did. The isolation is already in progress. I can show you the current isolation status, or you can move on to escalation."

The analyst is not trapped in a dead surface or shown a cryptic system error. The conversation absorbs the conflict and offers a path forward.

Throughout this flow, the runtime records the audit trail required by §9.7: which surface action was invoked, which surface origin (the incident response application, distinct from the underlying SIEM and endpoint management systems), the analyst's session, the tap-down intent timestamp, the declared action window, and the conflict result. If the analyst is later asked whether they attempted to isolate the endpoint, the audit record resolves the question against the protocol's own semantics.

The triage artifact, generated through a separate action against the same surface, persists after the session ends. The next-shift incident commander opens it through the application's artifact retrieval mechanism — a new SSP session, a new surface bound to the existing artifact (§7.4.4), and a fresh action window for any further actions taken against it.

This example demonstrates SSP outside consumer or productivity UX. The mechanics that protect a contractor appointment from accidental booking also protect a compromised endpoint from accidental isolation by a misinformed analyst. The protocol's discipline scales to enterprise and security contexts because the underlying problem — making consequential action trustworthy inside a drift-prone session — is the same.

17. Requirements summary

17.1 MUST

• Every action declared on a surface MUST include an action_window.
• Expired actions MUST NOT fire.
• Live actions with windows of five minutes or less MUST continuously communicate remaining validity to the user in a modality-appropriate manner.
• Live actions with windows longer than five minutes MUST surface remaining time when the user interrogates the action affordance, and MUST communicate impending expiration in the final two minutes of the window.
• Expired actions MUST be unambiguously distinct from live actions.
• Expired actions MUST present a refresh affordance.
• The session MUST NOT auto-refresh expired actions.
• Implementations MUST NOT treat each option in a selection as a separate action with its own window.
• Refresh affordance labels MUST describe the refresh in terms of user intent, not mechanical operation.
• Execution-layer failures MUST return structured context to the session.
• Every surface MUST be associated with access control bound to user, session, and surface lifetime.
• Possession of a surface identifier without corresponding session-scoped authorization MUST NOT grant access.
• Applications MUST NOT provide shareability affordances for v0.1 surfaces.
• Private session surfaces MUST NOT persist beyond their session.
• Destroying a surface MUST NOT destroy artifacts referenced through it.
• Surface destruction MUST be propagated to the surface origin where the origin is distinct from the runtime that holds the surface.
• Implementations MUST capture the action commitment as the canonical timestamp for action-window validity, not the option selection.
• System-initiated conversational turns MUST be clearly attributable to system action rather than user input.
• The runtime MUST be able to deliver completion of long-running actions to the conversational layer when the session next becomes active.
• The runtime MUST NOT lose long-running execution completions silently.
• Implementations MUST define a maximum execution timeout for long-running actions.

17.2 SHOULD

• In visual modalities, expired states SHOULD lose chromatic emphasis through desaturation, muting, opacity reduction, or equivalent treatment.
• In visual modalities, continuous validity communication SHOULD use the canonical countdown pattern (numeric timer, progress bar, ring, fading element, or equivalent).
• The refresh affordance SHOULD occupy the spatial region previously occupied by the remaining-validity indicator.
• When refresh produces a materially different state (changed price, different slot, new version, altered permission, modified consequence), the session SHOULD make the change explicit before allowing commitment.
• Implementations SHOULD communicate session idle and termination policy to users.
• Implementations SHOULD consider state volatility and action consequence when choosing window durations.
• Applications SHOULD retire surfaces whose underlying intent has clearly been superseded by later conversation, and SHOULD do so visibly rather than silently.
• Sessions SHOULD surface execution failures in conversational form.
• Sessions SHOULD return attention to the conversational stream after surface actions, failures, refreshes, or dismissals.
• Surfaces SHOULD make clear which content is artifact-backed and which is surface-only.
• The conversational layer SHOULD reflect artifact modifications back to the user so the durable consequence of the action is visible after the surface is gone.
• Compound user intent SHOULD be expressed as a single SSP action whose internal execution is the application's concern, rather than as a chain of independent SSP actions.
• Implementations SHOULD use system-initiated conversational turns sparingly.
• The runtime SHOULD record long-running completions on terminated sessions in a manner the user can reach in a subsequent session.
• Implementations SHOULD communicate execution timeout duration to users when actions are likely to approach it.
• Implementations SHOULD record action invocation metadata sufficient to reconstruct what surface action was invoked, by whom, in which session, at what tap-down intent timestamp, against which declared action window, with what surface origin, and with what execution result.
• Implementations SHOULD preserve surface origin in runtime state and expose it when relevant to user trust, permissions, debugging, or audit.
• Surface origins SHOULD discard ephemeral state corresponding to a destroyed surface — rendered payload, user interactions with options, intermediate selections that did not commit as actions, and working memory the origin held about the surface's content.
• Surface origins SHOULD NOT retain rendered content, option-set snapshots, or interaction traces beyond what the §9.7 audit boundary demands.
• Implementations handling sensitive content SHOULD consider additional disclosure controls (watermarking, screenshot detection, content-loss-prevention policy, device-attestation requirements) outside SSP.

18. Open questions for v0.1 review

These are the unresolved questions where v0.1 has named a position but where public review may surface better answers.

18.1 Default idle and termination durations

Should v0.1 recommend non-normative default values (e.g., 30-minute idle timeout, 24-hour hard termination), or remain fully implementation-defined? Implementation-defined preserves flexibility but produces inconsistent UX across implementations on a property users will compare directly.

18.2 Long-window countdown thresholds

§8.5 sets the boundary between short and long windows at five minutes (continuous validity communication required) and the final-warning threshold at two minutes (validity communication required regardless of window length). These thresholds are reasoned but not empirically validated. Are they correct across the full range of action types and modalities, or do certain action categories or modalities warrant different thresholds?

18.3 Surface supersession across stale conversational context

§7.3 says applications SHOULD retire surfaces whose intent has been superseded. But "clearly superseded" is judgment, not rule. When a user changes their mind mid-conversation, when an agent decides the prior surface is stale, or when a long-running session accumulates many surfaces, what guidance should the protocol offer about which surfaces to retire automatically and which to leave for the user?

18.4 Compound action atomicity

§5.3 and §11.5 establish v0.1's position: compound user intent should be expressed as a single SSP action with internal orchestration, and atomic compound semantics with rollback are deferred to a future version. The unresolved question is whether v0.1.1 or v0.2 should add a minimal compound-action contract — for example, an explicit "all or none" attribute on action sequences with declared rollback semantics — or whether compound action work requires substantially more design before any version of it is committed to the protocol. Implementations of v0.1 will produce useful evidence either way.

18.5 Failure category taxonomy

The seven categories in §9.2 — authorization, availability, conflict, policy, validation, execution, other — are a reasoned first cut. Are they sufficient across real application flows? Should rate_limit be a separate category or a subtype of availability? Should a category exist for failures caused by external dependencies the user cannot control (third-party API outages, network failures)?

18.6 Access mechanism specificity

§10.3 names the required access property without prescribing a specific cryptographic construction. Should v0.1 publish a recommended construction as a non-normative companion document, to prevent the first wave of implementations from each inventing incompatible mechanisms? Or is mechanism diversity acceptable in v0.1 because the property is what matters and the implementations will converge through ecosystem pressure?

18.7 Artifact lifecycle obligations

§7.4 establishes the surface-artifact boundary but leaves artifact lifecycle to applications. The position taken in v0.1 is that imposing protocol-level obligations on artifact storage, retention, or accessibility would push SSP from being a surface protocol toward becoming a backend standard. Artifacts persist according to application-defined rules; SSP governs the boundary, not the contents.

This question is included for public review only because the position may have edge cases — for example, artifacts produced by surface actions where the user has no other path to reach them, or artifacts whose existence is the entire purpose of the action that produced them. The current spec treats these as application concerns. Pushback is welcome.

18.8 Choreography across long-form authoring, multi-agent orchestration, and approval gates

§11.4 names three harder cases. Each has unresolved questions. For long-form authoring: how does the surface lifecycle reconcile with an in-progress artifact that is the user's primary workspace? For multi-agent orchestration: should surfaces exist for showing agent reasoning state separately from agent-produced artifacts? For approval gates: how does v0.1's action-window mechanic interact with high-stakes approvals where the action needs to remain valid for hours or days but the underlying state may drift?

18.9 Shareable durable surfaces

§12 defers shareable durable surfaces to a future primitive. The unresolved question is sequencing: which sub-problem of shareability must be designed first to make the rest tractable — durability (storage and identity), consent (declaration and revocation), citation (stable reference), or social convention (adoption pattern)? The dependency order matters because committing to one set of decisions constrains the others.

18.10 Governance

Should SSP become an open working draft with multi-party authorship, an open-source repository with reference implementation, or remain a Curated Future-authored specification until it has been implemented in production? Each path has different obligations and different timelines.

19. Changelog

v0.1-draft — April 2026

Initial public draft.

Defines the private session surface for language-user interfaces, with time-bounded action windows, the tap-down intent rule, refresh-on-request with intent-oriented labels, structured execution-failure handoff, private non-shareable access scoping, and a defined relationship between session surfaces and durable artifacts. Distinguishes private session surfaces from future shareable durable surfaces (§12) and explains why they are separate primitives. Defines language-user interface and surface origin as key terms (§4). Names read-consequential actions as a category alongside write-consequential ones (§4). Specifies modality-neutral rules for communicating remaining validity, with countdowns positioned as the canonical visual UI pattern (§8.5). Adds refresh disclosure of material change as a SHOULD (§8.6). Establishes the artifact concept and surface-artifact boundary (§4, §7.4), including rules for re-instantiating surfaces from existing artifacts (§7.4.4). Specifies long-running execution semantics for cases where execution time exceeds the action window or session lifetime (§9.6). Defines an audit trail boundary that makes the load-bearing intent timestamp auditable without prescribing audit format (§9.7). Acknowledges that access scoping cannot prevent disclosure through screenshots, screen sharing, or local device compromise (§10.1). Establishes guidance on compound user intent and surface composition, recommending compound surfaces with internal orchestration over chains of independent SSP actions (§5.3, §11.5). Clarifies that system-initiated conversational turns may wake idle sessions, with attribution requirements (§6.1). Adds an enterprise-context worked example covering incident response (§16). Adds versioning to the design-pressure list for shareable durable surfaces (§12). Clarifies that action windows govern actions, not options within actions: a single selection action with multiple alternatives carries one window, not N (§8.2.1, §13). Establishes that surface destruction propagates to the surface origin and that origins should discard ephemeral state while retaining only what audit demands (§7.3). Refines the tap-down intent rule for actions presenting options — the canonical timestamp is the moment of action commitment, not the option selection (§8.4). Uses "tap-down intent timestamp" consistently to link audit obligations to §8.4's load-bearing fact.

Companion to the essay After the Page, which makes the architectural argument this protocol attempts to operationalize.

20. Contact and feedback

This is a protocol draft for a substrate that affects the public, so its development should be public too. Comments, objections, counter-proposals, implementation reports, and substantive critiques are welcome in the comment thread on this spec's post at curatedfuture.com.

Feedback in the thread becomes part of the body of discourse around the protocol. Future versions of SSP will reference and respond to specific arguments raised there, and the visible record of pushback and refinement is itself part of how a public protocol earns legitimacy.

Private notes can be sent to the author via the contact information at curatedfuture.com, but the thread is the preferred channel for any feedback intended to inform v0.2 or to be heard by other implementers and reviewers.