Made by AI, Directed by David Stein

Search
Community

Preservation Tutorial: Getting Started With Archiving Your Own Digital Artwork

Documenting a piece photographically is not the same as being able to run it in ten years. A practical starting routine for software-based work: freeze the dependencies, write the disposition, and record the artwork's behaviour, not just its appearance.

7 min read

If you make work that runs — a shader, a Processing sketch, an installation with a microcontroller in it, a web piece, a Max patch — then you have a problem that painters do not. Your work has dependencies, and dependencies have expiry dates.

This is distinct from documenting a piece photographically, which is about making an image of the work. This is about being able to run it later, or failing that, to let someone else reconstruct what running it was like.

The three ways a digital work dies

Worth naming, because each needs a different countermeasure.

Bit rot. The files are gone or corrupted. Drives fail, accounts lapse, a service shuts down, a format stops being readable. This is the easiest problem and the one everyone assumes is the only problem.

Dependency rot. The files are fine and the work will not run. The library had a breaking change, the browser removed the API, the shader needs a GPU extension nobody ships, the toolchain wants a compiler version that no longer builds, the platform requires a signing certificate that expired. This kills more software-based art than disk failure, and backups do not help at all.

Knowledge rot. The files run and nobody knows whether what they see is correct. Was the flicker intentional? Was it that fast? Was it meant to be silent? This one is permanent once it happens, and the only defence is writing things down while you still know them.

Step 1: Freeze the dependencies, not just the source

Your source code is the smallest part of what you need. Alongside it, capture:

  • Exact versions of everything. Not “p5.js” — p5.js 1.9.0. Commit a package-lock.json, requirements.txt with pinned versions, Cargo.lock, or whatever your stack’s equivalent is. A pinned version list is the difference between “rebuild this” and “guess what this was”.
  • The dependency files themselves. Vendor them. Put the actual p5.min.js in the folder. Registries disappear, packages get unpublished, and a lockfile pointing at a dead URL is a list of things you no longer have.
  • The toolchain. Record the compiler, interpreter, OS and version you built and ran it on. “Worked on macOS 14 with Python 3.11” is a sentence your future self will be glad of.
  • Hardware, if it matters. Board revision, sensor part numbers, screen resolution, GPU. If the piece was tuned to a specific display’s refresh rate or a specific sensor’s noise floor, that is part of the work.

A reasonable test: hand the folder to someone else and ask them to run it without asking you a question. Whatever they have to ask is what is missing.

Step 2: Write the disposition

This is the single highest-value document and almost nobody makes one. It is a plain-language statement of what the work is supposed to do, written for a person who has never seen it.

Cover:

  • What a viewer should see and hear, in order, including how it starts and whether it ends.
  • Timing. Durations, speeds, cycle lengths. “The colour cycle takes about 40 seconds” is unrecoverable from source code that computes it from a frame rate.
  • What is intentional that looks like a bug. Glitches, stutters, dropouts, asymmetries. This is the one that saves the work.
  • What is a bug that you tolerate. Equally important — it tells a future restorer what they are allowed to fix.
  • Variability. If the piece is generative or responds to input, say what varies and what must not. Describe the envelope, not one instance.
  • Failure modes. How it behaves when a sensor is unplugged or the network is down, and whether that state is acceptable to show.

Two or three pages is plenty. Write it in the same folder as the code, as plain text or Markdown, so it travels with the work.

Step 3: Record the behaviour

Photographs capture appearance. Software-based work needs evidence of behaviour.

  • Screen capture of a full cycle, at real speed, with audio. Not a highlights edit — an unedited run long enough to show the work’s whole range.
  • A video of the physical installation if there is one, including the room, the viewer’s distance, and someone interacting with it.
  • Stills at known moments, labelled with timestamps into the capture.
  • A recording of the inputs, if the piece responds to something. A log of the sensor data during a capture lets someone verify a future reconstruction produces the same output from the same input, which is as close to a regression test as this gets.

Keep these in a format that is boring and widely supported. Boring is the goal throughout.

Step 4: Choose formats that will still open

The institutional rule of thumb is simple: prefer open, documented, widely implemented formats, and keep the original anyway.

  • Code and text: plain text, UTF-8.
  • Documents: PDF/A or Markdown, not a proprietary editor’s format.
  • Images: PNG or TIFF for masters; keep camera RAW if you have it.
  • Video: a widely supported codec for access copies, plus the highest-quality master you possess.
  • Audio: WAV or FLAC masters.
  • Data: CSV or JSON, not a database dump that needs a specific server version.

Keep the original files as well as the converted ones. Conversion loses things you did not know mattered, and the original is the only record of what was actually made.

Step 5: Store it so it survives you

  • Three copies, two media, one off-site. The old rule, still correct.
  • Checksums. Generate SHA-256 for every file and store the list with them. Without checksums you cannot tell a good copy from a silently corrupted one, and a corrupted file propagates happily through backups. shasum -a 256 on macOS and Linux, or Get-FileHash in PowerShell, is all you need.
  • Verify on a schedule. Annually, re-run the checksums and compare. An unverified backup is a hypothesis.
  • Do not rely on one platform. A cloud account is not an archive. GitHub is not an archive. Anything with a terms-of-service and a login can stop being yours.
  • Tell someone where it is. An archive nobody can find is not an archive. Put the location and any credentials somewhere a trusted person can reach them.

Step 6: Consider emulation early

For work that depends on an environment rather than just libraries, the long-term answer is usually emulation or containerisation: preserve a runnable environment rather than hoping to port the work forever.

You do not have to solve this now, but you can make it possible later by recording what the environment was precisely enough to rebuild it. A Dockerfile that successfully runs your piece today is both a build script and a specification of the environment, and it is worth writing for that second reason alone.

The minimum viable version

If you do nothing else, do these four things for your most important piece this week:

  1. Put the code, the vendored dependencies and a pinned version list in one folder.
  2. Write two pages saying what the work does and which strange parts are deliberate.
  3. Record one unedited full-cycle capture with audio.
  4. Copy the folder to two places, one of them not in your house, and save a checksum list.

That is an afternoon, and it moves the piece from “will be lost” to “can be reconstructed”. Everything else in this article is refinement.

Sources

Related Reading