v0.2 Draft: Private Session Surfaces, Shareable Durable Surfaces, and the Session as Authoring Venue

Part of a coordinated release

This is one of three protocol drafts being published together: SSP v0.2 (this document), ACP v0.1 (the Agent Compact Protocol), and RCP v0.1 (the Runtime Compact Protocol). The three specs are intended to be read together as a coordinated architectural proposal. An architectural overview introduces the five-protocol architecture: SSP, ACP, RCP, AAP (the Agent Attestation Protocol), and EPP (the Event Propagation Protocol). Three of the five are included in this coordinated release; AAP and EPP are named throughout but not yet drafted. SSP v0.2 can be read standalone, but readers wanting the full picture should start with the overview.

SSP v0.1 published April 27, 2026, and remains the reference for readers concerned only with the private session surface primitive in single-application contexts. v0.2 supersedes v0.1 for implementers; v0.1 readers will find most v0.1 mechanics carried forward unchanged (see §4 for the carry-forward inventory and §20 for the v0.1→v0.2 section mapping).

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. It also defines the shareable durable surface — a structured artifact authored inside a session and designed for sharing, citation, archival, or asymmetric retention by multiple parties. Action validity inside a drift-prone session remains the core operating principle; v0.2 extends that principle to a new class of action (the authorization of inter-agent commitments) and to a second primitive (the shareable durable surface).

SSP 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, inter-agent compact authorization, 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, invoke actions against external systems, or render the terms of an agreement the user is being asked to authorize.

The most important rule from v0.1 carries forward unchanged: 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.

SSP is the surface protocol — where users and agents meet, where consequential actions are reviewed and committed, and where inter-agent compacts are authored. It is not a compact protocol. The compact family — ACP, RCP, AAP, and EPP — addresses what crosses the boundary between agents, where the interaction is hosted, what makes an entity a legitimate agent, and how events propagate across the mesh of compacts. SSP is the venue protocol that those compacts are reviewed and authorized inside. The relationship is composition, not membership.

[Changes from v0.1: extended scope statement to include shareable durable surfaces and inter-agent compact authorization; named SSP's relationship to the compact family explicitly; preserved the v0.1 core operating principle.]

2. What SSP is not

SSP is deliberately narrow.

SSP is the surface protocol, not a rendering specification, a transport specification, or a model-orchestration specification. It is the venue protocol, not a compact protocol; the compact family (ACP, RCP, AAP, and EPP) governs what crosses inter-agent boundaries, where interactions are hosted, what makes an entity a legitimate agent, and how events propagate across the mesh of compacts. SSP is a surface protocol for conversational-era applications, not a replacement for the public commons of pages, documents, and durable web resources that the page era produced.

The granular inventory of what is in scope, out of scope, and deferred is in §5.

[Changes from v0.1: §2 condensed to a philosophical statement plus a pointer to §5; the granular list of deferrals lives in §5.2 and §5.3 to avoid duplication.]

3. Design stance

Four commitments shape this draft. The first three carry forward from v0.1 unchanged. The fourth is new in v0.2 and resolves a question v0.1 left open.

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. In inter-agent contexts, the same session may also be the venue where the user reviews and authorizes commitments that will be enforced across future interactions.

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 separates private session surfaces from shareable durable surfaces. Private session surfaces are optimized for privacy, freshness, trust, and action. Shareable durable surfaces are optimized for stability, addressability, consent, citation, integrity, attribution, and long-term meaning — including, in the bilateral case, asymmetric retention by multiple parties. Those are different design centers. They deserve different primitives. v0.2 specifies both.

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. Users authorizing an inter-agent commitment should not encounter terms that have shifted between rendering and authorization.

The action window, the tap-down intent rule, refresh-on-request, conversational failure handoff, and the compact rendering integrity requirement (§17.2) all follow from this stance.

3.4 Persistence by composition, not by primitive

Sessions remain non-persistent by rule. Persistence is not a property the SSP session offers; it is a property that emerges from the chain of compacts and the artifacts they govern.

This commitment resolves a question v0.1 left open and makes explicit what v0.1's structure already implied. The continuity users need across sessions does not come from any single session being made durable. It comes from durable artifacts (§7.4) and from the chain of compacts that govern interactions over time (ACP). A session is a bounded interaction. What persists is what the session authored: artifacts, compacts, and the records each retains under its own protocol.

Why this matters architecturally: a session that remembers everything is not neutral. The party that owns the memory shapes what the session is for. A user-owned session remembers in service of the user. A corporate-owned session remembers in service of the corporation. Both fit the word "session." They are not the same substrate.

SSP's answer is that sessions do not own memory at all. Memory lives in artifacts the user controls and in compacts the user has authored. The session is the venue where the user's intent meets the world; it is not the place that remembers what happened. When a session ends, it ends. What survives is what was committed to artifacts, what was recorded as compact terms, and what the runtime hosting the session was contractually permitted to retain.

This is consistent with v0.1's stance and elevates the implicit choice to a design commitment. Implementers reading v0.2 should understand that persistence is not a feature SSP can be configured to provide; it is a structural property the architecture distributes across SSP, ACP, and RCP, with each protocol carrying its piece. SSP's piece is non-persistence. The mechanics that make this workable across sessions — artifact-bound re-instantiation (§7.4.4), compact-history-aware sessions ([ACP §X]), and standing runtime compacts ([RCP §X]) — are specified in their respective sections.

The normative form of this commitment is stated in §6.3 (session lifecycle): SSP sessions MUST NOT persist beyond their session lifetime.

[Changes from v0.1: §3.4 is new in v0.2; §3.1, §3.2, §3.3 are minor edits to acknowledge inter-agent context and shareable durable surfaces.]

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. A session may be used to think with an LLM, to coordinate work, to act on the world through structured surfaces, or to author commitments with other agents — all of these are uses of the same primitive. The session is the venue; what happens inside it varies.

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, compact review surface, 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. 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 is always written in full to distinguish it.

Shareable durable surface

A structured artifact authored by one or more sessions — single-agent or inter-agent — designed for some combination of sharing, citation, archival, public reference, or asymmetric retention by multiple parties. Its lifecycle is independent of any session that created it.

A shareable durable surface is a separate primitive from the private session surface. It is not a private surface with a share button; it is a durable artifact with its own structure, addressability, versioning, and consent semantics. Single-author shareable durable surfaces (one party authors; many parties may read) are a specialization. The bilateral shareable surface (two parties hold permission-bound copies whose retention is asymmetric per ACP compact) is the more general structure that v0.2 specifies in §12.

The integrity property — that paired copies of a bilateral shareable surface share canonical content even when the retained slices differ — is SSP's contribution. The retention asymmetry that determines what each party retains is governed by the ACP compact under which the surface was authored.

Artifact

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

Examples include documents, reports, files, records, images, dashboards, saved plans, tickets, invoices, calendar events, compact records, and other application-defined or protocol-defined objects. Shareable durable surfaces are themselves artifacts under this definition; ACP compacts are also artifacts; runtime compacts ([RCP §X]) are artifacts.

This distinction is important. SSP defines the lifecycle of session surfaces; it specifies the structure and integrity of shareable durable surfaces; it does not define the storage, retrieval, or governance of arbitrary application artifacts. A surface may be destroyed when a session ends while artifacts created or modified through that surface persist under their own application-defined or protocol-defined rules. The relationship between session 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, authorizes an inter-agent commitment, or otherwise carries consequence outside the surface itself.

Booking an appointment, sending a message, approving a document, transferring value, submitting an order, changing a configuration, or committing an inter-agent compact 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 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, agent records, compact registries, 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. In the session-as-authoring-venue case (§17), the origin of a compact-review surface is the user's agent acting on the user's behalf to render the proposed compact for review.

v0.2 names surface origin as a concept and recommends that implementations preserve it (§18.2). Full provenance semantics — chains of origin across nested agents, attestation, and trust delegation — depend on AAP and are deferred there.

Compact

A structured artifact governing the terms of a bounded interaction between two parties — typically two agents, sometimes including the user as a reviewer or party. A compact is bilateral, machine-readable, signed by both parties, and retained by both. Its terms specify what context enters the interaction, what is retained on each side, what derivation rights each party has, how context may propagate, when retention expires, and how the compact may be revoked.

Compacts are governed by ACP. SSP references compacts where they intersect with the surface protocol — most importantly, where a session is used as the venue for compact review and authorization (§17). The full definition of a compact, its dimensions, and its negotiation protocol is in [ACP §3] through [ACP §6].

A compact is an artifact under SSP's definition; the surface that renders a compact for user review is a session surface; the bilateral shareable surface that may be produced as the compact's record is a shareable durable surface.

Runtime accountability

The property that the runtime hosting an SSP session is mutually accountable to the parties involved in the session — including the user, any agents acting on the user's behalf, and any counterparty agents whose interactions are reviewed inside the session.

Runtime accountability is a precondition for the session-as-authoring-venue use case. A user authorizing an inter-agent compact inside a session must be able to trust the runtime to render the compact accurately, not to surveil the review process beyond what the runtime compact permits, and not to retain session state beyond what is mutually agreed. The mechanisms that establish runtime accountability — host designation, host capabilities, host guarantees, audit mechanisms, and visitor recourse — are specified by RCP. v0.2 names runtime accountability as a concept and points to [RCP §3] through [RCP §5] for the mechanics.

[Changes from v0.1: replaced "future primitive" entry for shareable durable surface with full definition; added compact, runtime accountability as new defined terms; expanded action and surface origin to acknowledge inter-agent contexts; expanded artifact to acknowledge compacts and runtime compacts as artifacts; otherwise carry-forward.]

5. Scope of v0.2

SSP v0.2 expands the scope of v0.1 to include shareable durable surfaces and the session-as-authoring-venue use case, while preserving v0.1's focus on action validity inside private session surfaces.

5.1 In scope

• Session lifecycle semantics, including substrate dependence as a named (but not specified) precondition.
• Surface lifecycle semantics for private session surfaces.
• Shareable durable surface specification: structure, lifecycle, addressability, versioning, integrity across paired artifacts in the bilateral case.
• 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 session surfaces.
• Access scoping for shareable durable surfaces, including the bilateral case.
• The relationship between session surfaces and artifacts, including shareable durable surfaces and compact records as specific artifact types.
• Chat-surface choreography, including the session-as-authoring-venue pattern.
• The integrity requirements that SSP imposes on compact rendering when a session is used to review and authorize an inter-agent compact.

5.2 Out of scope

• The terms of inter-agent compacts (governed by ACP).
• The retention asymmetry that determines what each party retains from a bilateral shareable surface (governed by ACP).
• The runtime hosting the session (governed by RCP).
• What makes an entity a legitimate agent (governed by AAP).
• Reconciliation when parties dispute compact terms or accuse each other of violations (deferred across the compact family).
• Atomic multi-step action semantics with rollback on partial failure (see §5.3).
• Cross-session state transfer or session migration (consistent with §3.4's persistence-by-composition commitment).
• Multi-user collaboration on a single session surface (distinct from the bilateral shareable surface case, which is two parties holding permission-bound copies).
• A conformance test suite.
• Durable artifact lifecycle beyond the surface relationship defined in §7.4 and the shareable durable surface specification in §12.
• Citation, archival, and revocation semantics for shareable durable surfaces beyond what §12 specifies (full treatment depends on the public knowledge commons evolving its own conventions and on ACP's revocation dimensions).
• Rendering and component specifications.

5.3 Why these deferrals

Each deferred concern is a real problem. None is this version's problem. Some are harder than the problems v0.2 solves.

Four deferrals deserve specific note because they intersect with v0.2's new scope and implementers are most likely to confront them immediately.

Compact terms and retention asymmetry. SSP v0.2 specifies the surface that renders a compact for review and the integrity properties of the artifacts the surface produces. It does not specify what terms a compact may include, what defaults apply, or how retention asymmetry between parties is enforced. These are ACP's concerns. The reason for the split is that the compact is a contract; the surface is the venue where the contract is reviewed. Conflating them would re-bundle interaction with negotiation, which is exactly the bundling the page era's primitive demonstrated to be costly.

Runtime hosting. Where the session runs is RCP's concern. SSP v0.2 names runtime accountability as a precondition for the session-as-authoring-venue use case but does not specify how runtime accountability is established. The reason is the same: the runtime question is itself a negotiable architectural concern, and a half-designed answer inside SSP would foreclose the design space RCP is trying to keep open. SSP's mechanics are correct regardless of which runtime hosts the session; the trustworthiness of those mechanics depends on the runtime, which RCP addresses.

Compound action atomicity. v0.1's §5.3 named this as deferred and §11.5 specified the working answer (compound user intent SHOULD be expressed as a single SSP action with internal orchestration). v0.2 carries this position forward unchanged. The unresolved question is what evidence from v0.1 implementations would shift the question from "deferred" to "ready to specify" — articulated in §19.4 as an open question with a concrete evidence threshold.

Agent capability requirements. What makes an agent sophisticated enough to represent a user faithfully in compact authorization is a separate spec's concern, currently deferred. v0.2 names this dependency where the session-as-authoring-venue use case intersects with it, but does not attempt to specify capability requirements. A surface that renders a compact for review is meaningful only if the agent presenting that surface is genuinely the user's; the protocol's mechanisms cannot, by themselves, distinguish a genuine user-agent from a captured one. This is the wolf-in-agent's-clothing problem and it is where the compact family meets the limits of what protocol mechanics alone can guarantee.

5.4 What v0.2 does not change

Most of v0.1 carries forward unchanged. The carry-forward inventory is in §4 of this draft (key terms) and §6 through §11 (mechanics). The substantive additions are §3.4 (persistence by composition), the new defined terms in §4 (shareable durable surface, compact, runtime accountability), the substrate paragraph in §6.5, the bilateral case extension in §7.4, the integrity requirement in §10.1 and §17.2, the §12 shareable durable surface specification, and the §17 session-as-authoring-venue worked example. Everything else is v0.1.

[Changes from v0.1: §5.1 expanded to include shareable durable surfaces and the authoring-venue use case; §5.2 expanded to acknowledge ACP/RCP/capability boundaries and to defer reconciliation; §5.3 added two new deferral notes (compact terms; runtime hosting); §5.4 is new and explicitly inventories what does not change, to support readers of v0.1 who need to see the delta.]

6. Session lifecycle

6.1 Session boundaries

A session begins when the user enters the SSP-speaking application in an authenticated context. A session ends when one of the following occurs:

• The user explicitly ends the session.
• The session times out under application-defined inactivity rules.
• The user signs out, the authentication context is invalidated, or the session is forcibly terminated by the application or runtime.
• The user's device or runtime context is lost in a way the application treats as session-ending.

A session is not a tab, a window, or a URL. A user may have one session across multiple tabs or devices, or multiple sessions inside one tab, depending on the application's design. SSP does not prescribe the mapping between sessions and the surrounding user-agent affordances.

6.2 Session identity

A session has a session identifier. The session identifier is opaque to the user and is not a URL.

The session identifier MUST NOT be reused across users. The session identifier MUST NOT be derivable from public information. The session identifier MUST be invalidated when the session ends.

6.3 Sessions MUST NOT persist beyond their session lifetime

When a session ends, its session-scoped state is destroyed. Private session surfaces, conversational history held only in session state, in-flight actions that have not been committed, and any other session-scoped objects MUST NOT survive the end of the session as session-scoped objects.

This rule is normative and load-bearing. The continuity users may want across sessions is provided by artifacts (§7.4), by ACP compacts where applicable, and by the user's own records of what was authored in the session — not by extending the session.

Applications MAY offer session resumption affordances — the ability to begin a new session that loads prior artifacts, recent context, or a summary of recent interactions. A resumed session is a new session. It does not inherit the prior session's identifier, in-flight actions, or unauthorized state. It begins with whatever artifacts and compacts the user authorizes it to load.

6.4 Session boundaries are user-meaningful

A session boundary is a meaningful event for the user, not just an implementation detail. When a session ends, the user should know it ended. When a new session begins, the user should know it is new.

This requirement is not about modal dialogs or interrupting the user. It is about not presenting a continuous-feeling experience that conceals a session boundary the user would care about. If an action authorized in a prior session would no longer be valid in the current session, the application MUST NOT silently fire it. If a surface from a prior session is no longer live, the application MUST NOT continue to render it as if it were.

6.5 Substrate is a precondition

SSP's mechanics are correct only when the runtime hosting the session is mutually accountable to the parties involved. The user authorizing an action — and especially the user authorizing an inter-agent compact (§17) — must be able to trust the runtime to render surfaces accurately, to enforce action windows honestly, to terminate sessions cleanly, and not to retain session state beyond what is mutually agreed.

What makes a runtime mutually accountable, what guarantees a runtime must declare, and what recourse a party has when those guarantees are violated are governed by RCP. SSP does not specify these mechanics. SSP specifies that they are necessary.

A runtime that does not satisfy the conditions specified in [RCP §3] through [RCP §5] cannot host SSP-compliant sessions for any use case where runtime trustworthiness matters — which, in practice, is most of them.

[Changes from v0.1: §6.3 adds the normative MUST NOT and the non-persistence resolution; §6.4 is unchanged in substance, lightly edited; §6.5 is new in v0.2 and names runtime accountability as a precondition with a pointer to RCP.]

7. Surface lifecycle

7.1 Surfaces are session-scoped by default

A private session surface exists inside a session. It is created in response to conversational intent or application logic. It is rendered to the user. It accepts input, displays state, or invokes actions. It is destroyed when the surface is retired or when the session ends, whichever comes first.

A private session surface MUST NOT outlive its session. Implementations MUST NOT cache, persist, or restore private session surfaces across sessions as if they were durable.

7.2 Surface retirement

A surface may be retired before its session ends. Retirement may be explicit (the user dismisses the surface, the application closes it) or implicit (the surface's purpose is fulfilled, a superseding surface replaces it, the conversational thread moves on in a way the application treats as retiring the prior surface).

Retired surfaces are no longer live. Their actions cannot fire. Their state is not authoritative. Implementations MUST NOT re-render a retired surface as if it were live; if the user returns to a prior surface, the application must either re-instantiate it as a new surface or render it explicitly as a historical view.

7.3 Surface refresh

A surface may be refreshed while still live. Refresh updates the surface's depicted state to reflect current world state. Refresh may be triggered by the user, by the application on a defined cadence, or in response to an event the application recognizes as relevant to what the surface depicts.

Refresh is distinct from re-rendering for display reasons. A surface that re-renders because the user resized a window has not been refreshed. A surface that re-fetches calendar slots and shows a new set of availability has been refreshed. Refresh resets the action window for any actions on the surface (§9.3).

7.4 Surfaces and artifacts

A private session surface is not an artifact. It is a transient instrument. Artifacts created or modified through a surface persist under their own application-defined or protocol-defined rules.

7.4.1 Surfaces may bind to artifacts

A surface may be bound to one or more artifacts. The surface renders the artifact's current state, mediates user actions against the artifact, and ends when the session ends. The artifact persists.

When a surface is bound to an artifact, the surface depicts a view of the artifact, not the artifact itself. Two surfaces in two different sessions may bind to the same artifact and depict it differently.

7.4.2 Artifact lifecycle is application-defined

SSP does not specify how application artifacts are stored, retrieved, versioned, or governed. A document, a saved plan, a ticket, a calendar event, an invoice — these are application artifacts and their lifecycles belong to the application or to the system the application interacts with.

7.4.3 Compact records and runtime compacts are artifacts

A compact record produced by an inter-agent negotiation (ACP) is an artifact under this spec. A runtime compact (RCP) is an artifact under this spec. Both persist under their respective protocols, not under SSP.

When a session is used to review and authorize a compact (§17), the surface that renders the proposed compact for review is a session surface. The compact record produced when the user authorizes is an artifact. The session surface ends with the session. The compact record persists as governed by ACP.

7.4.4 Artifact-bound re-instantiation

A new session may load an existing artifact and render a new surface bound to that artifact. This is how continuity is provided across sessions: the user returns to the artifact, not to the prior session.

The new surface is a new surface. It does not inherit the prior session's action windows, in-flight intent, or session-scoped state. It begins fresh, with whatever the artifact contains and whatever the application or compact history makes available to it.

7.4.5 Shareable durable surfaces are a distinct artifact class

A shareable durable surface is an artifact, but it is an artifact with structural and integrity properties beyond what arbitrary application artifacts are required to have. It is addressable. It is versioned. It carries consent semantics. In the bilateral case, it carries the integrity property that paired copies share canonical content even when retained slices differ. The full specification is in §12.

A shareable durable surface MAY be bound to a session surface during authoring. The session surface ends with the session. The shareable durable surface persists under §12's rules.

[Changes from v0.1: §7.4.3 is new and names compact records and runtime compacts as artifacts; §7.4.5 is new and names shareable durable surfaces as a distinct artifact class with a forward reference to §12; §7.4.1, §7.4.2, §7.4.4 are minor edits to acknowledge inter-agent and bilateral cases.]

8. Action windows

8.1 The action window rule

Every action declared on a surface MUST have an action window.

The action window is the duration during which the action, once rendered, may fire. The window begins when the surface depicts the action as available. The window ends when the declared duration elapses or when the surface is retired or refreshed.

After the window ends, the action MUST NOT fire. Any attempt to invoke an expired action MUST be treated as a request to refresh the surface against current world state.

8.2 Why action windows

A surface depicts a slice of the world at the moment the surface was generated. Between generation and invocation, the world may drift. The slot that was available may be taken. The price that was quoted may have changed. The compact terms that were rendered may have been revised. The contractor whose record was retrieved may have updated their availability.

The action window protects the user from acting on stale state. It also protects the executing system from receiving actions whose preconditions no longer hold. The window is the protocol's commitment that what the user saw is what the user acted on.

8.3 Window duration

Window duration is action-specific. A booking action against a calendar with five-minute slot granularity may have a window of seconds. A document approval against a stable artifact may have a window of minutes or hours. A standing-compact authorization may have a window of days.

SSP does not prescribe specific durations. SSP requires that durations be declared, that they be honest with respect to how fast the underlying world state can drift, and that the user be able to perceive the window's bound where the bound is short enough to matter (§8.5).

8.4 The tap-down intent rule

When a user invokes an action whose window is about to expire, the application MUST treat the user's invocation as the moment of intent. The application MUST honor the action against the state the user saw, unless one of the following conditions applies:

• The world state has changed in a way that makes the action materially impossible (the slot is no longer available; the artifact no longer exists; the counterparty has revoked their participation).
• The world state has changed in a way that makes the action materially different from what the user authorized (the price has changed beyond a declared threshold; the compact terms have been revised).
• Honoring the action would violate access scoping (§11) or the integrity requirement for compact-rendering surfaces (§10.4).

Where the application refuses to honor the user's tap-down intent, the refusal MUST be reported to the user via conversational failure handoff (§10.2), with the specific reason for refusal made available. The application MUST NOT silently fail or silently substitute changed state.

This rule is a design choice in favor of the human. The user should not be punished for acting at the edge of a window because the application's backend was slow. The protocol's account of the user's intent is anchored at the moment the user committed to the action, not at the moment the system finished receiving it. Refusal is permitted only where honoring the action would be worse than refusing it — because the action is impossible, materially different, or a security violation. Anything else is the application's processing latency, which the protocol does not accommodate as a basis for refusal.

The tap-down rule does not relieve the application of the responsibility to validate the action against world state. It specifies that validation is against the state at the moment of intent, and that the named exceptions are the only valid grounds for refusal.

8.5 Window visibility

Where the window is short enough that a user might miss it, the surface SHOULD make the window's bound perceptible. A countdown, a progress bar, a relative-time indicator, or other affordance is appropriate. The point is not to alarm the user but to ensure the user is not surprised when an action expires.

For windows long enough that the user is unlikely to encounter expiration in normal use, visibility is not required. The window still applies; the user simply will not see it elapse.

8.6 Windowing is per-action, not per-surface

A surface may host multiple actions with different action windows. Each action's window is independent. Refreshing a surface refreshes the action windows of all actions on that surface; retiring a surface ends them.

A single action may also span multiple surfaces if the application architecture warrants it. The action's window applies to the action, regardless of which surface depicts it.

[Changes from v0.1: §8.3 acknowledges compact authorizations as an action class with their own typical window duration; §8.4 rewritten in v0.2 to make tap-down a MUST with named exceptions for material impossibility, material change, and access/integrity violations — replacing v0.1's SHOULD, which left a loophole the §3.3 humane-over-machine-tidy commitment did not warrant. Otherwise carry-forward.]

9. Refresh and recovery

9.1 Refresh as the response to expiration

When an action has expired, the application MUST refresh the surface against current world state before any equivalent action can fire.

Refresh re-renders the surface with current state. New action windows begin. The user sees what is now available, which may be the same as what they saw before, may be different in detail, or may no longer include the action they were attempting.

9.2 The refresh contract

Refresh is not silent. The user MUST be able to perceive that a refresh has occurred, especially if the refresh changes what the user is being asked to authorize.

This requirement matters most when the refresh changes consequential state — a price, a compact term, an available slot, an authorization scope. A surface that quietly mutates between the user's first read and the user's invocation is the failure mode this rule prevents.

For low-stakes refreshes (a list reorders, an inventory count updates), perceptibility may be satisfied by ordinary UI cues. For high-stakes refreshes (a price changes by more than a threshold, a compact term changes), the application SHOULD make the change explicit and require the user to re-engage with the changed state before the action may fire.

9.3 Refresh resets action windows

Refresh resets the action windows of actions on the refreshed surface. The new windows begin at the moment of refresh. Prior windows are extinguished.

This rule prevents the failure mode where a surface is refreshed but actions retain the windows they had under prior state, allowing the user to fire an action that was valid against state the surface no longer depicts.

9.4 Refresh-on-request

The user MAY request a refresh at any time the surface is live. Implementations SHOULD provide a perceptible refresh affordance, especially on surfaces where the user might reasonably wonder whether the depicted state is current.

Refresh-on-request is the user's instrument against staleness. The application's automatic refresh cadence is the default; the user's request overrides it.

[Changes from v0.1: §9 carries forward unchanged in substance. Light edits to §9.2 to acknowledge compact terms as a class of consequential state subject to the rule.]

10. Execution failure handoff

10.1 Execution may fail

When an action fires, it is handed to the execution layer. The execution layer may succeed, fail, partially complete, or hang. SSP does not specify how the execution layer behaves; SSP specifies how failure returns to the session.

When an action fails or partially completes, the application MUST surface the failure to the user inside the session. The user MUST NOT be left inside a surface that depicts a successful state when the action did not succeed. The user MUST NOT be left inside a surface that depicts no state when the action's outcome is uncertain.

This requirement applies to all action classes, including read-consequential actions and compact authorizations. A compact authorization that the runtime accepted but ACP-side commitment did not complete is a partial failure under this rule. The user MUST be returned to a state where the partial commitment is visible and the path forward is conversational.

10.2 Conversational failure handoff

The session is the venue for failure recovery. When an action fails, the application's response is not a generic error dialog. The application returns control to the conversational layer, names what happened in language the user can act on, and offers the user the next step.

The next step may be a retry, a refresh, a different action, a clarification, or a graceful exit. The application's job is not to recover automatically; it is to put the user in a position to recover with full information.

10.3 Failure that crosses a boundary

When an action involves a counterparty — an external system, an inter-agent compact, a remote runtime — failure may originate on the other side of a boundary. The application MUST report what is known about the failure honestly. If the application does not know whether the action succeeded on the counterparty side, the application MUST say so. Manufacturing a confident state in the absence of information is the failure mode this rule prevents.

In the inter-agent case, the application's account of failure may depend on what the runtime compact ([RCP §X]) and the agent compact ([ACP §X]) specify about cross-boundary signaling. SSP requires that whatever those protocols make available to the application be returned to the user. Where they do not provide enough signal for the application to know the outcome, the application's report to the user reflects that uncertainty.

10.4 The integrity requirement for compact-rendering surfaces

A surface that renders a compact for user review MUST depict the compact accurately. The terms shown to the user MUST be the terms the user is authorizing. Any drift between the rendered terms and the committed compact is a failure of the surface and MUST be treated as one.

This requirement is normative. It applies to the rendering of compact terms before authorization, to the compact record produced upon authorization, and — in the bilateral case — to both parties' paired copies of the shareable durable surface that records the compact.

The mechanisms that enforce integrity are partly SSP's responsibility (the surface) and partly ACP's (the compact record itself). SSP's contribution is that the surface depicting the compact is the canonical representation the user reviewed; ACP's contribution is that the record retained on each side faithfully represents what was authorized. Where the two protocols meet, neither may relax the integrity requirement.

10.5 Session death during execution

An action may fire successfully into the execution layer and then encounter session death before the execution layer's outcome returns to the user. Causes include: device power loss, network failure, runtime termination, forced authentication invalidation, or any other event that ends the session while execution is in flight.

The execution layer's behavior in this case is outside SSP's scope; SSP specifies how the user, in a subsequent session, can recover the outcome.

Where the action was bound to an artifact (§7.4.1), the execution outcome MUST be recorded against the artifact, not against the dead session. A new session that loads the artifact (§7.4.4) MUST surface the outcome to the user — success, failure, partial completion, or unknown status — as part of the artifact's state at load time.

Where the action was a compact authorization (§7.4.3), the outcome MUST be recorded against the compact record. A new session that loads the compact MUST surface the outcome. Where the runtime compact ([RCP §X]) and the agent compact ([ACP §X]) provide signaling that distinguishes "authorized but not committed" from "committed," the application MUST report which state was reached.

Where the action was not bound to a durable artifact, the outcome may be unrecoverable. Implementations SHOULD treat unbound consequential actions as a failure mode to design against; the architectural answer is to bind consequential actions to artifacts (§7.4.1) so that session death does not erase the user's record of intent.

The application MUST NOT silently retry an action whose outcome is unknown. Retry, if it is appropriate, is a user-mediated decision in the new session, not an automatic application behavior.

[Changes from v0.1: §10.1 expanded to include compact authorizations as a class of action subject to the rule; §10.3 added to handle cross-boundary failure reporting with pointers to ACP and RCP; §10.4 is new in v0.2 and is load-bearing for the session-as-authoring-venue use case; §10.5 is new in v0.2 and resolves the session-death-during-execution race condition by routing recovery through artifact-bound re-instantiation, consistent with §3.4's persistence-by-composition stance.]

11. Access scoping

11.1 Surfaces are scoped to the user

A private session surface is scoped to the authenticated user whose session it lives in. The surface is not shareable. The surface is not addressable from outside the session. The surface is not visible to other users, other sessions of the same user, or any party not present in the session.

The session identifier (§6.2) is the proximate enforcement mechanism. A request that does not present a valid session identifier MUST NOT receive surface state. A request that presents a session identifier belonging to a different user MUST NOT receive surface state.

11.2 What scoping does not protect against

Access scoping prevents unauthorized parties from reading or acting on surface state. It does not prevent a user from screenshotting a surface and sharing the image. It does not prevent a user from describing the surface's contents to another party. It does not prevent a runtime that hosts the session from observing surface state to the extent the runtime compact permits.

These are not failures of the scoping rule. They are the boundaries of what scoping can do. The rule prevents the protocol-level leak; the other concerns are addressed by user behavior, by RCP's runtime accountability mechanisms, and by AAP where applicable.

11.3 Shareable durable surfaces have different scoping

Shareable durable surfaces are designed to be shared. Their access semantics are specified in §12 and depend on the consent model the authoring session selected. In the bilateral case, each party's copy is scoped to that party under the retention asymmetry the ACP compact specified.

A shareable durable surface is not a private session surface with a relaxed scoping rule. It is a different primitive with its own scoping semantics from creation. Implementations MUST NOT convert a private session surface into a shareable durable surface by relaxing scoping; the conversion, if it is meaningful at all, requires authoring a new shareable durable surface with explicit consent and the correct integrity properties.

11.4 Surface origin and access scoping

In multi-agent or third-party-tool contexts, the surface origin (§4) may be distinct from the host application. Access scoping in these contexts is more involved than in single-application cases.

v0.2 takes the following position: the host application is responsible for enforcing access scoping for any surface rendered inside its session, regardless of origin. A third-party tool or embedded agent that generates a surface is bound by the host application's scoping rules; the host application does not relax those rules to accommodate the origin's preferences.

Where AAP is relevant — for instance, in determining whether a third-party origin is a legitimate participant — the dependency is named here and deferred to that spec.

11.5 Read-consequential actions are scoped by the same rule

Disclosure, computation against private data, and exposure of privileged content are actions under §4 and are subject to the access scoping rule. A surface that would disclose privileged data to a session whose authenticated user is not entitled to see that data MUST NOT render the disclosure, regardless of how the surface arrived in the session.

This rule prevents the failure mode where a surface generated in one context is rendered in another context whose access scope is narrower.

[Changes from v0.1: §11.3 extended to acknowledge bilateral shareable surfaces and the ACP retention asymmetry; §11.4 expanded to acknowledge multi-agent origins with a pointer to AAP; otherwise carry-forward.]

12. Shareable durable surfaces

12.1 The shareable durable surface as a distinct primitive

A shareable durable surface is a structured artifact authored inside a session and designed to persist beyond it, to be addressable, and to carry consent semantics. It may be authored by a single party or, in the bilateral case, by two parties under an ACP compact, where each retains a permission-bound copy and integrity is preserved across the pair.

A shareable durable surface is not a private session surface that has been made shareable. It is a different primitive with different design centers. Private session surfaces are optimized for privacy, freshness, trust, and action inside an ongoing session. Shareable durable surfaces are optimized for stability, addressability, citation, attribution, and meaning that survives the sessions that produced them.

The two primitives compose. A session may author a shareable durable surface. The session ends; the shareable durable surface persists. A new session may load a shareable durable surface and render a private session surface bound to it for further authoring or for review. The private session surface ends with its session; the shareable durable surface persists across all of them.

This separation is deliberate. Treating shareability as a flag on the private session surface — a "make this shareable" toggle — would compromise the privacy guarantees of the private surface and the durability guarantees of the shareable one. v0.2 specifies them as separate primitives with separate rules.

12.2 What a shareable durable surface contains

A shareable durable surface contains, at minimum:

• Canonical content. The structured content that the surface depicts. The canonical content is the authoritative representation of what the surface means.
• Authorship metadata. Who authored the surface, in what session, under what compact (where applicable). In the bilateral case, authorship records both parties.
• Versioning information. A version identifier, the immediate predecessor version (if any), and the relationship of this version to prior versions (revision, supersession, branch).
• Access semantics. Who may read the surface, under what conditions, with what attribution.
• Consent semantics. Who consented to the surface's existence at this version, and what the consent covered.

In the bilateral case, the surface additionally carries an integrity attestation that establishes pairing across both parties' copies. The attestation is required for the bilateral case and is specified in §12.5.

A shareable durable surface MAY contain additional fields — provenance chains, derivation history, citation forms, archival manifests — depending on the use case. SSP specifies the minimum; implementations and downstream protocols may extend it.

12.3 The single-author case

The single-author shareable durable surface is the baseline form. One party authors the surface; other parties may read it under the access semantics the author declared.

The surface has one canonical content, one authorship attestation, one set of access semantics, and one consent record. There is no paired copy, no retention asymmetry between authors, and no integrity attestation across copies, because there is only one authoritative copy.

A reader of a single-author shareable durable surface MAY retain a local cache, a citation, or a copy under their own application's rules. SSP does not govern what readers do with a surface they have read. SSP governs what the surface itself is — the authoritative artifact remains the author's, and readers consult it under its access semantics.

Most shareable durable surfaces in practice will be single-author: a user publishes a report, a researcher publishes a finding, an organization publishes a record. The single-author case is the analogue of the page-era document: one party writes, many parties read. What it adds beyond the page is consent semantics and versioning — the author can specify who may read, under what conditions, and what the relationship of each version is to its predecessors.

12.4 The bilateral case

The bilateral shareable durable surface is the structure produced when two parties author together under an ACP compact and each retains a permission-bound copy. It extends the single-author baseline with two structural additions: paired copies and retention asymmetry.

The two copies are paired. They share canonical content. They differ in what each party has retained beyond the canonical content, as governed by the compact.

The canonical content is the part of the surface that both parties have a contractual right to retain and that both parties' copies must depict identically. The retention asymmetry is the part of each party's copy that is permitted to differ — what one party retains and the other does not, what derivation each party may perform, what each party may propagate, and how long each party retains.

The canonical content is SSP's concern. The retention asymmetry is ACP's concern. SSP guarantees that canonical content is identical across paired copies. ACP guarantees that the retained slices on each side conform to the compact's terms.

The integrity of the pairing is what makes a bilateral shareable durable surface useful. If the two copies could drift in their canonical content, the contract would be unenforceable; each party would hold a different account of what was agreed, and disputes would resolve to whichever party's record was admitted as authoritative. The integrity attestation (§12.5) prevents this failure mode at the protocol level.

The bilateral case is where the architectural commitments of v0.2 are most consequential. A medical billing dispute, a contractor scope agreement, an insurance claim, a confidential consultation — each of these is the kind of interaction that produces a bilateral shareable durable surface, and each of these is where the absence of an integrity-preserving primitive in the page era forced parties to fall back on legal mechanisms with much higher friction.

12.5 Integrity across paired copies

Paired copies of a bilateral shareable durable surface MUST share canonical content. This is normative. An implementation that produces paired copies whose canonical content differs has not produced a bilateral shareable durable surface; it has produced two divergent artifacts that cannot serve the function the bilateral case requires.

The integrity attestation is the mechanism that establishes pairing. Both parties sign the canonical content at authoring time. Both parties' copies record the signature. A reader of either copy can verify, against the signature, that the canonical content has not drifted from what was authored.

The signing mechanism is not specified by SSP. It depends on the cryptographic stack the runtime makes available and on AAP's definition of what an agent must demonstrate to sign on behalf of a party. SSP specifies that a signing mechanism MUST exist and that it MUST attest to canonical content identity across paired copies.

Where the signing mechanism is not available — for instance, in early implementations operating on substrates that do not yet support the cryptographic primitives — implementations MUST NOT claim to produce bilateral shareable durable surfaces. They may produce single-author surfaces or paired copies under explicit weaker semantics, but the bilateral primitive as specified in v0.2 requires the integrity attestation.

This rule is strict for a reason. The bilateral shareable durable surface is the primitive that ACP-governed compacts compose with. If implementations are permitted to relax the integrity property, the compositions become unreliable, and the protocol's guarantees about what each party retained and what each party agreed to dissolve into application-level claims that cannot be verified across boundaries.

12.6 Versioning

A shareable durable surface is versioned. Every change to canonical content produces a new version with a new version identifier and a recorded relationship to prior versions.

A version is immutable. Once a version of a shareable durable surface has been signed and committed, its canonical content does not change. Subsequent edits produce new versions; they do not mutate the prior version.

Version relationships include:

• Revision. A successor version that supersedes its predecessor. Readers MAY be directed to the latest revision; the predecessor remains addressable for historical reference.
• Supersession. A successor version that explicitly retires its predecessor. The predecessor is no longer the canonical reference; readers SHOULD be directed to the successor.
• Branch. A successor version that does not retire its predecessor; both remain canonical, used for different purposes.

Versioning is consent-bound. In the single-author case, the author consents to each new version. In the bilateral case, a new version requires both parties' consent under the governing compact. Unilateral revision of a bilateral shareable durable surface is not possible under v0.2; an attempt by one party to revise without the other's consent produces a new artifact, not a new version of the existing one.

12.7 Addressability

A shareable durable surface MUST be addressable. The form of the address is not specified by SSP; it may be a URL, a content-addressable hash, a protocol-specific identifier, or another form appropriate to the runtime and the access semantics.

The addressability requirement is not a return to the page. A shareable durable surface address resolves to a structured artifact with consent semantics, not to a freely-readable document. Whether the address dereferences successfully for a given reader depends on the access semantics and on the reader's standing under those semantics.

The minimum requirement is that the address is stable across the lifetime of the version it identifies. A reader who holds the address of a specific version MUST be able to retrieve that version, subject to access semantics, for as long as the version persists.

12.8 Access and consent

Access to a shareable durable surface is governed by the access semantics recorded in the surface itself. Access semantics include:

• Who may read. The set of parties or classes of parties entitled to read the surface.
• Under what conditions. Authentication, attestation, time bounds, jurisdictional constraints, or other preconditions.
• With what attribution. Whether reading is logged, anonymized, attributed to the reader, or otherwise tracked.

Consent is the record of who agreed to the surface's existence at this version. In the single-author case, consent is the author's. In the bilateral case, consent is both parties', and the consent record references the governing ACP compact under which authorship occurred.

A shareable durable surface whose consent record is incomplete is not a valid shareable durable surface. Implementations MUST NOT publish, address, or treat as authoritative a surface lacking consent attestation appropriate to its case.

12.9 Revocation

Revocation of a shareable durable surface is partial under v0.2.

A party may revoke their own consent to a future-tense version: they decline to consent to revisions, supersessions, or branches that would extend the surface's lifetime. This form of revocation is fully specified by v0.2 and operates through ordinary versioning.

A party may attempt to revoke a past-tense version: they request that an existing version be retired or that paired copies be deleted. This form of revocation is partially specified. SSP requires that the protocol record the revocation request and that addressability of the revoked version be governed by the access semantics; implementations MAY honor revocation by ceasing to dereference the address, by marking the version as retired, or by other mechanisms appropriate to the runtime.

What revocation cannot do at the protocol level is recall copies already retained by counterparties whose retention rights were established under the governing compact. The recall of retained copies is governed by ACP's revocation dimensions and by the runtime accountability mechanisms specified by RCP. SSP's contribution is the version-level revocation; the chain-of-retention recall is downstream.

This deferral is a known limitation. It is the same limitation GDPR's right-to-be-forgotten encountered when applied across systems that retained derivatives of personal data. v0.2 does not solve it. v0.2 specifies what SSP can specify and names the rest as the compact family's concern.

12.10 What §12 does not specify

Citation conventions for shareable durable surfaces. The page era developed citation conventions over decades, and the shareable durable surface era will develop its own. v0.2 does not specify them.

Archival policy. How shareable durable surfaces are preserved beyond the lifetime of the systems that originally hosted them is an institutional question, not a protocol one. v0.2 names the durability property and does not specify archival mechanisms.

Discoverability. How readers find shareable durable surfaces they have a right to read but do not yet have addresses for is outside SSP's scope. Discoverability is a function of indices, registries, and conventions that the ecosystem will produce. v0.2 specifies the surface; it does not specify the index.

Attribution semantics for derived works. A reader who creates a new artifact derived from a shareable durable surface they have read raises questions of attribution that depend on the access semantics, on copyright frameworks, and on the conventions of the field. v0.2 does not specify them.

Cross-jurisdiction enforceability. A shareable durable surface authored under one jurisdiction's legal framework and read in another raises enforceability questions that are downstream of ACP and RCP, not of SSP. v0.2 does not specify them.

These are real concerns. They are not v0.2's concerns. The shareable durable surface specification gives the ecosystem something to build these conventions on top of.

[Changes from v0.1: §12 is new in v0.2. v0.1 named shareable durable surfaces as a future primitive; v0.2 specifies the primitive. §12.3 introduces the single-author case as the baseline; §12.4 introduces the bilateral case as the structural extension that adds paired copies and retention asymmetry. §12.5 specifies the integrity attestation that the bilateral case requires. §12.10 names what v0.2 does not specify so that readers do not mistake v0.2's silence for a claim of completeness.]

13. Chat-surface choreography

A session is a conversation. Surfaces are instruments rendered inside that conversation. The relationship between the conversational layer and the surface layer is the choreography that makes the language-user interface coherent. This section specifies that choreography.

13.1 The conversation is the through-line

Surfaces appear, perform their function, and recede. The conversation persists through them. A user who has rendered three surfaces over the course of a session has not navigated through three pages; they have engaged three instruments inside one continuous exchange.

Implementations MUST treat the conversational layer as the through-line of the session. A surface may dominate the user's attention while it is live, but the surface does not replace the conversation. The user MUST be able to return to the conversational layer at any time without dismissing or losing state from a live surface (subject to surface lifecycle rules in §7).

This rule prevents the failure mode where a surface presents itself as a destination — a modal the user must exit, a page the user must close, a flow the user must complete — and severs the conversational thread. The conversation is the venue; the surface is the instrument; the relationship MUST NOT be inverted.

13.2 Surfaces are summoned, not navigated to

A surface appears because the conversational state warrants it. The user expressed an intent that requires structure (selecting from a list, filling a form, reviewing a compact); the application generated a surface to host that structure. The user did not navigate to the surface; the surface was summoned in response to context.

This is the architectural inversion the page era did not have. In the page era, the user navigated to a destination; the destination was the unit. In the session era, the user remains inside the session; surfaces arrive inside it as needed.

Implementations SHOULD make summoning legible: the user should be able to perceive that a surface has been generated in response to something specific the conversation produced. Surfaces that appear without conversational warrant — as ambient UI, as persistent panels, as background instruments — are not session surfaces in the sense this spec uses; they may be application chrome, but they are outside SSP's scope.

13.3 Surfaces dismiss back to the conversation

When a surface's purpose is fulfilled or the user dismisses it, control returns to the conversational layer. The conversation acknowledges what happened on the surface — the action that fired, the input that was collected, the compact that was authorized — and continues.

Implementations MUST surface the outcome of significant surface interactions in the conversational layer. A user who authorized a compact, booked an appointment, or approved a document MUST see that fact reflected in the conversation, not only in the surface that has now retired. This is what makes the session navigable: during the session, the conversational record holds what happened, even when the instruments that hosted those moments are gone.

13.4 Multiple surfaces, one conversation

A session may host multiple surfaces simultaneously or sequentially. Multiple surfaces do not produce multiple conversations; they produce one conversation with multiple instruments active inside it.

Where multiple surfaces are active simultaneously, the application MUST make clear which surface is currently the focus of the user's attention and which actions on which surface are subject to which action windows. Concurrent surfaces with overlapping scopes are a known complexity; v0.2 does not prescribe a specific UI pattern for managing them, but does require that the user not be confused about which surface they are acting on.

Where surfaces appear sequentially — one surface retires, another is summoned in its place — the conversational layer mediates the transition. A surface that retires without conversational acknowledgment of what it accomplished is a failure under §13.3.

13.5 Conversational state and surface state are not the same

The conversation holds the through-line of the session — what the user has said, what the application has said, what intents have been expressed, what outcomes have been recorded. Surface state is the temporary state of an instrument: the form's current values, the table's current sort order, the compact's currently-displayed terms.

These are different layers and they MUST NOT be conflated. Conversational state persists for the duration of the session. Surface state ends when the surface ends. An action committed on a surface produces a conversational entry that survives the surface's retirement; the surface's intermediate state does not.

Implementations MUST NOT preserve surface state past surface retirement as if it were conversational state. A surface that has been retired is gone; reconstructing its prior intermediate state in a subsequent session is the application's responsibility (typically through artifact-bound re-instantiation, §7.4.4), not SSP's.

[Changes from v0.1: §13 carries forward the chat-surface choreography from v0.1 with light edits to acknowledge compact authorization as one class of surface interaction; §13.4 expanded to address the inter-agent case where multiple surfaces may be active under different compacts; §13.5 added in v0.2 to make explicit a distinction v0.1 left implicit and which the inter-agent reframe makes load-bearing.]

14. The sequence-of-instruments pattern

Some user intents require a sequence of surfaces, each performing a distinct function, each handing off to the next. Booking an appointment may require selecting a service, choosing a provider, picking a slot, and confirming. Authorizing a compact may require reviewing terms, examining the counterparty's claims, modifying scope, and committing. These are sequences of instruments inside a single conversational thread.

14.1 The sequence is the user's, not the application's

A sequence of surfaces is a sequence of moments where the user expresses or refines intent. The application orchestrates the sequence, but the user owns it. At any point in a sequence, the user MUST be able to revise prior steps, abandon the sequence, or branch into a different sequence by expressing a different intent in the conversational layer.

Implementations MUST NOT enforce linear progression through a sequence as a forced multi-step progression. A user who has selected a service and is now choosing a provider MAY return to service selection; a user who is reviewing compact terms MAY return to scope. The conversational layer is the through-line; the sequence is one path through it, not a script the user is running.

14.2 Each instrument has its own action window

Within a sequence, each surface is a distinct instrument. Each surface has its own action window for the actions it depicts. The completion of one surface in the sequence does not extend the action windows of subsequent surfaces; subsequent surfaces declare their own windows when they are summoned.

This rule prevents the failure mode where a long sequence accumulates stale state. If the user spent twenty minutes in step three of a five-step sequence, the surface for step three may need refresh before its actions can fire, even if step two completed cleanly twenty-five minutes ago.

14.3 Sequence state lives in the conversation, not in the surfaces

As the user moves through a sequence, the application accumulates context: what was selected, what was entered, what was decided. This context belongs in the conversational layer, not in the chain of surfaces.

This means surfaces in a sequence are not coupled state holders. Each surface depicts current world state appropriate to its function and reads context from the conversational layer. If a surface mid-sequence is retired and re-summoned, the new surface inherits context from the conversation, not from the prior surface's intermediate state.

This rule supports refresh and recovery: a surface that needs refresh can be retired and re-summoned without losing the user's place in the sequence, because the user's place is in the conversation.

14.4 Compound intents and sequence boundaries

v0.1 §11.5 specified that compound user intent SHOULD be expressed as a single SSP action with internal orchestration, rather than as a chain of separately-authorized actions. v0.2 carries this position forward. Sequence-of-instruments is the user-facing pattern; compound atomicity is the execution-layer concern. The sequence may walk the user through several surfaces; the action that fires at the sequence's end may be one compound action that the execution layer orchestrates internally.

This is the architectural choice v0.1 made for compound atomicity, named again here for completeness. The unresolved question — what evidence would shift this from "deferred" to "ready to specify" — is articulated in §19.4.

[Changes from v0.1: §14 carries forward the sequence pattern from v0.1; §14.3 makes explicit a state-residence rule v0.1 implied; §14.4 references the compound-action position carried forward from v0.1.]

15. Conversational state across surfaces

The conversational layer is the through-line of the session (§13.1). This section specifies how that through-line behaves across the appearance, retirement, and refresh of surfaces.

15.1 Conversational state is the session's authoritative record (within the session)

Within a live session, conversational state is the session's authoritative record. What happened in the session — what the user said, what the application said, what intents were expressed, what surfaces appeared, what actions fired, what outcomes were recorded — is held in the conversational layer.

This is not a claim about implementation: applications may store conversational state in transcripts, structured logs, vector indices, or any other form. It is a claim about authority within the bounds of the session. When a question arises about what happened in a session and the question is asked while the session is live, conversational state is what the application MUST consult to answer it.

Surface state, when it differs from conversational state, is an intermediate working state that did not survive the surface's retirement. The conversation holds what was committed; the surface held what was being worked on.

Authority beyond the session is a different question. Once the session ends, conversational state ends with it (§15.3). Authority for what happened in the session, after the session has ended, lives in artifacts and compacts (§15.2). The session is authoritative for itself; durable artifacts and compacts are authoritative for what survives it.

15.2 Outcomes recorded against artifacts and compacts are also authoritative

Where actions fired during a session produced outcomes recorded against artifacts (§7.4.1) or compact records (§7.4.3), those outcomes are authoritative for the artifacts and compacts they were recorded against. The conversational record references those outcomes; the artifacts and compacts hold them.

This separation matters because artifacts and compacts persist beyond the session, while conversational state ends with the session. A user returning to an artifact in a later session sees the artifact's authoritative outcome; the conversational record of the prior session may or may not be available, but the artifact's record is.

15.3 The conversational record is not a transcript that survives the session

Conversational state ends with the session unless the application has explicitly bound elements of it to durable artifacts. SSP does not require applications to preserve conversational transcripts beyond the session, and applications that do preserve them MUST do so under explicit user consent and under whatever compact (ACP) governs the retention of session content.

This is the consequence of §3.4: persistence comes from artifacts and compacts, not from sessions. A user who wants a record of a session's conversation must commit it to an artifact during the session; otherwise the conversational record ends when the session does.

Implementations SHOULD make explicit, where applicable, whether and how conversational records persist. Users MUST NOT be misled into believing conversational state will be available in future sessions when the application has not committed to preserving it.

15.4 Cross-surface references

Within a session, the conversation may reference surfaces that have already retired ("the form you filled out earlier," "the compact you authorized"). These references resolve against the conversational record of what happened, not against the retired surface itself.

Where a reference identifies an action's outcome ("the appointment you booked"), the reference resolves against the artifact or compact that holds the outcome, not against the session surface that mediated it. The session surface is gone; the artifact or compact persists.

This rule keeps the architecture clean: surfaces are transient instruments; outcomes live in durable structures. References to outcomes always go to the durable layer.

[Changes from v0.1: §15 expands v0.1's treatment of conversational state to make explicit which records are authoritative and how persistence flows from artifacts and compacts rather than from the session. The §15.3 clarification that the conversational record does not survive the session unless explicitly bound to artifacts is new in v0.2 and is the §3.4 commitment applied at the conversational layer.]

16. Surface-to-surface transitions

When one surface gives way to another within a session, the transition is a moment of architectural concern. The user's attention shifts; action windows change; conversational state advances. This section specifies how those transitions behave.

16.1 Transitions are mediated by the conversation

A surface does not hand control directly to another surface. The conversation mediates. The retiring surface's outcome (or its dismissal without outcome) is recorded in the conversational layer; the next surface, if any, is summoned in response to that updated conversational state.

This rule prevents the failure mode where surfaces chain together without conversational acknowledgment, producing what is effectively a wizard inside a session. A user who has moved from surface A to surface B without the conversation registering A's completion has lost the through-line.

16.2 The retiring surface's state must be resolved before transition

A transition MUST NOT occur with surface A's actions still in flight in a state that the conversation has not acknowledged. If an action on surface A has fired but its outcome has not yet returned, the transition either waits for the outcome (under long-running execution rules — see §10.5 and the long-running execution semantics implied throughout §8–§10) or proceeds with the conversation acknowledging that the outcome is pending.

This rule prevents the failure mode where a user moves to a new surface and a prior action's outcome arrives later with no conversational context to receive it. The conversation must be in a state that can receive the outcome when it arrives.

16.3 Action windows do not transfer

Action windows on the retiring surface end when the surface retires. Action windows on the new surface begin when the new surface is summoned. There is no continuity of action windows across the transition; a user cannot "carry" an authorized action from one surface to another.

This rule is a corollary of §8 and §14.2 stated explicitly because the transition is where implementations are most likely to be tempted to hand windows forward. They MUST NOT.

16.4 Compact authorization is a special case

When a sequence's terminal surface is a compact authorization (§17), the transition out of that surface is the moment of compact commitment. The retiring surface's outcome is the compact record; the conversation's acknowledgment of that outcome is the user's confirmation that the compact has been authorized.

Where a subsequent surface is summoned after compact authorization, it is summoned in response to the new conversational state — a state that now includes the authorized compact. The compact governs whatever interactions are reviewed inside the subsequent surface, until and unless the compact's terms are revised through ordinary versioning (§12.6).

[Changes from v0.1: §16 makes explicit the conversational mediation of surface-to-surface transitions; §16.4 is new in v0.2 and addresses the case where the terminal surface in a sequence is a compact authorization. The rest of §16 carries forward v0.1's transition semantics.]

17. Worked example: the session as authoring venue

This section walks through a single use case end-to-end to demonstrate how the rules specified in §6 through §16 compose when a session is used to author an inter-agent compact. The example is illustrative, not normative — the normative rules are in the prior sections — but it shows what compliance looks like in practice and what failure modes the rules prevent.

The use case is a contractor-and-homeowner scope agreement. The homeowner's user-agent and the contractor's agent are negotiating a compact governing what context the contractor's agent will retain about the homeowner, what records of the work will be produced, and how disputes about scope will be resolved. The homeowner is reviewing the compact inside their own session; the contractor is doing the same in theirs.

This example is chosen because the wedge analysis in [ACP §10] identifies contractor-and-service work as a primary adoption vertical: scope drift and "he-said-she-said" disputes are exactly the failure mode the asymmetric-retention property of bilateral shareable durable surfaces is designed to address. The example illustrates SSP's role in that architecture — the venue where the compact gets reviewed and authorized.

17.1 Setup

The homeowner has begun a session with their user-agent. The session runs on a runtime that satisfies the conditions specified in [RCP §3] through [RCP §5] — the homeowner's agent has a standing runtime compact with the runtime hosting the session, governing what the runtime sees, retains, and logs.

The contractor's agent has proposed a compact. The proposal arrived through the inter-agent channel specified by ACP; from SSP's perspective, the proposal is now context the homeowner's session needs to render for review.

The user-agent summons a compact-review surface inside the session. This is a private session surface (§4) whose origin (§4) is the user's own agent, acting on the user's behalf to render the proposed compact. The surface is bound to a draft artifact representing the proposed compact (§7.4.1, §7.4.3); the artifact will become the authoritative compact record if and when the homeowner authorizes it.

17.2 The integrity requirement at work

The compact-review surface depicts the proposed compact's terms: scope of work, retention rights for the contractor's agent, derivation rights, propagation rules, expiration, revocation conditions, and the substrate clause referencing the runtime compact. §10.4 governs what the surface MUST do here:

• The surface MUST depict the compact accurately. The terms shown to the homeowner MUST be the terms the homeowner is authorizing.
• Any drift between the rendered terms and the committed compact is a failure of the surface.
• The integrity requirement applies to the rendering of compact terms before authorization, to the compact record produced upon authorization, and to both parties' paired copies of the resulting bilateral shareable durable surface.

This is where SSP earns its keep in the inter-agent reframe. A surface that misrepresents the compact — by truncating terms, by reordering them, by softening retention language, by hiding propagation clauses — is a failure under §10.4 and the application MUST treat it as one. The homeowner's authorization is meaningful only if what they reviewed is what they authorized.

The user-agent's job is not just to render the compact but to render it faithfully. Where AAP applies, it specifies what makes an agent capable of this task; SSP specifies that the surface produced by such an agent MUST satisfy the integrity requirement.

17.3 Action windows on compact authorization

The compact authorization is an action under §4. It is subject to action window rules under §8.

The compact-review surface declares an action window for the authorization. §8.3 names compact authorizations as an action class with their own typical window duration; for this kind of compact — a contractor-scope agreement reviewed at home, with no immediate time pressure — the window may be measured in hours or days rather than seconds. The homeowner does not need to authorize within thirty seconds of the surface appearing; they may take the time to read the terms, consult with someone, or come back later.

If the window expires before the homeowner acts, §9 applies: the application MUST refresh the surface against current world state before any equivalent action can fire. In this case, "current world state" includes the contractor's agent's current proposal — which may have changed if the contractor has revised the offer in the interim. The refresh produces a new surface depicting the current proposal; the homeowner re-engages with whatever has changed.

If the homeowner invokes the authorization at the edge of the window, §8.4 applies: the application MUST treat the homeowner's invocation as the moment of intent and MUST honor the action against the state the homeowner saw, unless one of the named exceptions applies. The narrow exceptions matter here: the homeowner cannot be punished because the contractor's agent's response took an extra few seconds to arrive over the inter-agent channel. The homeowner's intent is the anchor.

17.4 The bilateral case at authorization

When the homeowner authorizes the compact, two artifacts come into existence. The homeowner's user-agent retains one copy, governed by what the compact permits the homeowner to retain. The contractor's agent retains the other copy, governed by what the compact permits the contractor to retain. The two copies share canonical content (§12.4); they differ in retention asymmetry as governed by [ACP §5].

The integrity attestation specified in §12.5 is what makes this pairing work. Both parties' agents sign the canonical content at authoring time. Both parties' copies record the signature. If a dispute later arises about what was agreed, either party — or a third-party reconciler, if and when reconciliation is specified — can verify against the signature that the canonical content has not drifted from what was authored.

This is what the bilateral shareable durable surface produces that page-era artifacts could not: a structured record that both parties agree to, that neither can unilaterally revise, and that retains different slices on each side under contractual terms. The contractor's agent retains the work record because they need it for their accounts; the homeowner's user-agent retains the work record because they need it for their household; neither party retains the other party's privileged context unless the compact permits.

17.5 Surface-to-surface transition out of authorization

After authorization, §16.4 applies. The transition out of the compact-review surface is the moment of compact commitment. The retiring surface's outcome is the compact record; the conversation's acknowledgment of that outcome is the homeowner's confirmation that the compact has been authorized.

If the user-agent summons a subsequent surface — for instance, a surface depicting the now-authorized compact for the homeowner's records, or a surface displaying the contractor's first scheduled visit under the compact — that surface is summoned in response to the new conversational state. The conversational state now includes the authorized compact; subsequent surfaces and subsequent interactions with the contractor's agent operate under it.

17.6 Session death between authorization and commitment

Suppose the homeowner authorizes the compact, the user-agent transmits the authorization to the contractor's agent over the inter-agent channel, and the homeowner's device loses power before the contractor's agent's commitment confirmation returns. §10.5 governs this case.

The action — compact authorization — was bound to the compact record artifact (§7.4.3). The execution outcome MUST be recorded against the compact record, not against the dead session. When the homeowner begins a new session and loads the compact record, §10.5 requires the application to surface the outcome: was the authorization committed on the contractor's side, or did it not complete?

Where the runtime compact ([RCP §X]) and the agent compact ([ACP §X]) provide signaling that distinguishes "authorized but not committed" from "committed," the application MUST report which state was reached. The homeowner is not stranded with a phantom authorization whose status they cannot determine. The architecture routes the recovery through the artifact, which persists, rather than through the session, which does not.

§10.5 also forbids silent retry. If the authorization was authorized but not committed, the homeowner — not the application — decides whether to retry. The application's job is to surface the state; the user's job is to act on it.

17.7 What this example demonstrates

The mechanics specified across §6 through §16 compose into a coherent end-to-end interaction:

• The session (§6) provides the venue.
• The private session surface (§7) provides the instrument for review.
• The action window (§8) protects the homeowner from acting on stale terms.
• Refresh (§9) handles the case where the proposal changes before authorization.
• Execution failure handoff (§10), including the integrity requirement (§10.4) and session death recovery (§10.5), keeps the homeowner informed and in control.
• Access scoping (§11) keeps the surface scoped to the homeowner alone during review.
• The shareable durable surface specification (§12) — particularly the bilateral case (§12.4) and integrity attestation (§12.5) — produces the contractually-bound paired record.
• Chat-surface choreography (§13) and surface-to-surface transitions (§16) keep the conversation as the through-line.

Each rule does specific work. None is decorative. The composition is what makes the session-as-authoring-venue use case workable, and the composition is what would not be available if any individual rule were softened.

This is the architectural claim of v0.2 demonstrated end-to-end: the session is not just a venue for thinking with an LLM; it is the venue where the user's intent meets the world, including the world of inter-agent commitments. The page era did not have a venue with the integrity properties this use case requires. v0.2 specifies it.

[Changes from v0.1: §17 is new in v0.2. v0.1 did not have a session-as-authoring-venue worked example because the inter-agent reframe was not yet part of the spec. §17 is where the architectural claim of v0.2 is demonstrated.]

18. Requirements summary

This section consolidates the normative requirements specified throughout v0.2 for implementer reference. The authoritative form of each requirement is in its parent section; this summary is a navigation aid.

18.1 Session lifecycle (§6)

• Session identifiers MUST NOT be reused across users, MUST NOT be derivable from public information, and MUST be invalidated when the session ends. (§6.2)
• SSP sessions MUST NOT persist beyond their session lifetime. Session-scoped state is destroyed when the session ends. (§6.3)
• Applications MUST NOT silently fire actions authorized in a prior session that would no longer be valid in the current session. (§6.4)
• Applications MUST NOT continue to render a surface from a prior session as if it were live. (§6.4)
• Substrate is a precondition: SSP-compliant sessions for use cases where runtime trustworthiness matters MUST run on runtimes that satisfy the conditions in [RCP §3] through [RCP §5]. (§6.5)

18.2 Surface lifecycle (§7)

• Private session surfaces MUST NOT outlive their session. Implementations MUST NOT cache, persist, or restore them as if they were durable. (§7.1)
• Implementations MUST NOT re-render a retired surface as if it were live. (§7.2)
• Implementations SHOULD preserve surface origin metadata to support multi-agent contexts; full provenance semantics are deferred to AAP. (§4, §11.4)

18.3 Action windows (§8)

• Every action declared on a surface MUST have an action window. (§8.1)
• After the window ends, the action MUST NOT fire. Any attempt to invoke an expired action MUST be treated as a request to refresh. (§8.1)
• When a user invokes an action whose window is about to expire, the application MUST treat the user's invocation as the moment of intent and MUST honor the action against the state the user saw, except in the named exceptions of §8.4.
• Where the application refuses to honor tap-down intent, the refusal MUST be reported to the user via conversational failure handoff with the specific reason made available. The application MUST NOT silently fail or silently substitute changed state. (§8.4)
• Surfaces SHOULD make short action windows perceptible to the user. (§8.5)

18.4 Refresh and recovery (§9)

• When an action has expired, the application MUST refresh the surface against current world state before any equivalent action can fire. (§9.1)
• Refresh MUST be perceptible to the user, especially when consequential state has changed. (§9.2)
• For high-stakes refreshes, the application SHOULD make the change explicit and require the user to re-engage with the changed state before the action may fire. (§9.2)
• Refresh resets the action windows of all actions on the refreshed surface. (§9.3)
• Implementations SHOULD provide a perceptible refresh-on-request affordance. (§9.4)

18.5 Execution failure handoff (§10)

• When an action fails or partially completes, the application MUST surface the failure to the user inside the session. (§10.1)
• The user MUST NOT be left inside a surface that depicts a successful state when the action did not succeed. (§10.1)
• The application MUST report cross-boundary failure honestly. If the application does not know whether the action succeeded on the counterparty side, the application MUST say so. (§10.3)
• A surface that renders a compact for user review MUST depict the compact accurately. The terms shown MUST be the terms the user is authorizing. (§10.4)
• Where an action was bound to an artifact and the session dies during execution, the execution outcome MUST be recorded against the artifact. A new session loading the artifact MUST surface the outcome. (§10.5)
• Where an action was a compact authorization, the outcome MUST be recorded against the compact record. (§10.5)
• The application MUST NOT silently retry an action whose outcome is unknown. (§10.5)

18.6 Access scoping (§11)

• Requests that do not present a valid session identifier MUST NOT receive surface state. Requests presenting an identifier belonging to a different user MUST NOT receive surface state. (§11.1)
• Implementations MUST NOT convert a private session surface into a shareable durable surface by relaxing scoping. The conversion requires authoring a new shareable durable surface with explicit consent and the correct integrity properties. (§11.3)
• In multi-agent contexts, the host application is responsible for enforcing access scoping for any surface rendered inside its session, regardless of origin. (§11.4)
• Surfaces that would disclose privileged data to a session whose authenticated user is not entitled to see the data MUST NOT render the disclosure. (§11.5)

18.7 Shareable durable surfaces (§12)

• Paired copies of a bilateral shareable durable surface MUST share canonical content. (§12.5)
• A signing mechanism MUST exist that attests to canonical content identity across paired copies. (§12.5)
• Implementations without the integrity attestation mechanism MUST NOT claim to produce bilateral shareable durable surfaces. (§12.5)
• Versions of shareable durable surfaces are immutable; subsequent edits produce new versions. (§12.6)
• Bilateral shareable durable surfaces require both parties' consent for new versions. (§12.6)
• Shareable durable surfaces MUST be addressable. The address MUST be stable across the version's lifetime. (§12.7)
• Implementations MUST NOT publish, address, or treat as authoritative a surface lacking consent attestation appropriate to its case. (§12.8)

18.8 Chat-surface choreography (§13–§16)

• Implementations MUST treat the conversational layer as the through-line of the session. The user MUST be able to return to the conversational layer at any time without dismissing or losing live-surface state. (§13.1)
• Implementations MUST surface the outcome of significant surface interactions in the conversational layer. (§13.3)
• Where multiple surfaces are simultaneously active, the application MUST make clear which surface is the focus and which actions are subject to which windows. (§13.4)
• Implementations MUST NOT preserve surface state past surface retirement as if it were conversational state. (§13.5)
• Implementations MUST NOT enforce linear progression through a sequence as a forced multi-step progression. (§14.1)
• Within a live session, conversational state is the session's authoritative record. Applications MUST consult it when answering questions about what happened in the session while the session is live. Authority beyond the session lives in artifacts and compacts. (§15.1, §15.2)
• Conversational state ends with the session unless explicitly bound to durable artifacts under user consent and applicable compact terms. Users MUST NOT be misled into believing conversational state will be available in future sessions when the application has not committed to preserving it. (§15.3)
• Surface-to-surface transitions MUST be mediated by the conversational layer; transitions MUST NOT occur with prior surface actions in flight in a state the conversation has not acknowledged. (§16.1, §16.2)
• Action windows do not transfer across surface transitions. (§16.3)

[Changes from v0.1: §18 is the consolidated requirements summary; v0.1 had a similar section, and v0.2 expands it to cover the new normative rules introduced in §3.4, §6.5, §8.4 (rewritten), §10.4, §10.5, §12, and §13–§16. The summary is a navigation aid; the parent sections are authoritative.]

19. Open questions

These are questions v0.2 has taken positions on but where review may produce better answers. Each question names the position v0.2 takes and the kind of pushback that would justify revision.

19.1 The integrity attestation requirement (§12.5)

v0.2 requires that bilateral shareable durable surfaces carry an integrity attestation establishing canonical content identity across paired copies, and forbids implementations from claiming to produce bilateral surfaces without it. Some reviewers will argue this is too strict — that early implementations on substrates without mature cryptographic primitives should be permitted to ship a weaker form. Others will argue it is not strict enough — that the signing mechanism should be specified at the SSP layer rather than deferred to the runtime and AAP.

v0.2 takes the strict middle position: the requirement is normative, the mechanism is deferred. Pushback on whether the strictness is workable in early implementations is welcome. Pushback on whether the mechanism deferral is appropriate is also welcome.

19.2 Persistence by composition (§3.4)

v0.2 commits to non-persistent sessions and routes continuity through artifacts and compacts. Some reviewers will argue this concedes too much to user agency — that some session continuity is necessary for usable applications and that the architecture should permit narrow exceptions. Others will argue it does not go far enough — that even artifact-bound continuity introduces vendor lock-in unless additional governance is specified.

v0.2 takes the position that the architectural answer to memory ownership is structural, not configurable. Pushback on whether the structure produces usable applications is welcome. The pushback that would shift the position is not "users want more continuity" but "the structure as specified produces failure modes that user-mediated remedies cannot address."

19.3 The integrity requirement for compact-rendering surfaces (§10.4, §17.2)

v0.2 specifies that surfaces rendering compacts for user review MUST depict them accurately, and that drift between rendered terms and committed compact is a surface failure. The unresolved question is what mechanism enforces this at runtime: the rule is normative, but the protocol does not specify how an application proves it has rendered faithfully.

Pushback on whether this requires a specific verification mechanism — for instance, cryptographic attestation of the rendered surface against the compact's canonical form — is welcome. The risk of specifying a mechanism is foreclosing the design space; the risk of not specifying is leaving the requirement enforceable only by inspection.

19.4 Compound action atomicity

v0.2 carries forward v0.1's position that compound user intent SHOULD be expressed as a single SSP action with internal orchestration, rather than as a chain of separately-authorized actions. The unresolved question is what evidence from implementations would shift this from "deferred" to "ready to specify."

v0.2's position: the threshold is evidence of real flows where compound-as-single-action produces worse UX than a chain would have. If implementations report that internal orchestration produces opaque failures the user cannot reason about — failures where the user sees a compound action succeed-or-fail but cannot determine which constituent operations completed and which did not — that is evidence the boundary needs protocol-level support. Implementations reporting clean internal orchestration are evidence the deferral is correct.

Pushback that names a specific failure mode the deferral does not handle is welcome. Pushback that argues compound atomicity in general is welcome but should be accompanied by a proposed mechanism.

19.5 Session resumption affordances (§6.3)

v0.2 permits applications to offer session resumption — beginning a new session that loads prior artifacts, recent context, or a summary of recent interactions. The unresolved question is how much of the prior session's context can be loaded into a resumed session before the resumed session is, in effect, the prior session continued under a different name.

v0.2's position: a resumed session is a new session if it does not inherit the prior session's identifier, in-flight actions, or unauthorized state, and if the user explicitly authorizes whatever artifacts and compacts are loaded. The line is at unauthorized state and at session-scoped objects. Pushback on whether this line is workable is welcome.

19.6 Multi-user collaboration on session surfaces (§5.2)

v0.2 defers multi-user collaboration on a single session surface as out of scope. Some reviewers will argue this excludes use cases (real-time collaborative editing of a shared instrument) that the architecture should accommodate.

v0.2's position: multi-user collaboration is distinct from the bilateral shareable surface case (which is two parties holding permission-bound copies, not two parties acting on a single live surface). The architectural treatment of multi-user surfaces is its own design problem, not addressed by v0.2's bilateral specification. Pushback on whether multi-user surfaces should be specified as a distinct primitive is welcome.

19.7 Reconciliation across the compact family

v0.2 is consistent with ACP and RCP in deferring reconciliation — the question of who arbitrates when parties dispute compact terms or accuse each other of violations. The deferral is parallel across all three protocols of the compact family and is the same deferral v0.1 made for SSP itself.

Pushback on whether reconciliation can be deferred indefinitely is welcome. A working hypothesis worth holding lightly: a reconciliation agent operating under its own compact, distinct from both parties, may be the architectural answer. v0.2 does not commit to it.

[Changes from v0.1: §19 is the open-questions section. v0.1 had open questions; v0.2 expands them to cover the new normative commitments and named the evidence threshold for compound atomicity (§19.4) explicitly.]

20. Changelog and v0.1→v0.2 mapping

20.1 Substantive changes from v0.1

• §3.4 (new). Persistence by composition, not by primitive. v0.1 left this question open; v0.2 resolves it by routing continuity through artifacts and compacts rather than through extended sessions.
• §4 (expanded). New defined terms: shareable durable surface (full definition replacing v0.1's "future primitive" placeholder), compact, runtime accountability. Expanded definitions: action, surface origin, artifact.
• §6.3 (strengthened). Sessions MUST NOT persist beyond their session lifetime. v0.1 implied this; v0.2 makes it normative.
• §6.5 (new). Substrate is a precondition for SSP-compliant sessions where runtime trustworthiness matters. Points to RCP for the mechanics.
• §7.4 (expanded). Compact records and runtime compacts named as artifacts (§7.4.3); shareable durable surfaces named as a distinct artifact class (§7.4.5).
• §8.4 (rewritten). Tap-down intent rule restated as MUST with named exceptions for material impossibility, material change, and access/integrity violations. v0.1's SHOULD created a loophole that the §3.3 humane-over-machine-tidy commitment did not warrant.
• §10.4 (new). Integrity requirement for compact-rendering surfaces. Load-bearing for the session-as-authoring-venue use case.
• §10.5 (new). Session death during execution. Recovery is mediated through artifact-bound re-instantiation, consistent with §3.4.
• §11.3 (expanded). Acknowledges bilateral shareable surfaces and the ACP retention asymmetry.
• §12 (new). Full specification of shareable durable surfaces. The single-author case is the baseline (§12.3); the bilateral case is the structural extension (§12.4); integrity attestation across paired copies is normative (§12.5).
• §13–§16 (expanded). Chat-surface choreography, sequence-of-instruments, conversational state, and surface-to-surface transitions all carry forward from v0.1 with edits acknowledging compact authorization as a class of surface interaction. §13.5 (state-residence rule) and §15.3 (conversational records do not survive the session unless explicitly bound to artifacts) make explicit rules v0.1 left implicit.
• §17 (new). Worked example: the session as authoring venue. Demonstrates §6 through §16 composing end-to-end for an inter-agent compact authorization.
• §19 (expanded). New open questions covering integrity attestation, persistence by composition, compact-rendering integrity enforcement, and reconciliation.

20.2 What did not change

Most of v0.1's mechanics carry forward unchanged. v0.1 implementers reading v0.2 will find the action window rule (§8), refresh and recovery (§9), execution failure handoff (§10.1–§10.3), access scoping (§11.1, §11.2, §11.5), and chat-surface choreography (§13.1–§13.4) substantively the same as in v0.1. Edits to these sections are clarifications, additions, or acknowledgments of the inter-agent reframe; they do not contradict v0.1.

20.3 Section mapping

v0.1's section numbering is preserved through §16. New sections introduced in v0.2:

• §3.4 — Persistence by composition (new subsection in §3).
• §6.5 — Substrate is a precondition (new subsection in §6).
• §7.4.3, §7.4.5 — Compact records and shareable durable surfaces as artifact classes (new subsections in §7.4).
• §10.4 — Integrity requirement for compact-rendering surfaces (new subsection in §10).
• §10.5 — Session death during execution (new subsection in §10).
• §12 — Shareable durable surfaces (new section). v0.1 §12 was titled "Future primitive: shareable durable surfaces" and contained a deferral note; v0.2 §12 is the full specification. Readers with v0.1 references to §12 should expect v0.2's §12 to be substantially different.
• §13.5 — Conversational state and surface state are not the same (new subsection in §13).
• §15.3 — The conversational record is not a transcript that survives the session (new subsection in §15).
• §16.4 — Compact authorization as a special-case transition (new subsection in §16).
• §17 — Worked example: the session as authoring venue (new section). v0.1 had no §17.

v0.1's requirements summary (v0.1 §17) is now §18 in v0.2. v0.1's open questions (v0.1 §18) are now §19. v0.1's contact information (v0.1 §19) is now §21. Readers with v0.1 references to §17, §18, or §19 should consult the corresponding renumbered sections in v0.2.

[Changes from v0.1: §20 is the changelog and section mapping. The mapping table is included so external references to v0.1 section numbers can be resolved against v0.2.]

21. Contact and feedback

SSP is a draft protocol. Feedback, critique, implementation experience, and proposed revisions are all welcome and necessary for the spec to mature. Implementers, reviewers, regulators, and anyone with a stake in what the conversational substrate becomes are invited to engage.

Feedback on SSP v0.2 can be directed to Curated Future at curatedfuture.com. The architectural overview accompanying this release names the channels for the coordinated feedback process across SSP, ACP, and RCP.

This is one of three protocol drafts being published together. Readers wanting to understand SSP v0.2 in the context of the full architecture should also read ACP v0.1 (the Agent Compact Protocol) and RCP v0.1 (the Runtime Compact Protocol). The architectural overview at [link] frames the coordinated release.

The original SSP v0.1 published April 27, 2026, and remains available for readers concerned only with the private session surface primitive in single-application contexts. This v0.2 supersedes v0.1 for implementers; it does not retract or invalidate v0.1, which remains a complete specification of its own scope.

The companion essay After the Page provides the architectural argument that motivates the compact family. It is recommended for readers who want to understand the context in which these protocols are being proposed but is not required to implement them.

v0.2 is a draft. It will be revised.