The exhibition — running a proven work on the wall

The exhibition stage is a player, not a rebuilder. By the time a work reaches it, the hard part is done: the workbench has already reconstructed the machine the work needs, run the work inside it, and proved it comes up. The exhibition controller’s only job is to keep that one proven machine running on the wall — every morning, for months, without a technician standing by.

Everything here is deliberately narrow. There is no analysis, no LLM, no rebuilding. It boots one baked image, watches it, and heals it when it breaks.

The handoff: one baked image of a proven work

The workbench doesn’t hand over a recipe — it hands over the finished machine. When a researcher promotes a verified work, it lands on a “done shelf”: a browsable catalog of finished artworks, each one a single self-contained bundle. Every entry is checksum-signed; the catalog re-hashes each bundle and shows its integrity before you can download it. A bundle that fails verification is flagged and refuses to hand out a download.

You take one work off the shelf as a single self-contained zip. It carries everything the exhibition host needs — a flattened standalone disk image, the machine definition, the per-artwork configuration, and any conservation archive the work reaches for. Nothing in it points back at the research tooling: no golden base to resolve, no catalog to consult, no network to the workbench. That was all baked in when the work was promoted.

On the exhibition host, one command imports it:

evmctl import <artwork.zip>

The importer unpacks the zip and re-hashes every file against its manifest — a tampered or corrupted bundle is refused, not installed. It places the disk image, rewrites the machine definition to point at the local paths, defines the machine, and — critically — creates the ready snapshot the player will always fall back to. If that snapshot can’t be created, the import fails outright: it refuses to install an exhibit that could never recover itself. You never end up with a work on the floor that has no safety net.

Bake, boot, prove, ready-snapshot

When the controller starts, it doesn’t just boot the disk and hope. It runs a fixed sequence:

1. Revert to the ready snapshot. The controller always starts the work from its known-good baseline, never from whatever state the disk happened to be left in.
2. Prove it came up. It polls the machine’s guest agent until the guest actually responds — proof the work booted, not just that the machine powered on. If the guest never answers, that’s surfaced loudly and the watchdog (below) takes over; the controller doesn’t declare a silent machine healthy.
3. Stamp the ready-snapshot. The baseline the controller reverts to is a live snapshot — memory and disk together, taken of the running, proven work. This is the key move: reverting to it resumes the machine from that instant rather than cold-booting it.

That distinction is what makes unattended recovery viable. A cold boot of an old guest — POST, operating system, the artwork’s own startup, waiting for it to settle — can run into minutes, all of it visible on the gallery wall. Resuming from a live memory-and-disk snapshot drops the machine back onto the proven frame in a few seconds. Recovery is a resume, not a reboot.

The heartbeat watchdog and auto-revert

Once the work is up, the running guest sends a heartbeat to the controller on a steady interval. That heartbeat is the single signal that says “the exhibit is still alive and doing its job.” The controller watches two things at once, several times a second:

• Is the machine still running at all? If the guest has crashed or powered itself off, that’s caught within the check interval.
• Is the heartbeat still arriving? If the work has wedged — frozen, hung, stopped responding while the machine is technically still “on” — the heartbeat stops. When it’s been silent past the timeout (a matter of seconds, not minutes), that counts as a failure.

Either condition triggers the same automatic response: revert to the ready snapshot. The watchdog resumes the proven machine from its live baseline, waits for the guest to prove it’s responsive again, and re-arms itself. No technician is involved. The exhibit heals itself and keeps running.

A short back-off window after each recovery stops the watchdog from firing again while the machine is still coming back up, so a slow resume can’t stack a second revert on top of the first. And when a recovery restart doesn’t reach a responsive guest, the watchdog does not pretend the exhibit is healthy — it leaves the clock running and retries, rather than re-arming over a machine that’s still hung.

Fail-closed: it won’t run dirty, and it won’t sit dead

The whole stage is built to fail closed — toward a safe, known state — never open toward “just show whatever’s on the disk”:

• It refuses to boot un-reverted state. If the ready snapshot is missing, the controller will not start the machine from the raw disk. Booting mutable, possibly-tampered state would put an unverified exhibit on screen and — worse — let the auto-recovery path “recover” into that dirty state. Instead it refuses and asks an operator to restore the baseline first. A work only ever runs from its proven baseline.
• It won’t let a dead exhibit sit there. The heartbeat is the whole point: a wedged or crashed work is caught in seconds and reverted, rather than staying frozen on the wall until someone notices.
• Heartbeats are only trusted from the work itself. The controller accepts a heartbeat only from the running guest’s own network. An external host on the museum LAN — or a stray monitoring script — can’t post a fake heartbeat to hold the watchdog off over a dead exhibit. If the controller can’t even determine which network the guest is on, it rejects the heartbeat and lets the watchdog do its job, rather than assuming everything is fine.
• Guest content can’t destroy the safety net. The running work is often a period browser pointed at the host. A stray URL in archived or proxied artwork content must never be able to delete the ready snapshot or stop the machine. Destructive operations are blocked when they originate from the guest’s own network, and blocked by default when the network can’t be determined.

The one exception is deliberate maintenance: an operator can disable auto-revert to work on the machine, and that intent is honoured — an in-flight recovery or a scheduled restart won’t silently override an operator who has just stopped the exhibit on purpose.

Why this matters for a months-long exhibition

A media-art work on the wall has to survive being switched on every morning and left alone all day, for the length of a show. Old software wedges. Guests crash. A work that phones an archive can trip over a slow response. None of that can mean a black screen that waits for a technician who may not be in the building.

The exhibition player answers that with unattended reliability: one proven machine, a live baseline it can resume in seconds, and a watchdog that reverts to that baseline the moment the work stops proving it’s alive. The failure mode isn’t “the exhibit is down until someone fixes it” — it’s “the exhibit blinked and healed itself.” That’s the difference between a research VM and a piece a museum can actually run.

Where this sits in the pipeline

This is stage three. The autopsy works out what a work is; the workbench rebuilds and proves the machine it needs. The exhibition player takes that proven machine and runs it. It has its own home at exhibition.vmctl.org.