For conservators & researchers

You are responsible for a born-digital work and need to understand its technical body, reproduce it, and document how it runs. This system gives you a deterministic evidence base plus an AI analyst that reasons over it — and a workbench to actually boot the result.

The mental model

A project is one artwork. Everything derives from the untouched original bundle. The work moves through stages — analysis → research workbench → (eventually) exhibition — and its position is durable, so anyone can pick up where it was left.

Status today: analysis + research workbench are the working system. The automatic lock-into-exhibition (evmctl) hand-off is planned, not built — see the overview.

What the analysis guarantees

The deterministic layer does no guessing and no set-fitting. It extracts generic signals — formats, dependencies, entry points, and every network-protocol indicator in the code — and hands them to the AI, which judges what they mean for this work. Two rules matter for your practice:

1. Network reach is a MUST, not a nicety. If a work is broken because it can’t reach a host, you need to know which host — to restore it or serve it from an archive. The analyst is required to look at every network indicator, even at the cost of chasing false positives, and to cite the code it read before classifying a URL as real / constructed / a field default.
2. Nothing is fitted to one artwork. The tools flag files fairly (no starvation, no scheme-matching that would drop a URL a work builds up over several steps); the AI reconstructs and judges. A report about your work is evidence about your work.

Read The autopsy for what’s in a report and how to read it.

The preflight checkpoint (step 1.5)

Between upload and the expensive analysis, a preflight pass inspects the bundle. If it looks like it bundles a runtime installer or a full runtime install tree alongside the art, it pauses and asks you: “is this only the artwork?” — it never rejects (a self-installing or Python-packed work is a legitimate artwork). You confirm to proceed (it reuses the already-unpacked files) or cancel to re-upload the artwork’s own files. This keeps the analysis pointed at the art, not its runtime’s vendor boilerplate.

The research workbench

Once analyzed, you clone the era-correct machine(s) and boot the work:

• A broad library of golden images. Working today: Windows 98 SE, 2000, XP / Server 2003, 7, 8.1, 10 (22H2), 11 — each with an in-guest agent so the controller can drive the guest — plus Mac OS 9.2.2 (PowerPC) with a MacPython agent, Mac OS X 10.4 Tiger (PowerPC), and Mac OS X 10.6 Snow Leopard (Intel). In progress: Windows 98 SE period networking (the agent runs; the era NIC is being finalised).
• Pick more than one base to compare fidelity (e.g. XP vs. 2000).
• Network capture to watch what the work actually reaches at runtime.
• Save-points to freeze a known-good running state.

See Working in the VM.

Your deliverables

• Report / manifest — the layered picture (host / guest / network), entry point, fidelity risks.
• Dependency manifest — the conservator’s view: what must be provisioned to run the work.
• Asset catalogue — the researcher’s view: what the work is actually made of.
• The artist’s hand — the historian’s view: the artist’s own words, harvested from the source and the decompiled code — comments, authorship and copyright lines, contact URLs, the voice inside the work.
• Runbook — the ordered environment-construction plan.
• Suggestions — the base VM and the tools/runtimes to stock.
• KB docs — rendered notes on the work.

These are written to the project’s drive and survive independently of the tooling — a report from ten years ago still reads.

Bring your own AI

The analysis needs an LLM and you supply it — your key, your provider, your bill. See Bring your own AI.