SpaceMusic Vault

What a studio forgets

A studio that makes physical things accumulates files effortlessly and loses knowledge effortlessly. The two happen at the same time, and only one of them is visible.

The files survive. Every geometry file we have ever made is still sitting in Dropbox, and will be in ten years. What does not survive is everything that was never written down: which material that piece was cut from, what the machine settings were, whether it warped on the first attempt, which script generated the form in the first place. That knowledge lives in someone's memory for about a year and then it is gone — and the file, on its own, cannot tell you any of it.

There is a second, quieter problem. The pieces we actually produced — the ones that came off the printer or the laser cutter and exist as objects — are a vanishingly small fraction of what is on disk. A single parameter sweep can generate two hundred renders; perhaps five of them were ever made. Those five are scattered among hundreds of thousands of working files, indistinguishable from everything that was tried and abandoned.

The Vault exists to solve exactly three problems, and no others: finding a piece again years later, reusing what went into it, and showing it — on a website, in a proposal, on an exhibition label.

The standard shape of a catalogue

The conventional answer to this is a digital asset manager: point a tool at your storage, let it index everything it finds, and search the resulting file list. We looked seriously at that category and it does not fit, for reasons worth stating plainly.

1. Photo library tools. Built for images and video, with no concept of geometry files. They cannot preview or understand anything we make. Photoprism, Piwigo, Damselfly
2. Open-source asset managers. Credible and genuinely open, but photo- and document-centric, and all of them expect to take ownership of your storage. None generates previews for the file types we work in. ResourceSpace, Pimcore, Phraseanet
3. Desktop taggers. The right philosophy — tag-based, keeps its own library, does not disturb your folders — but single-machine, with no interface anything else can talk to. Eagle, TagStudio, TagSpaces
4. Our own Factory. Already browses SpaceMusic exports, groups them into runs, and lets you mark favourites. It is the right tool, pointed at a different body of work — the cloud library, not the studio's physical output. The Vault does not touch it. factory.spacemusic.tv
5. Our position. Every tool above starts by indexing everything and asks you to filter down. The Vault inverts that: it starts empty and only ever contains what someone deliberately put in.

What we already run

The most useful thing to say about this project is how little of it is new. The SpaceMusic platform already provides most of what a catalogue needs: a dedicated server with single sign-on in front of it, object storage, a shared API gateway, and — importantly — the Worker fleet, which already runs headless Rhino on studio machines to convert geometry without anyone opening a program.

That last point matters more than it sounds. Generating a thumbnail and a web-viewable 3D file from a geometry file is the single hardest engineering problem in a project like this, and it is the one we have already solved for other reasons. The Vault adds a tool to an existing fleet rather than building a conversion pipeline from nothing.

An earlier research pass on this project recommended building our own database, our own login system, our own admin interface, our own API and our own preview pipeline. That advice was sound in isolation and wrong in context — it was written without knowledge of the platform. Roughly four of those five already exist. What is genuinely missing is the catalogue itself.

Curation as the entry condition

The load-bearing decision is this: nothing enters the Vault automatically. There is no scan of Dropbox, no file index, no background discovery. An entry exists only because a person — or an assistant acting on a person's instruction — decided that a specific produced object deserved a record.

We call that record an Artifact, and the unit is deliberate: one produced object is one Artifact, however many files went into making it. The two-hundred-render sweep produces perhaps five Artifacts. This is the difference between a catalogue whose central claim is everything in here is a thing we made and a file browser with a search box.

Three sources fill an Artifact in, and the balance between them is the design's most important practical property. The system derives what it can measure. A vision model proposes what it can see in a render. A person supplies only what neither can know — the judgement. The Vault has to be useful on day one with no human input at all, because a three-person studio will not fill in forms, and a catalogue that depends on people filling in forms is a catalogue that stays empty.

Process is the part worth defending. Everything else about an Artifact can be reconstructed from its files if you have to; the material, the settings and the outcome cannot. It is also the part that answers the question we will actually ask in three years, which is rarely where is that file and almost always what was that made of, and did it work.

Where everything lives

Curating a piece copies its files into a folder the Vault owns, and that folder sits on Dropbox rather than on the server. This is purely arithmetic: the server has around 500 GB in total, and Dropbox holds roughly 13 TB today with room to grow, already mirrored to the NAS in the studio. Source geometry and process video would exhaust the server within months.

The server still keeps the small things — thumbnails and web-viewable 3D, single-digit gigabytes even at thousands of pieces — so that browsing is fast and so that publishing a piece to a website is a permission change rather than a file transfer. Everything, including those, is written to Dropbox as the backup of record.

One detail in that picture is worth explaining because it looks like an overcomplication and is not. Three of our machines sync the same Dropbox folder. If two of them write the same file at the same moment, Dropbox does not raise an error — it silently creates a second copy named conflicted copy and carries on. A catalogue quietly accumulating those would be genuinely unpleasant to untangle. So every write into the Vault Folder is routed through one machine, using the same job mechanism the Worker fleet already uses for everything else. Saving in the CMS queues the work rather than doing it directly. The cost is a few seconds; the benefit is that the failure mode cannot occur.

The catalogue itself lives in a database on the server, but each piece's folder on Dropbox also receives a plain, readable file describing what it contains. Nothing reads that file back — it exists so that the Vault Folder still makes sense to a person browsing Dropbox in ten years, with or without our software, and so the catalogue could be rebuilt if the server were lost.

Costs and deliberate omissions

The back catalogue will take years to enter, and that is the design working as intended rather than a shortfall. Pieces go in one at a time, with an assistant doing the tedious part — reading a folder, proposing a title and a description, drafting the record — and a person confirming it. Drafts wait for that confirmation, because an inferred description is confidently wrong often enough that it should not enter a permanent record unreviewed.

The real risk is not technical. It is that curation is a habit, and habits die when the tool is tedious. That is the single reason the CMS was chosen on the quality of its editing interface rather than on what would have been most convenient to run — it means adopting one framework that differs from the rest of the platform. We accepted that deliberately: an unpleasant tool produces an empty vault, and an empty vault is worse than none.

Two smaller costs. Generating 3D previews needs a studio machine switched on, so previews appear shortly after curation rather than instantly. And conversion from our geometry formats is imperfect — some files will need a preview exported by hand at the time the piece is made.

Deliberately out of scope, so that they are not quietly assumed: long-term archival and succession planning; the SpaceMusic cloud library, which Factory already owns; our reusable scripts and patches, since nothing there was physically produced; and login federation, which is real work for a tool with three users.

Why this matters

"The files were never the thing at risk. What we lose is the knowledge of how something was made, and we lose it quietly, about a year after making it."

What changes if we build this: an exhibition label comes out of a record instead of out of someone's memory. Reusing a form from three years ago stops being archaeology. The website pulls published pieces directly, without anyone assembling a folder of images by hand. And because the catalogue is reachable programmatically, an assistant can answer questions we currently cannot ask — which of our brass pieces warped, and what were the settings on the ones that didn't — because for the first time that information exists somewhere other than in a person's head.

What we lose if we do not: nothing dramatic, and that is exactly the problem. The files stay safe on Dropbox and the knowledge keeps evaporating at the same rate it does now, invisibly, one project at a time. The cost of starting is a few weeks of assembly on infrastructure that is already running and already paid for. The cost of not starting is only ever noticed in retrospect.

Glossary

Terms used in this document, in plain language.

Artifact

One thing the studio physically produced, recorded as one entry in the Vault — however many files went into making it.

Authentik

The single sign-on system already in front of every SpaceMusic service. It decides who is allowed to reach the Vault at all.

Curation

The act of deciding that a produced object deserves a record, and writing that record. Nothing enters the Vault any other way.

Derivative

A file the Vault generates from an Artifact's own files — a thumbnail, or a 3D file a web browser can display. Always regenerable, and the only kind of file ever made public.

Factory

factory.spacemusic.tv. Our existing browser for SpaceMusic exports and the cloud library. A different corpus; the Vault does not touch it.

glb

A compact 3D file format that web browsers can display without any plugin. What we generate so pieces can be viewed online.

MCP

Model Context Protocol. The standard way an assistant like Claude connects to a system. It is how the Vault becomes queryable in conversation rather than only through a web page.

MinIO

The file storage already running on our server. Fast to serve from, but small — hence its limited role here.

Payload

The content management system chosen for the Vault: the interface where an Artifact is actually created and edited.

Postgres

The database holding the catalogue — every Artifact's title, year, tags and Process.

Process

How a piece came to be: machine, material, settings, outcome, and the scene or script it originated from.

Vault Folder

The directory on Dropbox where the Vault keeps its own copy of every Artifact's files, in a layout it controls.

Worker

The existing SpaceMusic tool that lets a studio machine take on background jobs — already used for headless geometry conversion, and now for Vault file writes and previews.