Skip to content
vmctl

Bring your artwork — the lifecycle

This is the full guided flow, from an untouched bundle to a running research VM. In the workbench it appears as a vertical set of steps whose completed-state is derived from the project’s real state (not a local wizard), so it’s resumable across sessions and shared between collaborators.

The flow ends today at a running, verified research VM. The eventual step — locking the result into evmctl for unattended exhibition — is the north star, not yet wired.

Step 1 — Identity

Tell the system what the work is: title, artist, when it arrived, provenance. These are human-authority priors — facts the bytes can’t reveal — and they legitimately outrank byte-derived guesses where they don’t contradict hard evidence (a PE header still wins over a hint about the OS).

Step 2 — The original

Upload the artwork’s original bundle. It’s stored immutable in the project’s artwork/ and never modified; every later artifact is derived from it. Upload the artwork’s own files — the projector/app plus its casts/data — not a runtime installer (see step 1.5).

Step 1.5 — Preflight (the checkpoint)

After upload, a fast deterministic pass unpacks and inspects the bundle before the expensive analysis. Two outcomes:

  • Clean → it advances to analysis automatically.
  • Looks like a bundled runtime (an installer or a runtime install tree dominating the upload) → it pauses and asks: “Preflight — is this only the artwork?” You see what it found and choose:
    • Proceed — this is the artwork (a self-installing / packed work is legitimate; the run resumes over the already-unpacked files), or
    • Cancel & re-upload artwork-only files (the upload bundled the runtime; start over with the work’s own files).

Preflight never rejects — it only asks. It exists so the analysis studies the art, not its runtime’s vendor boilerplate.

Step 2 — Autopsy

The analysis runs. A deterministic layer extracts the ground truth (formats, entry point, dependencies, and every network indicator); an agentic analyst then maps the crucial parts, judges each network endpoint, and writes the report. It runs with no caps — until it has a coherent picture or you cancel — and shows a live progress log; a Cancel button composes a partial report from whatever it found so far (never a lost run).

You need an LLM for this step — bring your own AI.

Output: verdict, entry point, suggested base VM, suggested runtimes, network endpoints, and the revival runbook. See The autopsy.

Step 3 — Base VM(s)

The report is shown before you choose, so the choice is informed. Then you pick the era-correct machine(s) from the golden-image catalog — the analysis pre-checks its suggestion(s). This is a multi-select: check more than one (e.g. Windows XP and Windows 2000) and Clone & boot starts one VM per checked golden, so you can compare how the work behaves across eras.

Step 4 — Helpers

Stock the runtimes the work needs (players, libraries) onto the machine, guided by the analysis’s tool suggestions.

Step 5 — Into the workbench

The original plus the helpers ride a data-link CD into the guest — no manual copying. Attach it to a running VM, open the screen, and the work is in front of you.

From here you work in the VM: capture its network, fix what’s needed, and save known-good states.

What “done” means today

A work is done in the current system when it boots and runs verifiably in an era-correct VM, with a report and runbook documenting how. Freezing that into a long-running exhibition instance (evmctl) is the planned next stage.