artwork-autopsy
Analysis service that opens an undocumented born-digital artwork and works out what it is, what it needs to run, and how to revive it.
What it does
Point it at a zip, a disk image or a loose bundle of files and it produces two things: a report on what the work actually is — entry point, runtime, operating system, the network hosts it expects — and a runbook for bringing it back to life.
It is the triage step in front of the vmctl workbench, but it stands on its own.
How it works
Deterministic identification first, no AI involved: file formats and signatures via siegfried and magika, Director casts, QuickTime, Java fingerprints, Max patches, classic Mac resource forks, entry-point detection. Then the runtime modules take over. Only afterwards does an optional analyst step assemble the traces into a picture — and a second, independent pass checks every finding back against the source.
Where it is uncertain, it stops and asks rather than guessing. The human decides what is the artwork and what is scaffolding.
Runtime modules
Around twenty-one and growing, one per family of thing you find in a collection: Director, Flash, Authorware, Java, QuickTime, VRML/X3D, native Windows PE, .NET, Classic Mac and HyperCard, Web/HTML, DOS, console ROM, script interpreters, Max/MSP, ScummVM engines, modern web, Firefox and Safari extensions, Pulse3D, Unity — plus a generic fallback. Every work analysed adds to the collection, for everyone.
AI is optional
It runs fully deterministic with no model at all. The AI analyst is opt-in and bring-your-own — any OpenAI-compatible endpoint. That was a deliberate design decision: a conservation tool should not require sending an artwork to a third party to be usable.
Alpha, MIT licensed. Part of the vmctl toolchain.