Sessions and context
Understand sessions and workspace context without assuming unsupported persistence, retention, automatic memory, or privacy guarantees.
Sessions and context
Sessions and context answer two different questions: where is this interaction bounded? and what information is available to the work? Use this page when preparing a model request, resuming a task, or reviewing why an output changed. Ethen’s platform copy supports workspace context, but the current sources do not establish exact persistence periods, automatic carryover, deletion behavior, or privacy guarantees.
What a session is
A session is a bounded period or thread of work. It can help a reader distinguish one line of inquiry from another and associate prompts, responses, decisions, or outputs with a particular interaction. The shell recognizes sessions as a platform concept, but Batch 01 does not define the complete session object or lifecycle.
A session should not be confused with:
- a workspace, which is the broader scope for model-centered work;
- a project, which groups related tasks or outcomes;
- a run, which represents one attempt to perform a task;
- a model context window, which is a capacity field for a request;
- an artifact, which is an output preserved from work.
One session may contain multiple requests or runs. A workspace may contain multiple sessions. These are reasonable conceptual relationships, but the exact implementation must be verified before documenting navigation, ownership, or retention behavior.
Session is used here as a bounded interaction context for current work, not as a promise of a particular database record, timeout, or cross-device history.
The console and shell support the idea of ongoing model work, while approved platform language describes context that can connect prompts, files, artifacts, decisions, evidence, and review notes. The exact session lifecycle is not defined in this batch.
Context lifecycle
Context has a lifecycle even when the product does not expose every stage explicitly.
- Select. Choose the minimum prompts, files, artifacts, decisions, evidence, or notes required for the task.
- Attach or reference. Make the material available through the supported surface.
- Use. The selected model or workflow processes the permitted portion of that material.
- Review. Inspect the output and determine which context actually influenced the result where evidence is available.
- Preserve or remove. Keep useful outputs and review notes according to current product controls and applicable policy.
The sources support the categories of workspace context, not a promise that every surface accepts every category or automatically records how each item was used.
Context should be treated as scoped input. A file stored in a workspace is not necessarily included in a model request. A prior response visible in a session may not fit within the selected model’s context window. A decision noted in one project may not be available in another.
Context should be understood as the material a supported surface makes available to a model or task at a given point.
A practical lifecycle is select, review, use, and remove or replace as the task changes. Do not assume automatic memory, automatic file inclusion, cross-project inheritance, or permanent availability. The product-specific UI must show what is active before documentation can provide exact controls.
State and persistence
Three forms of state should be kept separate.
| State type | Example | What this batch can say |
|---|---|---|
| Interface state | Current route, filters, selected model, open panel | Some Model Library search state is synchronized to URL parameters |
| Working state | Prompts, files, notes, decisions, and artifacts associated with work | Approved as workspace-context concepts where supported |
| Model-request state | The material sent within a particular request | Limited by the selected model and request path; exact assembly is product-specific |
Persistence is not verified by visibility alone. Seeing prior work in an interface does not establish how long it is retained, where it is stored, whether it is backed up, or how deletion works. Do not publish a retention period unless a verified policy source provides it.
When resuming work, reconstruct the context explicitly. Review the current session, identify the latest accepted decision, confirm the selected model and provider, and check whether source material has changed. This prevents stale interface state from being mistaken for a complete task history.
The sources do not establish how long sessions or context persist, whether they synchronize across devices, or which elements are stored separately as artifacts or history.
Describe visible state only. If a surface reloads or resumes work, that observation should be documented from the relevant implementation. Until then, avoid claims about autosave, recovery, retention, deletion timing, or durable memory.
Context boundaries
A context boundary is the point at which information stops being automatically available or should stop being shared. Useful boundaries include workspace, project, session, model request, tool call, and external system.
Before crossing a boundary, ask:
- Is this information necessary for the next step?
- Does the current surface support the context type?
- Is the selected model or provider appropriate for the material?
- Will a tool or integration receive part of the context?
- Is approval required before the context is used in a state-changing action?
- What evidence will show what was referenced?
Model capacity is another boundary. A context-window field, when present, describes the model record rather than the amount of workspace material. Long-context classification is a capability signal, not a guarantee that every item will be included or that quality remains constant across the full capacity.
Context boundaries also protect interpretation. A benchmark profile is research context; it is not runtime configuration. A catalog note is operational evidence; it is not a legal commitment. A receipt is evidence about one event; it is not the whole workspace history.
A context boundary answers what information is in scope for the current task and what remains outside it.
Keep sensitive information out unless the environment and product path are approved for it. Confirm the workspace, project, selected files, provider lane, and intended output. Do not infer that route recognition or a prior session grants access to unrelated context.
Privacy considerations
Use data minimization as a working practice: provide only what the task requires, remove unnecessary identifiers, and avoid placing credentials in prompts or files intended for model processing. These are safe operational habits, not claims about Ethen’s security or compliance posture.
The term local lane should not be used as a blanket privacy guarantee. Local behavior depends on the actual runtime, model, storage, network path, and product configuration, none of which is fully documented in Batch 01.
Privacy, retention, deletion, and contractual rights belong to verified legal and policy pages. The approved legal map includes Privacy and Terms routes, but a concepts page should link them only when directly relevant rather than implying that a short summary is authoritative.
When context sensitivity is uncertain, keep the task read-only and use synthetic or non-sensitive material until the owning surface and policy have been reviewed.
No universal privacy guarantee is provided by the current product surfaces. Approved language allows private or local lanes where supported, but does not define processing location, provider handling, retention, or deletion.
Use the verified Privacy route for canonical policy language when directly relevant, and obtain product-specific data-handling evidence before making sensitive-data decisions. Local does not automatically mean private, and hosted does not automatically mean unsuitable.
Common patterns
Research session
A reader opens Model Intelligence, compares normalized profiles, records quality flags, and saves a decision note. The context is research evidence. It does not automatically become a Gateway configuration.
Model-selection session
A reader filters Model Library by capability, provider, and status, inspects a candidate, and notes missing pricing or context values. The selected filter state can be represented in the URL, but the catalog result is still a current view rather than a permanent fact.
First-run session
A reader chooses a runnable model, supplies bounded context, submits a read-only task, and reviews the response together with visible route or status evidence. One successful run does not validate all providers or workloads.
Review handoff
A second person receives an artifact and decision note. The handoff should include the model, provider, date, relevant context, and unresolved limitations rather than assuming the artifact carries its full provenance.
Context reset
When a task changes direction, begin a new session or explicitly restate the accepted context. This avoids mixing earlier assumptions with a new objective.
These patterns demonstrate how to keep sessions useful without claiming automatic persistence, memory, or access behavior that the sources do not establish.
Useful patterns include a short task with explicitly selected inputs, a research session that records sources, and a review session that compares a result with evidence.
At the start of each pattern, identify the active context and selected model. At the end, separate the result from any retained artifact or receipt. When continuity matters, verify how the current surface preserves it rather than assuming a prior session will be available.
Diagnosing a changed answer
When a response changes between sessions, compare the inputs before blaming the model. Check the exact model and provider, current catalog status, prompt wording, attached files, prior decisions, and requested output. A different answer can reflect a changed route or missing context rather than random behavior.
Create a minimal reproduction with the smallest permitted context. If the behavior persists, preserve both attempts and the surrounding evidence. If it disappears, add context back in stages to identify which material changed the result. This method does not require a claim about hidden memory or persistence.
Preparing a session for review
A reviewer needs more than the final response. Include the objective, context sources, model or product surface, visible status, significant prompt constraints, and the reason the output was accepted or rejected. Mark any field that was unavailable. This keeps the review anchored to one bounded session while the broader workspace can continue to evolve.