In a generative artwork, the visible file may be merely one output of a system capable of producing many. Saving that image does not necessarily preserve the algorithm, the rules of variation or the decisions that distinguish a valid run from an anomaly.
Documenting the artwork means describing what must remain, what may vary, who may decide it and how each result is recorded. No universal legal or technical rule exists to determine when two outputs are the same work: that identity must be formulated and sustained by the artist's intention, the edition documents and the practice of conservation.
Which part is the artwork
Begin by explicitly choosing what constitutes the artwork:
- the generative system;
- a specific run;
- a selected output;
- a set of outputs;
- an installation that generates in real time;
- the code together with equipment or an interface;
- an edition of tokens or copies;
- a combination of these layers.
Do not use ‘generative artwork’ as a sufficient answer. Two artworks may execute similar code and be of a different nature: one may be a program that never repeats its result, another an image chosen and fixed, another an edition in which each copy corresponds to a seed.
Record that decision in the master artwork record.
Code, algorithm and runtime environment
Preserve and document:
- code repository and version;
- language and version;
- libraries, plug-ins and models;
- operating system, browser or engine;
- compiler or build tool;
- typefaces, data and resources;
- hardware or necessary capabilities;
- external services and network communications;
- installation and running instructions;
- licence for each dependency when it affects preservation or delivery.
Distinguish algorithm from implementation. The conceptual rule may survive code rewriting, but an implementation contains decisions that affect the result: order of operations, numerical precision, pseudo-random generator, colour, timing or error handling. The Guggenheim project on metadata for software-based art notes, among its conclusions, the need to define how to document software dependencies to track their obsolescence. The guide Preserving a digital artwork explains how to separate source file, master, exhibition copy and derivatives.
Seed: what it fixes and what it does not
A seed initiates a pseudo-random generator. In some works, it allows for the reproduction of an output; in others, it does not, because the following also intervene:
- version of the random algorithm;
- order of calls;
- clock and time zone;
- public input;
- network data;
- sensors;
- concurrency;
- hardware and precision;
- changing external resources.
Do not promise reproducibility because you have saved a number. Test the same seed in a clean installation and record the runtime environment. If the artwork uses non-deterministic randomness, document that decision and preserve reference results.
For each run, note at least:
- run identifier and artwork version;
- commit or code version;
- seed and parameters;
- external inputs;
- date and runtime environment;
- file or result and its checksum;
- selection or rejection and its reason;
- responsible person.
Parameters and permitted ranges
List all parameters that may affect the artwork and classify them:
- fixed;
- configurable by the artist;
- configurable by the venue;
- modified by the public;
- obtained from external data;
- random within a range;
- automatically derived.
Do not record only the value used today. Note range, unit, default value, dependency and expected effect. A parameter may admit technical variation without admitting any aesthetic variation. The following example is a proprietary model, not a standard:
| Parameter | Value or range | Who sets it | Effect | Requires approval |
|---|---|---|---|---|
| seed | integer | system or artist | initial configuration | per edition |
| palette | closed set | artist | colour | yes to expand it |
| density | 20–80 | venue | visual complexity | no within range |
| resolution | technical minimum | venue | output | validate |
| live data | indicated source | external service | behaviour | agreed substitution |
Inputs and external data
If the system receives data, document:
- source and owner;
- format and frequency;
- time period;
- applied transformation;
- storage and privacy;
- behaviour in the event of absence or error;
- possibility of using recorded data;
- effect of an API change.
An artwork that responds to the weather, a wallet or an interaction may never produce the same result. Conservation must fix the behaviour and the limits, not feign an output identity that the artwork does not possess.
The range of permitted results
Create a set of references:
- captures or recordings of valid runs;
- extreme but acceptable examples;
- rejected results and reason;
- properties that must always appear;
- behaviours that indicate failure;
- expected duration or frequency.
One case illustrates why a single result is insufficient. The Whitney Museum registers Color Panel v1.0 (1999), by John F. Simon Jr., as software, a modified PowerBook 280c and acrylic, in an edition of 3/12, and collects the artist's words describing it as a painting that changes continuously and does not repeat. With such an artwork, a single result documents an instant, not the system (interpretation).
The Variable Media Network, which emerged within the Guggenheim's orbit, proposes identifying medium-independent behaviours that must be preserved for an artwork to remain visible. Its Variable Media Questionnaire serves to record the opinions of creators on how to conserve an artwork when its medium becomes obsolete, using strategies such as storage, emulation, migration, or reinterpretation. These are case-by-case conservation practices, not a legal rule.
Automatic selection and artist selection
Distinguish between four situations:
- the system displays any valid output;
- the artist selects certain outputs after they are generated;
- an automatic rule selects or discards;
- the public or the institution chooses.
Record who selects, according to what criteria, and at what moment. A chosen and signed output may become an autonomous copy; a capture of any run may be merely documentation (interpretation: this depends on the artwork's documents and the artist's practice).
Preserve the criteria and, where relevant, the record of discards. It is not necessary to archive millions of variants if the system and its range are sufficiently documented, but that decision must be conscious.
What may vary and what must remain
Formulate the significant properties of the artwork. These may include:
- the relationship between rules and chance;
- the distribution of forms or sounds;
- the palette or chromatic range;
- speed and duration;
- scale and resolution;
- continuous or repetitive character;
- degree of interaction;
- latency;
- the relationship with a data source;
- the appearance of the equipment;
- the capacity to produce non-repeated results.
The Guggenheim project on software-based art is based on the premise that these works must reproduce an aesthetic experience faithful to the artist's original intention. Do not confuse a significant property with an immutable implementation. A library may be replaced without altering the artwork; in another piece, the specific behaviour of that library may be constitutive.
System, run, variant, copy, and edition
Use separate terms, as documentary tools rather than automatic legal categories:
- system: rules, code and runtime environment capable of generating;
- run: an activation of the system;
- output: the result produced;
- variant: a permitted result that differs from another;
- copy: a unit identified and transmitted within the artwork or edition;
- edition: a delimited set of copies according to declared rules.
If there is an edition, determine:
- size and closure;
- the relationship between seed and copy;
- the possibility of regeneration;
- artist's proofs;
- failed, discarded, or annulled outputs;
- technical backup copies;
- what occurs if an output is lost;
- whether a seed may be reused.
The guide Technical sheet, certificate, and invoice explains the function of each document and how to identify an edition and a copy. For the certificate, consult How to certify a digital artwork and its editions.
Token, seed, and file
In a tokenised artwork, record separately:
- network and contract;
- token identifier;
- issuing wallet;
- seed and the place where it is stored;
- the code that generates;
- metadata;
- file or rendering;
- minting and reveal rules.
The guide How OBJKT works notes that the token and the contract may continue to exist on the chain even if viewing the artwork or reading its metadata requires other tools. A token may represent an output, a licence, an access, or an edition unit, depending on the contract and the documentation.
Intention interview
The interview does not replace technical analysis. It serves to record decisions that the code does not explain:
- what does the artist consider the artwork to be?
- what variations are acceptable?
- what failures transform its meaning?
- can the code be rewritten?
- can the equipment be changed?
- what visual or sonic precision matters?
- who may approve a migration?
- what must occur if a data source disappears?
- would the artist prefer the artwork to cease functioning rather than be reinterpreted?
The Tate Conservation Department collects interviews with artists to guide future care and exhibition, and warns on its conservation interviews page that an artist's memory may be incorrect or partial. Contrast the statement with archives, versions, analysis, and actual operation.
Re-execution test
Do not consider the artwork documented until another person can install or execute it by following the instructions.
Perform a test in a clean runtime environment:
- start from the archived package;
- install dependencies without tacit memory;
- execute reference seeds and parameters;
- compare results and behaviour;
- record errors, skipped steps, and timings;
- correct the documentation;
- preserve the evidence of the test.
If it only functions on the artist's computer, you remain dependent on that computer and on non-transferred knowledge.
Checklist
- It is defined what part constitutes the artwork.
- Code, version, and dependencies are identified.
- Seed and reproducibility conditions have been tested.
- Parameters, ranges, and those responsible are recorded.
- External sources and behaviour in the event of failure are described.
- Valid, extreme, and rejected examples exist.
- Automatic, artistic, and institutional selection are distinguished.
- Significant properties and admissible changes are declared.
- System, run, output, copy, and edition are not confused.
- The interview is linked to the artwork and dated.
- Another person has performed a re-execution test.
Further reading
- Master artwork record.
- Technical sheet, certificate, and invoice.
- How to certify a digital artwork and its editions.
- Preserving a digital artwork.
- How OBJKT works.
Sources
- Variable Media Network. Case-by-case conservation practice, born from the Guggenheim's conservation work, which seeks medium-independent behaviours; page date: not located (inaugural conference, March 2001).
- Variable Media Questionnaire. Case-by-case conservation practice: an instrument for recording opinions on how to conserve works whose medium becomes obsolete; third public version of 2010.
- Software Preservation Network, Developing Metadata for Software-based Art. Institutional source on documenting software dependencies and aesthetic experience faithful to the artist's intention; Guggenheim project within the FCoP programme; entries from 2019 and 2020.
- Tate, Conservation interviews. Conservation interviews with artists; page date: not located.
- Whitney Museum, John F. Simon Jr., Color Panel v1.0. Collection case, not a general rule: 1999 work, edition 3/12; page date: not located.
Status: Verified. Review: 11 October 2026. This guide does not replace a software conservation assessment or a contract adapted to a specific artwork. If you find a change, a broken link, or an error, write to me.