JARVISLabs

E-stop during a GPU render: every owned process settled in 374.68 ms

On 19 September an E-stop was triggered while a local image-generation mission was rendering on the GPU. It was acknowledged in 19.4 ms, all three owned processes had settled by 374.68 ms, none survived, and no artifact was published.

LIVE-PROVEN What this run supports. Recorded 19 September 2026.

Footage pending

This run is documented from its recorded evidence. Footage has not been published: capture waits for the machine to be free of local model measurements, and every clip is reviewed for private information first.

Asked

What was asked

Stop everything while a GPU image render is in progress.

Result

What happened

An image mission was admitted and began rendering (step 1 of 4). The E-stop was triggered and acknowledged in 19.4 ms. The solver lifecycle settled its three owned child processes, all gone by 374.68 ms. The mission ended as failed with 'solve cancelled before publication'. No artifact was published and the core shut down cleanly.

Pipeline

Architecture path

  1. E-stop trigger
  2. EStop latch
  3. Mission cancellation
  4. Solver lifecycle settles owned children
  5. Mission marked failed
  6. No publication
  7. Clean shutdown

What this proves

  • An E-stop reached a running GPU job and settled all of its owned processes, with zero survivors, in 374.68 ms on this run.
  • A stopped mission is recorded as failed and cancelled, with no partial artifact published.

What it does not prove

  • A single run is not a latency distribution or a worst case.
  • Recorded on 2026-09-19; a recorded run is not a current reading.
  • It does not qualify the constitution's under-150 ms mid-utterance E-stop budget, which concerns a different path.
  • It says nothing about physical devices; no hardware was actuated.

Context

Local image generation runs as a governed mission. The core owns the worker processes, and they run inside quotas for wall time, CPU, memory and GPU. That makes it a good test of the E-stop. A GPU render is expensive, runs in child processes and is easy to leave half-finished.

The run

A render mission was admitted (“solver local.image admitted”) and reached the rendering state, step 1 of 4. At its peak it had about 8.4 GB of GPU memory allocated. The E-stop was then triggered.

  • The stop was acknowledged in 19.4 ms.
  • All three owned processes settled by 374.68 ms, with 0 survivors.
  • The worker’s state became cancelled, and the mission’s state became failed with the detail “SolveCancelled: solve cancelled before publication”.
  • artifact_available was false: no partial image was published.
  • The core shut down cleanly.

A companion case the same night killed the core in the middle of a render. The mission came back BLOCKED without re-rendering, and again no owned process survived.

The evidence

docs/ledger/evidence/A06/estop.json records the operation, the acknowledgement and stop timings, the checkpoint at the moment of the stop, the worker’s quota and exit state, the survivor count and the clean shutdown. It was read at 01:32 UTC on 19 September against head 71fbf83e. No footage exists yet.

The limits

This is one stop on one kind of job. It shows that the E-stop reaches GPU child processes and that nothing is published after the stop. It is not a worst-case figure and not a distribution. The project’s under-150 ms E-stop budget applies mid-utterance, to speech, and this run does not qualify it. Settling software processes is also a different claim from stopping a physical machine. For the printer, the project records the E-stop’s local trip time but lists the printer’s actual pause as unproven.