En una obra generativa, el archivo visible puede ser solo una salida de un sistema capaz de producir muchas. Guardar esa imagen no conserva necesariamente el algoritmo, las reglas de variación ni las decisiones que distinguen una ejecución válida de una anomalía.
Documentar la obra significa describir qué debe permanecer, qué puede variar, quién puede decidirlo y cómo se registra cada resultado. No existe una regla jurídica o técnica universal que determine cuándo dos salidas son la misma obra: esa identidad debe formularse y sostenerse con la intención del artista, los documentos de edición y la práctica de conservación.
Qué parte es la obra
Empieza por elegir, de forma explícita, qué constituye la obra:
- el sistema generador;
- una ejecución concreta;
- una salida seleccionada;
- un conjunto de salidas;
- una instalación que genera en tiempo real;
- el código junto con un equipo o interfaz;
- una edición de tokens o ejemplares;
- una combinación de estas capas.
No uses «obra generativa» como respuesta suficiente. Dos trabajos pueden ejecutar código parecido y ser de naturaleza distinta: uno puede ser un programa que nunca repite su resultado, otro una imagen elegida y fijada, otro una edición en la que cada ejemplar corresponde a una semilla.
Registra esa decisión en la ficha maestra de obra.
Código, algoritmo y entorno
Conserva y documenta:
- repositorio y versión del código;
- lenguaje y versión;
- bibliotecas, complementos y modelos;
- sistema operativo, navegador o motor;
- compilador o herramienta de construcción;
- tipografías, datos y recursos;
- hardware o capacidades necesarias;
- servicios externos y comunicaciones de red;
- instrucciones de instalación y ejecución;
- licencia de cada dependencia cuando afecte a la preservación o entrega.
Distingue algoritmo de implementación. La regla conceptual puede sobrevivir a la reescritura del código, pero una implementación contiene decisiones que afectan al resultado: orden de operaciones, precisión numérica, generador pseudoaleatorio, color, temporización o tratamiento de errores. El proyecto del Guggenheim sobre metadatos para arte basado en software señala, entre sus conclusiones, la necesidad de definir cómo documentar las dependencias de software para poder seguir su obsolescencia. La guía Conservar una obra digital explica cómo separar archivo fuente, máster, copia de exhibición y derivados.
Semilla: qué fija y qué no
Una semilla inicia un generador pseudoaleatorio. En algunas obras permite reproducir una salida; en otras no, porque intervienen además:
- versión del algoritmo aleatorio;
- orden de llamadas;
- reloj y zona horaria;
- entrada del público;
- datos de red;
- sensores;
- concurrencia;
- hardware y precisión;
- recursos externos que cambian.
No prometas reproducibilidad porque hayas guardado un número. Prueba la misma semilla en una instalación limpia y registra el entorno. Si la obra usa aleatoriedad no determinista, documenta esa decisión y conserva resultados de referencia.
Para cada ejecución, anota al menos:
- identificador de la ejecución y versión de la obra;
- commit o versión del código;
- semilla y parámetros;
- entradas externas;
- fecha y entorno;
- archivo o resultado y su suma de verificación;
- selección o descarte y su motivo;
- persona responsable.
Parámetros y rangos permitidos
Lista todos los parámetros que puedan afectar a la obra y clasifícalos:
- fijos;
- configurables por el artista;
- configurables por la sede;
- modificados por el público;
- obtenidos de datos externos;
- aleatorios dentro de un rango;
- derivados automáticamente.
No registres solo el valor usado hoy. Anota rango, unidad, valor por defecto, dependencia y efecto esperado. Un parámetro puede admitir variación técnica sin admitir cualquier variación estética. El ejemplo siguiente es un modelo propio, no un estándar:
| Parámetro | Valor o rango | Quién lo fija | Efecto | Requiere aprobación |
|---|---|---|---|---|
| semilla | entero | sistema o artista | configuración inicial | según edición |
| paleta | conjunto cerrado | artista | color | sí para ampliarla |
| densidad | 20–80 | sede | complejidad visual | no dentro del rango |
| resolución | mínimo técnico | sede | salida | validar |
| datos en vivo | fuente indicada | servicio externo | comportamiento | sustitución pactada |
Entradas y datos externos
Si el sistema recibe datos, documenta:
- fuente y titular;
- formato y frecuencia;
- periodo temporal;
- transformación aplicada;
- almacenamiento y privacidad;
- comportamiento ante ausencia o error;
- posibilidad de usar datos grabados;
- efecto de un cambio de API.
Una obra que responde al clima, una cartera o una interacción puede no producir nunca el mismo resultado. La conservación debe fijar el comportamiento y los límites, no fingir una identidad de salida que la obra no tiene.
El rango de resultados admitidos
Crea un conjunto de referencias:
- capturas o grabaciones de ejecuciones válidas;
- ejemplos extremos pero aceptables;
- resultados rechazados y razón;
- propiedades que siempre deben aparecer;
- comportamientos que indican fallo;
- duración o frecuencia esperadas.
Un caso ilustra por qué no basta con un resultado. El Whitney Museum registra Color Panel v1.0 (1999), de John F. Simon Jr., como software, un PowerBook 280c modificado y acrílico, en una edición 3/12, y recoge palabras del artista que la describen como una pintura que cambia continuamente y no se repite. Con una obra así, un único resultado documenta un instante, no el sistema (interpretación).
La Variable Media Network, nacida en el entorno del Guggenheim, propone identificar comportamientos independientes del medio que deben preservarse para que una obra siga siendo visible. Su Variable Media Questionnaire sirve para registrar la opinión de los creadores sobre cómo conservar la obra cuando el medio queda obsoleto, con estrategias como almacenamiento, emulación, migración o reinterpretación. Son prácticas de conservación caso por caso, no una regla legal.
Selección automática y selección del artista
Distingue cuatro situaciones:
- el sistema muestra cualquier salida válida;
- el artista selecciona algunas salidas después de generarlas;
- una regla automática selecciona o descarta;
- el público o la institución elige.
Registra quién selecciona, con qué criterio y en qué momento. Una salida elegida y firmada puede convertirse en un ejemplar autónomo; una captura de cualquier ejecución puede ser solo documentación (interpretación: depende de los documentos de la obra y de la práctica del artista).
Conserva los criterios y, cuando sea relevante, el registro de descartes. No hace falta archivar millones de variantes si el sistema y su rango están suficientemente documentados, pero esa decisión debe ser consciente.
Qué puede variar y qué debe permanecer
Formula las propiedades significativas de la obra. Pueden incluir:
- relación entre reglas y azar;
- distribución de formas o sonidos;
- paleta o rango cromático;
- velocidad y duración;
- escala y resolución;
- carácter continuo o repetitivo;
- grado de interacción;
- latencia;
- relación con una fuente de datos;
- aspecto del equipo;
- capacidad de producir resultados no repetidos.
El proyecto del Guggenheim sobre arte basado en software parte de que estas obras deben reproducir una experiencia estética fiel a la intención original del artista. No confundas propiedad significativa con implementación inmutable. Una biblioteca puede sustituirse sin alterar la obra; en otra pieza, el comportamiento específico de esa biblioteca puede ser constitutivo.
Sistema, ejecución, variante, ejemplar y edición
Usa términos separados, como herramientas documentales y no como categorías jurídicas automáticas:
- sistema: reglas, código y entorno capaces de generar;
- ejecución: una activación del sistema;
- salida: resultado producido;
- variante: resultado permitido que difiere de otro;
- ejemplar: unidad identificada y transmitida dentro de la obra o edición;
- edición: conjunto delimitado de ejemplares según reglas declaradas.
Si hay edición, determina:
- tamaño y cierre;
- relación entre semilla y ejemplar;
- posibilidad de regeneración;
- pruebas de artista;
- salidas fallidas, descartadas o anuladas;
- copias técnicas de respaldo;
- qué ocurre si una salida se pierde;
- si puede reutilizarse una semilla.
La guía Ficha técnica, certificado y factura explica qué función cumple cada documento y cómo identificar edición y ejemplar. Para el certificado, consulta Cómo certificar una obra digital y sus ediciones.
Token, semilla y archivo
En una obra tokenizada, registra por separado:
- red y contrato;
- identificador del token;
- cartera emisora;
- semilla y lugar donde se almacena;
- código que genera;
- metadatos;
- archivo o renderizado;
- reglas de acuñación y revelado.
La guía Cómo funciona OBJKT recuerda que el token y el contrato pueden seguir existiendo en la cadena aunque ver la obra o leer sus metadatos exija otras herramientas. Un token puede representar una salida, una licencia, un acceso o una unidad de edición, según el contrato y la documentación.
Entrevista de intención
La entrevista no sustituye el análisis técnico. Sirve para registrar decisiones que el código no explica:
- ¿qué considera el artista que es la obra?
- ¿qué variaciones son aceptables?
- ¿qué fallos transforman su sentido?
- ¿puede reescribirse el código?
- ¿puede cambiar el equipo?
- ¿qué precisión visual o sonora importa?
- ¿quién puede aprobar una migración?
- ¿qué debe ocurrir si desaparece una fuente de datos?
- ¿prefiere que la obra deje de funcionar antes que reinterpretarla?
El Departamento de Conservación de Tate recoge entrevistas con artistas para orientar el cuidado y la exhibición futuros, y advierte en su página de entrevistas de conservación que la memoria de un artista puede ser incorrecta o parcial. Contrasta la declaración con archivos, versiones, análisis y funcionamiento real.
Prueba de reejecución
No des por documentada la obra hasta que otra persona pueda instalarla o ejecutarla siguiendo las instrucciones.
Haz una prueba en un entorno limpio:
- parte del paquete archivado;
- instala dependencias sin memoria tácita;
- ejecuta semillas y parámetros de referencia;
- compara resultados y comportamiento;
- registra errores, pasos omitidos y tiempos;
- corrige la documentación;
- conserva la evidencia de la prueba.
Si solo funciona en el ordenador del artista, todavía dependes de ese ordenador y de conocimientos no transferidos.
Lista de comprobación
- Está definido qué parte constituye la obra.
- Código, versión y dependencias están identificados.
- Semilla y condiciones de reproducibilidad se han probado.
- Parámetros, rangos y responsables están registrados.
- Fuentes externas y comportamiento ante fallo están descritos.
- Existen ejemplos válidos, extremos y rechazados.
- Se distingue selección automática, artística e institucional.
- Propiedades significativas y cambios admisibles están declarados.
- Sistema, ejecución, salida, ejemplar y edición no se confunden.
- La entrevista está vinculada a la obra y fechada.
- Otra persona ha realizado una prueba de reejecución.
Para seguir
- Ficha maestra de obra.
- Ficha técnica, certificado y factura.
- Cómo certificar una obra digital y sus ediciones.
- Conservar una obra digital.
- Cómo funciona OBJKT.
Fuentes
- Variable Media Network. Práctica de conservación caso por caso, nacida de la labor del Guggenheim, que busca comportamientos independientes del medio; fecha de página: no localizada (conferencia inaugural, marzo de 2001).
- Variable Media Questionnaire. Práctica de conservación caso por caso: instrumento para registrar opiniones sobre cómo conservar obras cuyo medio queda obsoleto; tercera versión pública de 2010.
- Software Preservation Network, Developing Metadata for Software-based Art. Fuente institucional sobre documentación de dependencias de software y experiencia estética fiel a la intención del artista; proyecto del Guggenheim dentro del programa FCoP; entradas de 2019 y 2020.
- Tate, Conservation interviews. Entrevistas de conservación con artistas; fecha de página: no localizada.
- Whitney Museum, John F. Simon Jr., Color Panel v1.0. Caso de colección, no regla general: obra de 1999, edición 3/12; fecha de página: no localizada.
Estado: Verificada. Revisión: 11 de octubre de 2026. Esta guía no sustituye una evaluación de conservación de software ni un contrato adaptado a una obra concreta. Si encuentras un cambio, un enlace roto o un error, escríbeme.