Queued AI requests
If an AI request fails because there is no signal, MedJot offers to queue it. The request sends itself when the connection comes back, and the result appears in the same place it would have.
Nothing queues itself
You are offered the queue on a request that failed to reach the server, and nothing is queued unless you accept.
This is a deliberate limit. AI firing later that a clinician did not ask for is not a feature on a clinical tool — least of all a pre-alert.
The offer also only appears for a genuine connection failure. If the server answered and refused — you are out of entitlement, or the request was rejected — that is settled, and queueing it would not change the answer.
Which tools can be queued
| Tool | Queueable | Why |
|---|---|---|
| Differential diagnosis | Yes | |
| ATMIST pre-alert | Yes | But see the timing warning below |
| GP handover | Yes | |
| Safeguarding assist | No | It is a conversation; a queued turn arrives with no conversation around it |
| Text assist | No | It would land on text you have since edited |
Following a queued job
- The tool card that launched it shows its state — queued, sending, or ready to review — and that state outranks the feature's own status, because "Not started" on a card with a finished generation behind it is simply wrong.
- An unread result rings the card and replaces the Premium crown with a chip: the more useful thing to say about that card is that something is waiting.
- The header connection indicator lists everything queued. See The connection indicator.
Notifications
When a queued job finishes, MedJot raises a system notification — but only if the app is not on screen. The point of queueing is that you walked away; an alert for something you are already looking at is noise.
Permission is requested from the Queue it button, never on load, so the prompt is always attached to something you just asked for. If notifications are unavailable — iOS Safari only supports them in an installed app — everything falls back to an in-app message, and the card state is always there regardless.
The safety rules
A queued job is bound to the report it was made in. If you reset the report, the job is discarded, never run — its findings describe a patient who is no longer in front of you. This is re-checked even after the response comes back, in case you reset mid-flight.
No credential is stored on the device. A fresh token is minted when the job actually runs. If a different user has signed in by then, the job is dropped rather than billed to the wrong account.
Payloads are stored already redacted, so a queued job holds nothing the network would not have seen.
Expiry and failure
- Jobs expire after two hours.
- Failures back off and retire after five attempts.
- A failure the server settled retires immediately — retrying will not change the answer.
Reading the result
Opening the result does not consume it. Closing and reopening a modal will not bin a generation; only the unread badge is cleared.