JARVISLabs

A four-step research mission, completed in 10.8 s

On 16 September a four-step mission to gather and file NASA news ran to completion in 10.8 s on the normal launcher. JARVIS then answered 'where are we' and 'what failed' from the mission record, not from memory of the conversation.

LIVE-PROVEN What this run supports. Recorded 16 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

Run a short multi-step research task on NASA news and file the summary, then report status and any failures.

Result

What happened

The request became a durable mission, persisted before step one. Four steps ran in order, each read back, and the summary was filed in 10.8 s. 'Where are we' and 'what failed' were answered from the mission record. Hold and cancel on the finished mission were answered honestly, and a separate 20-step widget close also ran as a mission.

Pipeline

Architecture path

  1. Owner request
  2. Lane classifier (mission)
  3. MissionStore persist
  4. Admission
  5. Step loop with governance per step
  6. Read-back
  7. Summary filed
  8. Status answered from record

What this proves

  • On the normal launcher, a four-step mission completed in 10.8 s with its summary filed.
  • Status and failure questions are answered from the durable mission record.
  • Control commands on a finished mission report the true state instead of pretending to act.

What it does not prove

  • One run is not reliability.
  • Recorded on 2026-09-16; a recorded run is not a current reading.
  • Skip was driven in-process only, not live.
  • Surviving a machine reboot is not shown; a process kill is not accepted as a substitute.

Context

A mission is JARVIS’s form for work that takes more than one step. The mission engine writes the mission to SQLite before step one. Every step’s inputs, outputs and status are recorded as they happen, so a mission can be inspected or resumed without any model context. Each step passes through the governance chain and is read back before the next step starts.

The run

In the 16 September closure pass on the normal launcher, a four-step research mission on NASA news ran to completion in 10.8 s, and its summary was filed. The owner then asked “where are we” and “what failed”. Both were answered from the mission record: the answers came from the stored step states, not from the conversation. Asking to hold or cancel the already-finished mission produced an honest answer that it was finished, with no pretence of stopping anything. In the same pass, a 20-step widget close ran as a mission.

The evidence

The MISSIONS row of docs/analysis/JARVIS_CAPABILITY_MODEL_2026-09-16.md (commit f6aec1cf1) classifies missions as PROVEN_LIVE on the normal launcher and records the 10.8 s run. Post-LM acceptance journeys J2, J3 and J7 cover related mission behaviour and are recorded LIVE_VERIFIED, from readings that predate 17 September. No footage exists yet.

The limits

A single run shows that the path works, not that it is reliable. The same row records that “skip” was driven in-process only and that a distinct BLOCKED state is still owed. Surviving a full machine reboot (CAP-MSN-07) is not proven, and the project explicitly refuses to count a process kill as a substitute. The 10.8 s figure is a wall-clock observation for this mission. It is not a benchmark of mission speed in general.