A generative image may exist before being viewed, after executing a program, or only when a transaction fixes the seed that produces it. It may be acquired as a file, print, token, software edition or installation that continues to generate variations. Calling all these elements a "work" without distinguishing between them transfers ambiguity to the contract, the inventory and the preservation.
Algorithm, execution and output
It is advisable to separate algorithm, code, execution and output. To these are added seed, libraries, version, device, interface and external data. Two executions may share an algorithm and produce different outputs. A file may preserve the result while losing the generative capacity.
Stating that "the algorithm is the work" may be an artistic position or a platform rule. It does not describe every generative work.
The Art Blocks model
Art Blocks presents its architecture through an explicit premise: the algorithm is the work. The artist writes a script; upon minting, the chain generates a unique hash that is introduced into the code; the deterministic execution produces the output.
The specific output is not fixed until the seed associated with the token is generated. The artist decides the system and tests its behaviour; the collector activates an execution; the platform assigns the seed, token and record.
The purchase fixes a possibility
Before minting, the project defines a field of possible results. Afterwards, a seed fixes a specific output. Not all projects function in this manner: some select results before selling them, others maintain the program in continuous execution and others deliver a print and retain the system.
Token, file and work are not synonyms
Token, smart contract, script, seed, libraries, metadata, rendered output, derivatives and rights may coexist. The token identifies a unit and records relationships, but it does not by itself grant exploitation rights.
Art Blocks asserts that scripts, registered dependencies and seeds allow for the reconstruction of the works without the company's servers, within its architecture and as long as the chain and compatible means to interpret it exist.
What a museum would request
The Metropolitan Museum's procedures for software show a different logic. It may request a contract, licence, certificate, instructions, executable, source, libraries, images, editor, third-party applications, external components and an approved computer.
It does not treat the visible output as a sufficient package. To preserve the execution, dependencies, tools and authorisations must be documented.
Acquiring an output, an edition or a system
There are at least three operations: acquiring a fixed output, an executable edition or a generative system. The difference affects the exhibition, the environment, the seeds, the number of results and the selection.
Contract, certificate and technical documentation should coincide. When they do not, the collection may possess files that it is not authorised to transform or rights that it cannot exercise because it lacks the environment.
Selection is also part of the model
Generating and selecting are different operations. If the selection defines which results receive the status of work or edition, it must be stated in the file. No comparable primary file has been located that documents from beginning to end an institutional acquisition based on subsequent selection by the artist.
Preserving the rule and preserving the result
A collection may preserve an image and lose the program; preserve the code and lose a library; execute the program and obtain a different output because the browser changed. It is advisable to register version, seed, generation mechanism, libraries, licences, environment, master files, authorised results, expected behaviour, tests and rights.
Checksums prove that a file has not changed. They do not prove that future execution will produce the same experience.
What the public record does not show
Public records rarely reveal contracts, code, licences, seeds, instructions or credentials. It should not be inferred that an institution lacks those materials because it does not publish them.
What Art Blocks does not represent
The case does not represent every generative practice, every on-chain work, real-time installations, systems with external data or works whose code is not delivered. Neither does it guarantee permanent preservation in an absolute sense.
To take action
The guide on documenting a generative work allows for the registration of algorithms, seeds and parameters. For dependencies, consult how to preserve creative code. If there is a token, how OBJKT and Tezos work helps to separate platform, chain, file and ownership. For the services and accounts upon which a work may depend, consult invisible dependencies in digital art; to decide what should enter a collection, acquiring digital art.
About the open conversation
The very definition of these terms remains open. What does each project understand by work, edition, seed, output, and generative system? And what occurs when contract, token, files, code, and execution capacity do not point to the same object?
The Art Blocks architecture describes how that platform is organised. It does not serve as a universal definition, nor does it allow one to deduce how other artists, collections, or institutions operate.
If you are an artist, collector, or institutional representative and you maintain a file in which those elements did not coincide, this notebook remains open: write to me. A description that protects confidential data is sufficient.