How it fits together

vmctl keeps born-digital artworks alive in three stages. One artwork moves left to right — from a dead bundle of bytes, to a proven running machine, to a piece a museum switches on every morning. Each stage has exactly one job, and the boundary between stages is a durable handoff (a thing you can put on a shelf), not a live wire. This page is the map: what each stage produces, what it hands to the next, and the vocabulary the rest of these docs are built on.

The three stages, end to end

1. Autopsy — understand

Take an artwork bundle and work out what it actually is: the runtime it needs, the crucial components, and — for a broken piece — every network host it reaches. Deterministic tools extract the evidence; an agentic analyst judges it. No VM, no repair.

Produces: a conservation-grade report and a machine-readable revival contract — for each dead endpoint, the concrete format a revival has to reproduce.

How the autopsy works →

2. Workbench — revive

Clone an era-correct golden VM, apply the revival techniques the work needs, install the artwork, and drive it until it runs. Capture the live network, freeze known-good states, and define what “healthy” means. This is where the AI and the human are — expensive, and done once per artwork.

Produces: a proven project — a running machine that demonstrably runs, plus the shims, mirrors, and conservation plugin(s) it needs to keep running unattended.

Inside the workbench →

3. Exhibition — run

The north star. A proven work is baked into one standalone image and handed to a dedicated gallery machine, which plays it behind a self-healing heartbeat watchdog. On any fault it reverts to the ready-snapshot in seconds — no boot, no AI, deterministically, forever.

Produces: a frozen, reproducible exhibition instance a museum can run for months.

The exhibition runner →

The handoffs — what actually crosses each boundary

The stages are deliberately decoupled. Get the boundaries wrong and everything downstream rots, so each handoff is a concrete artefact:

Autopsy → Workbench. The report’s suggested base VM pre-fills the golden picker, and the revival contract tells the workbench what a revived endpoint has to look like. The workbench reads these off the artwork’s own durable drive.
Workbench → Exhibition. A promotion bundle — the baked image plus its boot config (snapshot name and plugins), the conservation plugin, and signed provenance. The bundle carries the ready state; the live ready-snapshot itself is stamped on the field machine, only after the baked image proves it still runs there.

The moving parts

The vocabulary the rest of the docs assume. One line each.

Bundle The artwork exactly as it arrived — the untouched original upload. Everything else is derived from it, and it is never modified.

Revival contract & verdict The autopsy's machine-readable output: the verdict (what the work is, in a sentence) plus, per dead endpoint, the exact format a revival must reproduce.

Golden base image An era-correct VM from the catalog — the right Windows or Mac of the work's time — cloned fresh per project so the artwork runs on the machine it expects.

The in-guest agent A small per-OS helper inside the VM — the controller's hands in the guest: run commands, move files, send keys, take screenshots, read the event log.

Revival technique A reusable, data-driven repair recipe the workbench applies to a running work — a shim, a mirror, a re-point of a dead endpoint — chosen from the work's capabilities.

Plugin A conservation plugin: the declarative bring-up plan that boots and holds a specific work in its correct state, and rides the exhibition heartbeat.

Ready-snapshot A live memory + disk snapshot of the warmed, verified-good VM. A revert resumes the exact running state in 3–5 seconds with no boot — the exhibition's self-heal.

The egress doors The controlled exits a revived work is allowed to reach out through — pointed at an archive or a mirror, never the open live internet — so preserving a work never means freezing the real web.

The layer model underneath

The three stages are one method made operational: research for as long as it takes to get the work into a three-layer runtime model, then bake the innermost layer and never touch it again.

Layer 1 — the conservation object. The VM guest: OS, runtime, plugins, artwork. The workbench authors it; the handoff freezes it as the ready-snapshot; it is never modified after that.
Layer 2 — the preservation infrastructure. The host controller and the archive-replay proxy — serviceable, replaceable, and where the exhibition runner lives.
Layer 3 — the managed external dependencies. The live internet and other outside services, isolated behind the egress doors so they can be swapped without disturbing the work.

The reason for the split is a finding from six months of real exhibition operation: every error inside the encapsulated environment recovered automatically; every failure outside it needed a human. So Layer 1 is baked and inviolable, and all the fragility is pushed out to Layers 2 and 3.

Where each piece lives

These docs are one site in a small family — one home per stage.

vmctl.org — the hub Where born-digital conservation came from, where it's going, and how to help.

autopsy.vmctl.org Stage 1 — the artwork-autopsy analysis, its own home.

research.vmctl.org Stage 2 — the research workbench, plus the whitepaper host.

exhibition.vmctl.org Stage 3 — the locked, long-running gallery runner.

All the source lives under the ZKM org at github.com/zkmkarlsruhe, MIT licensed.