Con una cuenta desbloqueas el cuestionario, el foro de dudas y el tutor con IA de esta lección, además del registro de progreso y el certificado verificable al terminar «Sistemas Distribuidos para Misiones Espaciales».
El clúster produce datos científicos: deben resistir a un revisor externo
El clasificador de señales de este clúster no solo emite una etiqueta ("esta señal es de tipo X"): produce un dato científico que, en principio, alguien externo al equipo debería poder auditar y, en la medida de lo posible, reproducir. Esa exigencia — pensar cada resultado como algo que un revisor escéptico examinará después — cambia por completo qué información hay que registrar en el momento en que el resultado se produce, no después.
Procedencia formal: el modelo W3C PROV
Este curso adopta el vocabulario del estándar W3C PROV para describir de forma estructurada de dónde viene cada dato: una entidad es un dato o artefacto concreto (una observación IQ cruda, una predicción de pase, una clasificación); una actividad es el proceso que produjo o consumió una entidad (ejecutar el clasificador, generar una predicción TLE); un agente es quién o qué es responsable de la actividad (una versión concreta del modelo, un usuario, un servicio). Sobre estos tres conceptos se construyen relaciones explícitas: derived-from (esta entidad se derivó de aquella otra), input-of (esta entidad fue insumo de esta actividad) y validates (esta actividad valida o corrobora el resultado de aquella otra). El resultado es un grafo dirigido y auditable, no una nota de texto libre sobre "de dónde salió el dato".
Huellas criptográficas: inputs_sha256
Declarar en texto qué insumos se usaron para producir un resultado ("usé la observación IQ del pase de las 14:00") no es verificable por sí solo: cualquiera podría escribir esa declaración sin que sea cierta. La solución es acompañar cada declaración de insumos con su hash SHA-256 (inputs_sha256): el hash exacto del archivo o payload que efectivamente se usó. Si alguien más tiene acceso al mismo insumo, puede calcular su propio hash y compararlo — coinciden si y solo si es exactamente el mismo dato, byte a byte. Un hash que no coincide con el insumo declarado es, en sí mismo, un motivo de rechazo de la cadena de procedencia: es la diferencia entre "yo digo que usé esto" y "esto es matemáticamente demostrable que fue lo que se usó".
Cadenas de derivación con veredicto
Una cadena completa de procedencia — por ejemplo, TLE → predicción de pase → observación IQ → clasificación — se audita de extremo a extremo, y el resultado de esa auditoría se etiqueta con un veredicto explícito: completa (cada eslabón tiene su hash, su actividad y su agente registrados y verificables) o con huecos tipados (se sabe exactamente qué eslabón falta o no pudo verificarse — no es un "no sabemos", sino un hueco nombrado y localizado). Un veredicto de "con huecos tipados" es honesto y útil; fingir una cadena "completa" cuando en realidad tiene huecos es el error que la siguiente sección nombra directamente.
Reproducibilidad práctica: la tripleta config + semilla + commit
Para que una corrida científica sea reproducible en la práctica (no solo en teoría), basta con registrar tres cosas juntas: el hash de la configuración usada (todos los parámetros del proceso), la semilla de cualquier fuente de aleatoriedad involucrada, y el commit de git exacto del código que se ejecutó. Esta tripleta — config_hash + semilla + commit — identifica una corrida de forma inequívoca: la misma tripleta, ejecutada de nuevo, produce el mismo resultado byte a byte. Si dos corridas con la misma tripleta producen resultados distintos, hay un bug de no-determinismo que hay que encontrar y corregir, no una casualidad aceptable.
No verificar lo inverificable: la "procedencia teatral"
El error más peligroso en este terreno no es no tener procedencia — es afirmar una verificación que en realidad no se hizo. Si un sistema declara "hash de insumos externos verificado" cuando en realidad nunca tuvo acceso a esos insumos externos para recalcular el hash y compararlo, eso es procedencia teatral: una afirmación que parece rigurosa pero que nadie puede sostener si se le pregunta cómo se verificó. Es estrictamente peor que declarar honestamente el límite ("no podemos verificar este insumo externo; lo registramos como recibido, sin verificación independiente") — la honestidad documental sobre lo que no se pudo comprobar vale más que una afirmación de rigor que no resiste el escrutinio.
FAIR y citabilidad: una visión de hacia dónde se dirige esto
Los principios FAIR (datos Findable, Accessible, Interoperable, Reusable) y mecanismos como un DOI emitido a través de DataCite son el horizonte natural de este enfoque: un dataset científico producido por el clúster, con su cadena de procedencia completa y sus hashes verificables, puede en principio recibir un identificador citable permanente y ser descubierto y reutilizado por terceros exactamente como un artículo publicado. El clúster de este curso aún no implementa esa capa por completo — se menciona aquí como la dirección hacia la que apunta toda la disciplina de procedencia que sí está en producción.
Visualicemos una cadena de procedencia completa:
¿Qué demuestra el campo inputs_sha256 en una cadena de procedencia?
8. Custodia de datos: un backup no probado no es backup