Cliente: Centrica Soluciones
Proyecto: Nebula ERP — Componente DataVault / Nebula Vault
Versión: 2.0
Fecha: 25 de junio, 2026
Autor: Carlos Torres (Arquitecto de Software)
Estado: PROPUESTA — auditoría de estándares y plan de implementación pleno (pendiente de aprobación)
Naturaleza de este documento. Es una auditoría canónica y agnóstica del componente de preservación frente al estándar internacional OAIS (ISO 14721) y su familia de normas. No describe únicamente lo construido: contrasta (a) lo que dice el estándar, (b) lo que pidió el cliente, (c) lo que realmente hay en el código y (d) lo que se debería implementar. La evaluación del código es deliberadamente crítica y sin adornos; se aplica criterio técnico-profesional, no juicio de valor sobre personas.
| Versión | Fecha | Cambio |
|---|---|---|
| 1.0 | 2026-03-16 | Documento de preservación e integridad as-designed (checksums, semáforo, metadata, ciclo de vida, §7 análisis de cumplimiento OAIS con gaps). |
| 2.0 | 2026-06-25 | Reescritura como auditoría canónica de estándares: marco agnóstico OAIS+familia, mapeo de las observaciones del cliente (sesión jun-2026), auditoría crítica del código real con evidencia, plan de implementación según estándar y visión de parametrización total (archivos, cargas, IA). Los gaps de la v1.0 (§7.2/§7.3) seguían abiertos y se reconfirman. |
Esta parte describe el estándar tal cual es, sin referencia a nuestra implementación, para que sirva de patrón de medida neutral.
OAIS no es un software ni una arquitectura concreta: es un modelo de referencia que define un vocabulario y un conjunto de funciones que cualquier archivo digital de largo plazo debe cubrir.
| Paquete | Significado | Propósito |
|---|---|---|
| SIP (Submission Information Package) | Lo que el productor entrega | Entrada, sujeto a validación |
| AIP (Archival Information Package) | El paquete que se conserva a largo plazo | Preservación; no se consulta directamente |
| DIP (Dissemination Information Package) | Lo que se entrega al consumidor | Acceso/difusión; derivado del AIP |
Un AIP = Content Information (el objeto + su Representation Information, que lo hace interpretable) + PDI (Preservation Description Information). La PDI, en la edición 2012, tiene 5 componentes:
| Componente PDI | Pregunta que responde | Estándar de metadatos típico |
|---|---|---|
| Provenance (Procedencia) | ¿De dónde viene, quién lo custodió, qué se le hizo? | PREMIS Events/Agents |
| Context (Contexto) | ¿Cómo se relaciona con otros objetos? | METS structMap, relaciones PREMIS |
| Reference (Referencia) | ¿Cómo se identifica de forma única y persistente? | Identificadores persistentes (Handle/ARK/DOI/URN) |
| Fixity (Fijación/Integridad) | ¿Cómo sé que no se alteró? | Checksums SHA-256/512 + PREMIS fixity |
| Access Rights (Derechos de acceso) | ¿Quién puede acceder y bajo qué condiciones? | PREMIS Rights |
(a) Negociar y aceptar información apropiada de los productores; (b) obtener control suficiente para la preservación; (c) determinar la Comunidad Designada (Designated Community); (d) garantizar que la información sea independientemente comprensible para esa comunidad; (e) seguir políticas y procedimientos documentados; (f) hacer la información disponible y producir DIPs.
El plan de preservación parametrizable que pide el cliente es la materialización de (c), (d) y (e): definir, por entidad, qué tipologías y formatos se aceptan y cómo se conservan en el tiempo.
| Estándar | Rol | Qué aporta |
|---|---|---|
| OAIS — ISO 14721 | Modelo de referencia | Vocabulario, paquetes, entidades funcionales |
| PREMIS Data Dictionary v3 | Metadatos de preservación | 5 entidades: Intellectual Entity, Object, Event, Agent, Rights |
| METS (Library of Congress) | Empaquetado/estructura | Manifiesto que une ficheros, metadatos y estructura |
| Dublin Core / MODS | Metadatos descriptivos | Catalogación para búsqueda y comprensión |
| PDF/A — ISO 19005 | Formato de preservación | PDF autocontenido y estable; validable con veraPDF |
| PRONOM / DROID (The National Archives) | Registro e identificación de formatos | Detecta formato real y su riesgo de obsolescencia |
| ISO 16363 / TRAC | Auditoría de repositorios confiables | Criterios para certificar un Trustworthy Digital Repository |
| NF Z42-013 / ISO 14641 | Archivado con valor probatorio | Garantías de integridad y trazabilidad legal |
Equivalencia clave: las "5 partes" del PREMIS que mencionó el cliente = las 5 entidades PREMIS (Objeto, Agente, Evento, Derechos/Acceso, Entidad Intelectual). El cliente está pidiendo PREMIS completo y parametrizable, no inventado.
Observaciones de la sesión de junio 2026 (Carlos —cliente—, Edgar, Jorge Manchola), traducidas a la entidad/estándar OAIS que les corresponde. Sirve para demostrar que lo pedido es estándar, no capricho.
| Observación del cliente | Entidad/estándar OAIS | Veredicto |
|---|---|---|
| "Necesitamos parametrizar el plan de preservación" | Preservation Planning + responsabilidades (c)(d)(e) | Núcleo del estándar; hoy ausente |
| "Tipologías y formatos exigidos (PDF/A), carta de salvaguarda, versión" | Ingest (validación de admisión) + PDF/A + Representation Info | Estándar; hoy ausente |
| "PREMIS con sus 5 partes, no por defecto" | PREMIS v3 (5 entidades) | Estándar; hoy parcial (3/5, cableado) |
| "El monitoreo debe verse: formatos por vencer, migración, integridad" | Preservation Planning + Archival Storage (fixity) | Estándar; hoy parcial |
| "El usuario consulta el DIP, no el AIP (que queda oculto)" | Access + modelo de paquetes | Estándar; hoy parcial (heurístico) |
| "Difusión, acceso ciudadano, datos abiertos" | Access + política institucional | Estratégico; fuera del alcance técnico actual |
Metodología. Evaluación con evidencia física en el código (no nombres de archivo: contenido real). Repositorios:
datavault-backend(FastAPI),datavault-oais-server(watcher/preingestor) ynebula-vault(Angular). Severidad: 🔴 alta · 🟠 media · 🟡 baja. No se oculta nada; también se reconoce explícitamente lo bien hecho.
| Entidad OAIS | v1.0 (mar) | v2.0 (jun) | Comentario |
|---|---|---|---|
| Ingest | 85% | 80% | Sólido (resumable, gates, cuarentena), pero la validación de tipología/formato no existe |
| Archival Storage | 70% | 65% | AIP/DIP y fixity rolling OK; régimen de fixity inconsistente (ver H-01) |
| Data Management | 50% | 45% | Metadatos descriptivos boilerplate, no catalogación real |
| Administration | 40% | 40% | Sin consola de parámetros de preservación; gates solo por variables de entorno |
| Preservation Planning | 30% | 25% | Sin plan, sin normalización, sin migración por obsolescencia |
| Access | 60% | 60% | DIP existe pero su exposición es heurística por ruta |
H-01 🔴 Régimen de fixity inconsistente y débil para preservación.
Coexisten dos esquemas de integridad: el flujo SIP/AIP calcula SHA-256 (ingest_service.py:564,652; cloud_sync_daemon_aip.py:81), pero el flujo nuevo de expedientes valida con MD5/SHA1 (expediente_preingestor.py:75-76) y la re-verificación diaria recalcula con MD5 (daily_review.py:59). La propia v1.0 de este documento (§2.1) declara que MD5 no es criptográficamente seguro y que "para preservación a largo plazo solo se debe confiar en SHA-256". Riesgo: la integridad de largo plazo del expediente se ancla en un algoritmo deprecado. Acción: unificar fixity de preservación en SHA-256/512; MD5/SHA1 solo como verificación de transporte del productor.
H-02 🔴 PREMIS incompleto y cableado.
premis_builder.py genera solo 3 de 5 entidades (Object, Event, Agent); no hay Rights (Access) ni Intellectual Entity. Los agentes son constantes (AGENT_VAULT, AGENT_CLAMAV), el formato está fijo a "ISO 9660 image" (L118) y los eventos son los 4 de ingesta. No es parametrizable. Acción: PREMIS v3 completo y configurable por el plan de preservación.
H-03 🔴 Preservation Planning prácticamente inexistente.
No hay normalización a PDF/A, no hay identificación de formato (PRONOM/DROID), no hay detección de obsolescencia ni migración. Peor aún: el SIP escribe "migration_strategy": "Format migration when needed" (ingest_service.py:649) como metadato declarativo sin motor detrás — una promesa no implementada. Acción: construir la entidad Preservation Planning real (ver Parte IV).
H-04 🟠 Metadatos descriptivos boilerplate (no catalogación).
La metadata "descriptiva" es plantilla fija: description = f"Documento del proyecto {project_name}", rights="Confidencial", language="es" (ingest_service.py:620-627). No describe el contenido real → la entidad Data Management no cumple la responsabilidad de "independientemente comprensible". Acción: captura/derivación real de Dublin Core (idealmente asistida por IA).
H-05 🟠 Sin identificadores persistentes (PDI/Reference).
No existe URN/Handle/ARK/DOI; se usan IDs internos y rutas. Un cambio de almacenamiento rompe la referencia. Acción: esquema de identificador persistente.
H-06 🟠 Exposición del DIP heurística.
El "consultar por DIP" se resuelve por coincidencia de la cadena /DIP/ en rutas (repository.py), no por un servicio que genere el DIP bajo demanda. Acción: AccessService que produzca DIP a partir del AIP.
H-07 🟠 Parametrización dispersa y sin consola.
Lo configurable vive en variables de entorno (EXPEDIENTE_INVENTORY_STRICT, ANTIVIRUS_RESCAN_REQUIRED, FIXITY_SLA_DAYS/BATCH/BYTE_BUDGET) — sin UI ni gobierno por tenant/tipología. Acción: módulo de parametrización (Parte IV).
H-08 🟡 Multitenant lógico y auditoría no inmutable.
Aislamiento por tenant_key en BD compartida (no físico) y auditoría mutable (no WORM/append-only). Aceptable hoy; relevante para ISO 16363 / valor probatorio.
os.rename + sentinela .ready) y 4 gates de admisión (formato, fixity de transporte, antivirus, inventario) con cuarentena trazable.daily_review.py).document_retention.py. Es el patrón a replicar para el plan de preservación.PreservationService): OPTIMAL(verde)/ATTENTION(amarillo)/CRITICAL(rojo)/UNVERIFIED(gris), por existencia + checksum + completitud de metadata + retención + antigüedad de verificación.legal_hold).Cómo se construiría cada pieza según el estándar, con la visión de parametrizar todo el contexto (por archivo, por carga, por tenant) y apalancar IA como diferenciador.
Un motor de reglas parametrizable que el archivista configura desde consola y que gobierna a los microservicios de validación (no "por debajo", como observó Edgar). Cada Plan de Preservación es una entidad versionada por tenant.
Dimensiones parametrizables (todo el contexto):
| Dimensión | Ejemplos de parámetro |
|---|---|
| Por tipología documental | "Responsabilidad fiscal" exige PDF/A + carta de salvaguarda + versión; "hoja laboral" exige tipologías X en formatos Y |
| Por formato/archivo | Texto→PDF/A; imagen→TIFF/JPEG2000; video→contenedor/codec de preservación; audio→WAV/FLAC |
| Por carga/lote | Reglas de admisión por proyecto, por origen, por volumen; modo estricto vs. advertencia |
| Por tenant/entidad | Cada entidad escribe su propio plan según su tabla de retención documental y normativa |
| Por evento PREMIS | Qué eventos se registran, qué agentes, qué política de derechos/acceso |
El plan se materializa como configuración, no como código: el motor lee el plan y parametriza dinámicamente los gates de Ingest, el generador PREMIS, las reglas de normalización y la agenda de fixity.
Completar las 5 entidades y hacerlas configurables por plan: Object (formato real vía PRONOM, tamaño, fixity SHA-256), Event (ingesta, fixity, virus, normalización, migración), Agent (persona/productor/software con versiones), Rights (público/reservado, permisos, vigencia) e Intellectual Entity (descripción lógica del proceso para búsqueda). Resuelve H-02 y la observación del cliente sobre metadatos.
AccessService que genera el DIP bajo demanda desde el AIP, manteniendo el AIP oculto (H-06); el usuario accede como a una biblioteca/colección.La IA se inserta dentro del Plan de Preservación como asistencia parametrizable, no como caja negra:
La IA propone; el plan parametrizado y el archivista deciden. Trazabilidad PREMIS de toda acción automática.
| Componente PDI | Estado real | Acción |
|---|---|---|
| Provenance | 🟠 Parcial (PREMIS 3/5) | Completar PREMIS (4.2) |
| Context | 🟠 Parcial | Vinculación SIP↔AIP↔DIP |
| Reference | 🔴 Ausente | Identificadores persistentes (4.4) |
| Fixity | 🟠 Inconsistente | Unificar SHA-256 (H-01) |
| Access Rights | 🔴 Ausente en PREMIS | Entidad Rights (4.2) |
| Fase | Entregable | Cierra |
|---|---|---|
| F1 | Unificar fixity SHA-256 + completar PREMIS (Rights + Intellectual Entity) | H-01, H-02 |
| F2 | Módulo de Parametrización del Plan de Preservación (consola + motor de reglas que gobierna los microservicios) | H-07, Preservation Planning |
| F3 | Identificación (PRONOM) + normalización PDF/A (veraPDF) + monitoreo de obsolescencia | H-03 (parte) |
| F4 | Migración de formatos con cadena de integridad + monitoreo visible al usuario | H-03 |
| F5 | Identificadores persistentes + DIP por servicio + auditoría inmutable | H-05, H-06, H-08 |
| F6 | IA: clasificación de tipologías, extracción de metadatos, validación PDF/A, sugerencia de migración | H-04 + diferencial |
F1 y F5 son correcciones de cumplimiento (deuda de integridad y de PDI). F2–F4 y F6 son la construcción del estándar pleno que se planeó desde marzo (§ v1.0 7.3) y nunca se aprobó.
| Métrica | Objetivo | Frecuencia |
|---|---|---|
| Tasa de integridad (AIP válidos / total, SHA-256) | > 99.99% | Diario |
| Cobertura de verificación (último ciclo SLA) | > 95% | Mensual |
| Objetos en formato obsoleto (pendientes de migrar) | tendencia ↓ | Mensual |
| Conformidad PDF/A de lo normalizado (veraPDF) | 100% | Por lote |
| Completitud PREMIS (5/5 entidades) | 100% | Por AIP |
| Archivos críticos (RED) | 0 | Diario |
| Hallazgo | Evidencia |
|---|---|
| Fixity dual/MD5 | datavault-oais-server/.../ingest_service.py:564,652; expediente_preingestor.py:75-76; daily_review.py:59 |
| PREMIS 3/5 cableado | datavault-oais-server/.../services/premis_builder.py (agentes constantes; formato fijo L118) |
| migration_strategy declarativa | ingest_service.py:649 |
| Metadata descriptiva boilerplate | ingest_service.py:620-627 |
| Gates por ENV | expediente_preingestor.py:31,47; daily_review.py:41-44 |
| Retención parametrizable (patrón a replicar) | datavault-backend/app/models/document_retention.py |
| Sin PDF/A, sin PRONOM, sin URN/Handle | Búsqueda negativa en datavault-oais-server y datavault-backend (jun-2026) |
nebula-vault/docsDepartamento de Arquitectura — Centrica Soluciones