Your session lives on the server

A thesis check often takes more than one sitting. After a run reaches Cross-check and a saved snapshot is available, you can use Continue to reopen that saved work. That is different from a promise that any unfinished upload or browser tab is saved. The account holds the eligible snapshot on the server; the browser displays it. This post explains the distinction, the limits of resuming, and why saved work still needs an export.

That is a deliberate architecture, and it has a cost we accept openly: it means we hold your work rather than you holding it. This post is about why that trade was made and what it obliges us to do in return.

The rule

One sentence governs the whole design: the session is the run's truth, and the browser is a view of it. Never the other way round.

Decisions and charges belong to the server-side run rather than a browser's local copy. A confirmed action updates that run; resuming later uses an eligible saved snapshot. Wait for the interface to confirm a save or completed action before leaving. An edit still being typed, an upload that has not finished, or a run that has not reached the save point should not be treated as durable work.

  ON THE SERVER                  IN THE BROWSER

  screening decisions            what is currently on screen
  accepted pairings              which panel is open
  reference edits                scroll position
  credits spent and held         a cached copy for speed
  consent you gave

  lose it and the run is gone    lose it and you press reload

The browser's rendering can be replaced. That does not make every stage of an unfinished run recoverable: use the account's available Continue entry to reopen an eligible saved run, and check that it contains the work you expect. If no saved snapshot is offered, do not assume clearing the browser or changing machines will recover it.

If closing a tab can destroy an hour of decisions, the decisions were never really recorded. They were being displayed.

Why not keep it in the browser?

Browser storage is genuinely attractive: it is private by default, costs nothing to run, and needs no account. Plenty of tools use it. It fails for this product on three counts.

A thesis is not a single sitting. A cross-check happens over weeks, across a university machine, a laptop and sometimes a borrowed desktop. State tied to one browser profile is state that does not follow you, and the moment it does not follow you it is worthless.

Money cannot live in a client. Credits are spent and held during a run. A balance the browser could edit is not a balance, and a charge recorded only in the browser that made it is unauditable — for you as much as for us. Anything financial has to be written somewhere neither party can quietly change.

Long work needs to survive the machine. A run can involve searches against several databases and processing that continues while you are not looking at it. A browser tab is not a place to keep something that has to outlive the tab.

What that obliges us to do

Holding your work is a responsibility, not a feature, so the retention side is stated plainly rather than buried.

Uploads, saved reports and resumable sessions have different retention rules. Uploads and reports use a one-year retention period, with deletion and archiving handled through the account tools. A resumable session has a shorter ceiling of 30 days and only qualifies for persistence after Cross-check. Keeping an upload does not mean keeping an open run for a year. Download reports and exports you need, and use the account's current retention information when planning longer-term storage.

Credits have a separate expiry policy. Their lifetime does not extend the lifetime of an upload or saved session, and purchasing credits is not a backup arrangement.

We do not train models on your document. The AI stages call provider APIs on the specific text they need, advisory-only and human-approved, and your thesis is not training material for anything. That is a standing commitment, not a setting.

One run, several views: choose the saved work explicitly

A browser window is not the identity of a thesis run. Use the run and saved-session controls to choose the work you intend to continue. A second tab or a different device is not an instruction to create a clean, independent copy of that document.

When changing devices, sign in and select the saved run that is actually available. Check its document and saved state before continuing. Two windows left open together can show different cached views until they refresh; do not use simultaneous tabs as a way to make competing edits to the same work.

The alternative — a separate run per browser — sounds more flexible and is considerably worse. Two runs over one thesis means two sets of screening decisions, two sets of accepted pairings and two answers to the question of what your bibliography looks like, with nothing to say which is current. Money makes it sharper still: a charge incurred in one would be invisible to the other, and a credit balance that depends on which laptop you opened is not a balance.

So starting fresh is an explicit act rather than a side effect of opening a new tab. It is the same principle as the rest of this post: the run exists in one place, and windows are windows.

What is a cache, and what is not

Not everything on the server is equally precious, and the distinction is what makes the system safe to rebuild.

Some state is derived: the extracted text, the parsed bibliography, the matched and missing tables, the analysis. All of it can be recomputed from your document, so losing it costs a recompute and never costs a decision. It is treated as a cache and rebuilt freely.

The rest is run truth: the decisions, the charges, the consents, the identities minted when your citations were first read. Nothing recomputes those, because they were not computed in the first place — they were chosen, by you. That state is carried forward through every rebuild, and a rebuild that omits it is treated as a stale write rather than an instruction to delete. The conservation rule behind it is in nothing gets lost.

What this does not claim

Server-side state is not a backup service. The resumable snapshot expires sooner than an upload or report, and deletion can remove the material you need to rebuild an export. Download important deliverables while they are available. If a run has expired, an older upload or report in the account is not a promise of an equivalent editable session.

Nor does any of this involve inspecting your writing. What the server holds is a reference check and the decisions you made during it. The report speaks to referencing quality and carries no finding of misconduct, and there is no stage at which the prose of your argument is assessed at all. If you want to see the shape of what a supervisor receives, that is covered in what a Ref[In] Report tells a supervisor.