Sessions, runs and artifacts

You ran a quench study on Tuesday. On Friday someone asks which cooling rate produced the diagram in your slide. You need to find that exact run, not re-derive it. This page describes what Phases keeps, where it keeps it, and how you get back to it.

Sessions#

A session is one conversation. When you send your first message as a signed-in user from the home page, the URL is quietly rewritten to /sessions/<id> — that is the permanent address of the conversation. Inside a workspace the equivalent address is /ws/<slug>/chat/<id>.

The conversation and the simulation record share one identity: the chat and the backend session have the same id, the same owner and the same workspace, and every run created in that conversation inherits the same workspace. That is enforced in the database, not by convention, which is why a run can never end up attached to a conversation you do not own.

Older links keep working. /chat/<id> and /sessions/<id>/activity both redirect to /sessions/<id>.

Signed-in users find past conversations under Recents in the left sidebar, or through the command palette on ⌘K, which searches chats and offers actions such as New chat and Open simulations.

A session created by an external agent over MCP opens as a read-only replay instead of an editable chat: the recorded tool calls are rendered, with log_note entries shown as assistant messages, and there is no composer. Continue the original conversation through your MCP host using the same product_session_id. To work in the web chat instead, start a new chat. See Use Phases from an MCP client.

Runs#

Every simulation execution reserves a run version — an integer starting at 1, allocated under a lock on the session so two concurrent requests cannot claim the same number.

Version numbers are never reused. The next version is one more than the highest version ever seen for that session, including versions that were deleted. If you delete run 3, the next run is 4, not 3. A deleted session id is likewise retired permanently. This is deliberate: a run number in a report always refers to one execution, forever.

Run artifacts live under a run-scoped storage prefix, session/<sessionId>/run_NNN, where NNN is the version zero-padded to three digits. Run 3 is run_003. That is the same name the product shows you.

Artifacts#

Artifacts are the files a run produced: plots, animations, the configuration that was executed, and the material cards involved. What each simulator writes is described on its own page — heat treatment, CCT, RSW, V-Gleeble.

The storage bucket is private. Nothing is served by guessing a path. Content comes back one of two ways:

Inline text is served only for .txt, .json, .csv, .k, .log, .yaml, .yml and .md files that are valid UTF-8 and under 2,000,000 bytes. Anything else must be fetched as a URL — the API answers Binary artifacts must be requested as a URL.

Deleting a run removes the stored objects, not just the database row: every file under the run's storage prefix is removed in batches, and the prefix is then re-listed and the deletion reported as done only when it comes back empty — otherwise the operation fails with Run artifact prefix is not empty after deletion rather than pretending to have cleaned up. A signed URL minted earlier is not individually revoked, but there is nothing left behind it to serve. Sharing a conversation is the case with no undo, and it is covered at the foot of this page.

Getting back to earlier work#

The Simulation Runs sidebar (the history control in the header) lists the runs of the session you are looking at, headed Simulation Runs with the session id truncated beneath it. The control is hidden on the admin, settings, materials and simulator pages, so open a chat first if you cannot find it. Each run appears as Run <version> with a file count; expanding it lists the files. When a session contains more than one kind of run, filter chips appear. With no runs yet it reads:

No runs — Runs appear here once a simulation has been executed in this session.

The list shows every file the run produced — plots and animations alongside PhaseLog.txt, material_resolution.json, the LS-DYNA deck and the outputs archive. Each row carries its own download button, and clicking a viewable file also opens an inline File Viewer that shows the image or the text and has its own Download file button. Viewable types are the text list above plus .png, .jpg, .jpeg and .gif.

The Results tab of the simulation panel lists stored runs for the active simulator as a table — Run, Date, Grades, BC, t_end, Peak T, Status, Images, Actions — with up to three actions per run: View / Hide, which expands the run to show the configuration summary and a Files list for any run that stored files, plus an inline image gallery when it produced images; Reconfigure, which loads that run's configuration back into the Configure tab; and a delete button. The status pill is derived from what was stored: complete when the run has at least one image, incomplete when it has files but no images, failed when it has none. Every file in the expanded Files list has its own download button — that is where PhaseLog.txt, material_resolution.json, the LS-DYNA deck and the outputs archive are picked up for your own tooling. Before the first run the tab reads No simulation runs found — Configure and run a simulation to see results here. Reuse and share runs walks through the reconfigure loop, and Compare and analyse runs covers reading two runs against each other.

You can also ask, in the conversation:

List the simulation runs in this session.

Show me the results from run 2.

Closing the tab during a long run#

A simulation does not stop because your browser went away. The backend keeps executing and buffers the event stream so a returning client can replay what it missed. When the page reattaches, a banner reads Resuming simulation from background….

That replay buffer has limits you should know about. It is held in the backend process, so it does not survive a restart, and a finished task is kept for replay for 10 minutes. Come back after that and the reconnect endpoint answers No active task for this session — the run's stored artifacts are still there, but the live narration is gone. Open the run in the Results tab or the Runs sidebar instead.

Where the workspace has durable workflow replay enabled — the default in the hosted product — a simulation that ran as a durable job is replayed from a stored event cursor instead of that in-process buffer. That narration survives a backend restart and is not bounded by the 10-minute window. A live in-process stream still wins while the turn is actually running; the durable cursor is consulted when there is no running task to attach to. If your reconnect answers No active task for this session, the in-process buffer is what you were on. Long-running simulations describes the reconnect experience from the front.

Only one execution runs at a time per session. A second submission while a turn is active is refused before anything executes, with Another chat turn is still running. Wait for it to finish, then retry. Common problems collects the other messages you might meet here.

Deleting#

Deleting a chat from the sidebar asks Are you absolutely sure? and warns that it permanently deletes the chat and removes your data from the servers. Deleting a single run from the Results tab asks Delete <run>? and warns that it permanently deletes all files for that run.

Deletion is refused while work is in flight, with an explicit reason rather than a silent partial cleanup — for example Run is still active; retry after it reaches a terminal state, Session has an active run; retry after it reaches a terminal state, or Run has an active artifact write; retry after it completes. Retry once the run is finished. Interrupted deletions stay resumable rather than leaving orphaned storage behind.

Clear chat history in the user menu deletes everything, confirms with This permanently deletes your chat history. This action cannot be undone., and reports honestly when it could not finish — for example Deleted 12; retained 3 because simulation data is active or unavailable. Retry later.

Sharing a conversation#

Sharing is per conversation, not per run: the … menu on a chat in the sidebar offers Share, and the resulting /share/<id> link carries the same id as the session.

The one thing to take literally is the dialog's own description, Anyone with the URL will be able to view the shared chat. That page has no owner check and no sign-in requirement, and there is no un-share control in the product, so treat sharing as a one-way decision. Reuse and share runs covers the dialog and what the recipient does and does not see.