Chapter 2 · 2 of 6

How it reads a work

It works the way a careful conservator would — first pin down the hard facts with mechanical, repeatable tools and translate the work’s compiled code back into something readable, then hand that evidence to a single AI analyst that reads it, maps the crucial parts, and judges every network address the work reaches for. Extraction is mechanical; the judgement is the model’s — and it cites its evidence and flags what it cannot resolve.

Reading an unfamiliar work is not one big leap of judgement. First you establish what is actually there — unpack it, identify every file format, recover the code in readable form — and only then do you reason about what it means. artwork-autopsy runs in exactly that order: deterministic tools — fixed, mechanical steps that give the same answer every time, with no AI involved — do the extracting, and a single analyst — an AI model given tools and time to work through the evidence step by step — does the judging, over what they laid out.

The stages

• What the conservator already knows comes first. Anything you supply about the work — the runtime you believe it uses (the player software it needs, like Flash Player or Macromedia Director), the intended operating system, the year, the peripherals, how it was meant to behave — is seeded as top-authority evidence before a single byte is parsed. Everything the tools go on to find is weighed against what a human already established.
• Intake. The bundle is unpacked into an untouched working copy — nested archives, installers and disc images unpacked all the way down — the file tree laid out, and every format identified from its bytes: a recognisable signature inside the file itself, not a file extension taken on trust.
• Preflight — a pause for a person. Before the expensive read, a quick check asks whether the upload is really just the artwork, or whether it also carries a runtime installer — the setup program for the player software rather than the piece itself. It never rejects — an installer can legitimately be the artwork — it only flags the signal and puts the question to the researcher, who knows which it is.
• Static core — deterministic, no model. It parses each file with the conservation field’s own standard tools — PRONOM / Siegfried for format identity, magika (machine-learned content-type identification) as a second opinion, lief for reading program binaries, JHOVE for validity, Apache Tika for metadata — then builds a run-graph: a map of the work’s moving parts, recording what starts it, what loads and reads what, and what talks to the network. This is the map the analyst will navigate.
• Orient — where does it start, and what here is the work? A work often carries its whole runtime beside itself — a Mac Java installation of some two and a half thousand files, a bundled Director/Shockwave player, a node_modules tree, a Python site-packages. Mapped file by file, that buries the artwork in thousands of nodes and can mistake the runtime’s own files for the entry point. So before the deep read, the deterministic pass draws a compact portrait of the bundle — the file tree plus what the program headers already gave up — and an LLM judge reads that portrait to settle two things no pattern-match can: which file is the entry point, and which parts are the artwork versus off-the-shelf software it merely ships with. Only then are the unambiguous bundled runtimes each collapsed to a single opaque node — in the analysis map only; nothing is deleted, the runtime still ships into the machine — and the judged work files and entry point always survive the collapse, so a work’s launcher never vanishes with its engine. When the judge is genuinely unsure, its doubt surfaces as a question to the researcher rather than a silent guess.
• Deep-readers — one per runtime. For each runtime the work actually uses, an expert reader decompiles it — translates the compiled, machine-only code back into something a person can read: Lingo scripts for Director, sources for Java or .NET, disassembly for a native binary — and persists that evidence for the analyst. The reading queue keeps draining until a pass turns up nothing new, so files discovered late — an archive inside an archive, a movie carved out of a program — still get read.
• The analyst — an AI session that runs to completion. A dedicated tool-using agent — its own model, not the fast classifier the earlier stages use — navigates the recovered evidence like a conservator with the sources open. It does not one-shot a summary: it walks the run-graph as a cartographer, laying a grounded flow over the skeleton so every conclusion stays tied to the extracted evidence. It maps the crucial parts, cites each claim to a file and line, judges every network endpoint, flags what it could not resolve, and lists what it deliberately left unexplored. It runs unbounded — a work with three hundred endpoints reviews all three hundred; the only clock is the researcher’s, who can stop it. Should a session die mid-read it hands its partial findings to the next, and every endpoint it had already seen is kept even then. It reads what the deterministic tools extracted — it never runs the work.
• Ask the researcher — when it is genuinely unsure. The preflight pause is the shipped shape of a general capability: at any point the analyst can put a question to the person. The session blocks, the human answers in the web UI, and it resumes with that answer folded in as authority — judgement handed back to a person exactly where a machine should not guess.
• A second opinion — an independent judge. An independent LLM judge, a separate AI model from the analyst, re-evaluates the finished result. This is distinct from the mechanical completion gate below: the gate checks that the read is structurally complete; the judge checks whether the reasoning actually holds.
• Done, or honestly partial. Whether the read is finished is not the model grading its own homework. A mechanical gate decides it: the entry point resolved, the dependency graph closed, every important part actually read, and every network endpoint either resolved or flagged. Only then is it done; short of that it is returned as an explicit partial — never dressed up as complete.
• Narrate & synthesise. The findings become a plain conservator’s write-up and are projected into the three documents you take away.

Every endpoint accounted for

One duty is treated as a conservation must: the analyst inventories every internet endpoint — every web address or server the work reaches for — and judges each one: is it essential to the artwork, mere runtime noise, or built at runtime from parts? This matters because a dead backend is so often why a work no longer runs. Some addresses are not even written out anywhere in the code — a net.art piece might assemble its address on the fly from a seed host and something the visitor types — and those are called out as constructed, so whoever revives the work knows a live server, not just a file, has to be stood back up.

What a dead server actually served

Naming a dead address is only half the answer; the other half is what it served. So the analyst settles that during the analysis, by querying the Internet Archive’s Wayback Machine — the public archive of what websites looked like at every point in the past — through the shared wayback-mcp, a small companion service the analyst can call, offering four read-only tools: wayback_snapshots (the index of every capture, scoped to the work’s own era), wayback_available (the capture closest to a chosen moment), wayback_fetch (the ground truth — the archived bytes and their content-type), and wayback_prognosis (cheap triage over a whole cluster of dead URLs at once). Resolving a dead endpoint is a search-and-judge loop, not a lookup, so a wayback specialist sub-agent drives these tools while the service stays dumb and factual. This turns a “this endpoint is gone” finding into a concrete revival contract that names the real format a revival must reproduce. It is integral to the analysis, not a downstream add-on.