Reporting a problem

Common problems is for the cases you can fix yourself. This page is for the other two: the answer is wrong, or the product broke. Both are worth reporting, and Phases gives you different tools for each.

It is also worth reading before you press the thumbs-down, because that button sends more than a thumb.

First, check it is a fault at all#

Three things look like failures and are not.

A capability switched off for your workspace. Phases says so, by name: "Resistance Spot Welding (RSW) simulation is disabled for this workspace. Ask your admin to enable it in settings." Nothing is broken; a workspace admin can turn it back on. See Workspace limits and features.

A role refusal. A workspace viewer cannot execute anything: "This workspace role cannot run simulations. Ask a workspace admin for member access." See Workspaces and roles.

A documented limit. TTT diagrams, quench media, per-phase hardness, an unsupported RSW grade, a missing bulk flow surface — these are refusals the product makes on purpose, and each one is written down in Known limits. A refusal that names its reason is working as designed, even when the reason is inconvenient.

What is left — a wrong number, a nonsensical answer, a card that never appeared, an "operation could not be completed" — is worth reporting.

The controls under an assistant message#

Every assistant message in a saved session carries a small row of buttons underneath: Copy, thumbs up, thumbs down, and — on the most recent turn only — Regenerate.

A few things govern when you see them:

• They appear only in a saved session. On the anonymous front page, before a conversation has become a session, there is nothing to attach a rating to and the rating buttons are not rendered.
• On a shared conversation link the transcript is read-only, so the row does not appear at all.
• The row on older turns fades in on hover or keyboard focus; the live turn keeps its row visible.
• The thumbs are disabled while a response is still streaming. Wait for the turn to finish.

Copy puts the message's raw text on your clipboard — including the fenced configuration blocks the chat renders as cards. That is usually the single most useful thing to paste into a report, because it shows exactly what the agent emitted rather than what the card drew.

What a rating actually sends#

This is the part worth knowing before you click.

Rating a message sends four things to the team that runs Phases: the rating itself, the session identifier, which message in the conversation it was, and the text of that turn — your prompt and the assistant's full reply. The transport bounds them at 100,000 characters for the prompt and 200,000 for the reply.

That is deliberate: a thumbs-down with no content attached tells nobody anything, and the point of the control is that someone can look at the answer you judged. But it does mean a rating is a product-quality channel, not a private note. Do not rate a turn whose contents you would not share. If the problem is in a conversation you would rather not hand over, describe it separately instead.

Three further honest details:

• The thumb lights up as soon as you click it, whether or not the record saved. The highlight is a local state, not a receipt.
• Clicking the same thumb again clears the highlight, but does not withdraw a rating that was already sent. Pressing the other thumb does replace it — each message carries one stored rating, and a later one overwrites the earlier.
• A rating is not a support ticket. Nothing is opened, and no one replies to you through the product. It goes into a review queue.

Regenerate#

Regenerate re-sends your last message under the same turn identity, and what that gets you depends on how the turn ended.

If the turn finished, its answer is already durable, and Regenerate replays it: the same text, read back from storage, without calling the model again. It will not talk a completed answer into being a better one. A genuinely fresh generation happens only where the turn ended in a model-generation failure the server marked as safe to retry.

It is not a retry for anything else either. It will not make a disabled capability work, it will not change a material the session has already resolved, and it does not repeat a solve: the replay path executes nothing, and a run that completed is already recorded with its own version number and artifacts. To actually run something again, ask for the simulation again and confirm a fresh parameter card — see Reuse and share runs.

Incident references#

When something fails inside Phases rather than in your request, the conversation says so without inventing a reason:

The operation could not be completed. Diagnostic details were retained.
Reference INC-ABCDEF123456.

Read that as three separate claims. The first sentence is the failure. The second is only present when the fault was actually written down — if you do not see "Diagnostic details were retained", nothing was saved and there is no reference to quote. The third is the handle.

The same fault always produces the same reference. Occurrences are grouped, so if you see INC-ABCDEF123456 twice, that is the same underlying problem happening again, not a second one. Saying "this is the third time I have seen this reference" is genuinely useful information.

What the reference does not contain is the reason to describe the problem yourself. An incident record deliberately holds no conversation content. It stores which service, component and operation failed, the exception class and an error code, up to eight repository-relative code locations, a short allowlisted context — the provider, route, runtime, simulator, stage, status, tool name and transport — and the identifiers that correlate it with a session, run or workflow. It does not store your prompt, the arguments the tool was called with, credentials, absolute paths, or your identity.

So the people who can read the reference cannot see what you typed. Your description is the other half of the report.

What to include#

A report that can be acted on is usually six lines:

Add whether it repeats. The single most valuable extra sentence in a bug report is the result of changing one variable: the same request on a different grade, a shorter cycle, or a different simulator. That tells the reader immediately whether the problem follows the material or the setup. The method is described in Common problems.

If the result is wrong rather than absent, say which number and by how much. Phases already publishes its known deviations with magnitudes and directions; a report that gives the same detail can be checked against them straight away. See Known limits and How we validate.

What happens next#

The thumbs-down is the route that carries the turn with it, so for a bad answer it is the most complete thing you can do in one click. Faults that Phases recorded itself already exist as an incident group, counting how often they recur, whether or not anyone rates the message.

Neither produces a reply to you inside the product: there is no in-app ticket, no status page for your report, and no notification when something is fixed. For anything that needs an answer — an urgent blocker, a question about your workspace's settings or limits, a result you need adjudicated — go to whoever operates Phases for your organisation. Your workspace owner or admin is the right first stop for anything about access, roles, enabled capabilities or allowances; see Workspaces and roles.

Before you write it up, one last check worth making: reopen the session. A long simulation that appeared to vanish has usually finished on the server, and its result card is rebuilt in the conversation when you come back. See Long-running simulations and Sessions, runs and artifacts.