Reglas de inventario SIP↔AIP de Docuten eArchiving v1

Docuten eArchiving SIP↔AIP Inventory Rules v1

1. Propósito / Purpose

Este documento define la lista blanca cerrada y versionada de reglas con las que el paso 7 de la ingesta compara el inventario del SIP recibido con el del AIP construido en el paso 6. Un peritaje que disponga del SIP, del AIP y de este documento puede reproducir la comparación y llegar al mismo resultado que cita el evento sellado. Es el documento que la URI de la tabla anterior identifica.

La URI es un identificador, no una URL que deba resolverse. No se dereferencia en tiempo de ingesta, sellado ni verificación.

This document defines the closed, versioned allow-list of rules that ingest step 7 uses to compare the inventory of the received SIP with the inventory of the AIP built by step 6. An expert witness holding the SIP, the AIP and this document can reproduce the comparison and reach the result cited by the sealed event. The URI is an identifier, not a URL to be dereferenced.

2. Alcance / Scope

Qué se compara. La comparación es bidireccional (D-07): se aplican las reglas al lado SIP para derivar el AIP esperado y se compara con el AIP real. Por cada objeto se compara:

• la ruta, relativa a la raíz del paquete (sin el prefijo {aipId}/);
• el SHA-256 de sus bytes, cuando la regla que lo gobierna compara huella;
• las secciones METS presentes (dmdSec, amdSec, fileSec, structMap), como multiconjunto de tokens (INV-R09).

Una discrepancia es un objeto que falta en el AIP, un objeto que sobra en el AIP, una huella distinta o una sección METS ausente o de más. Lo que ninguna regla explica es un bug de transformación del servicio: el paso 7 termina en FAILED con el código INVENTORY_DISCREPANCY (D-10).

Qué no se compara. Los bytes de los METS (METS.xml y representations/<r>/METS.xml): el paso 6 los reconstruye y sus bytes difieren siempre de los del SIP. De los METS solo se comparan sus secciones (INV-R09).

Compared: package-relative path, SHA-256 when the governing rule compares digests, and the METS sections present. Not compared: the METS bytes, which step 6 rebuilds.

3. Tabla de reglas / Rule table

<r> es el id de representación y <f> un nombre de fichero. Huella indica si la regla exige el mismo SHA-256 en origen y destino. Multiplicidad es el número de copias que la regla añade en el AIP por cada objeto de origen que gobierna.

Notas por regla / Notes per rule.

• INV-R01. La huella del lado SIP es la que el paso 3 verificó y persistió en sip_files.
• INV-R03 e INV-R04 (D-08 caso 1, 06.3 D-04). Renombrado fijo: el paso 6 guarda la metadata de preservación y la «other» del productor bajo producer/, separada de la del servicio. Esta regla cierra DI-06.3-09 en el inventario.
• INV-R05 (D-08 caso 2). Regla transitoria, ver §5.
• INV-R06 (D-08 caso 3). Medido en 06.4-01 (representationMetadata_measured_arrivesByteForByte): los cinco tipos de metadata de representación llegan al AIP byte a byte, así que la regla compara huella en los cinco. La metadata «other» de representación no entra: el paso 2 la rechaza (§7).
• INV-R07 (D-08 caso 4). Añadidos propios del AIP. Los schemas/<f> del servicio son los cuatro del estándar (DILCISExtensionMETS.xsd, DILCISExtensionSIPMETS.xsd, mets1_12.xsd, xlink.xsd), package-profile-v1.xsd y los cinco recursos Dublin Core (oai_dc.xsd, simpledc20021212.xsd, xml.xsd, XMLSchema.dtd, datatypes.dtd). Los METS no comparan huella porque se reconstruyen.
• INV-R08 (D-09a punto 5). Los cuatro XSD del estándar que commons-ip2 incluye siempre en el SIP no se propagan: el AIP lleva los suyos (INV-R07). Medido en 06.4-01: son idénticos byte a byte a los recursos de classpath del servicio. Cualquier otro XSD en schemas/ del SIP lo rechaza el paso 2 con SIP_CONTENT_NOT_ARCHIVABLE y nunca llega al inventario.
• INV-R09 (D-08 caso 5). Secciones METS, ver §6.

4. Reglas de multiplicidad / Multiplicity rules

• La multiplicidad cuenta las copias que cada regla añade en el AIP por objeto de origen. Las multiplicidades de las reglas que gobiernan un mismo origen se suman.
• Un fichero metadata/other/<f> de la raíz del SIP produce 2 copias en el AIP: una por INV-R04 (metadata/other/producer/<f>) y otra por INV-R05 (metadata/other/<f>). Las dos deben tener la huella del original.
• Un objeto que aparece en el AIP más veces de las que suman sus reglas es una discrepancia (objeto que sobra). Un objeto copiado dos veces sin reglas que sumen 2 es una discrepancia.
• Multiplicidad 0 (INV-R08) significa que el origen es legítimo pero no se propaga: su ausencia en el AIP no es discrepancia.

Multiplicities of the rules governing the same source add up: a root metadata/other/<f> yields 2 AIP copies (INV-R04 + INV-R05). Any object present more times than its rules allow is a discrepancy.

5. Regla transitoria INV-R05 / Transitional rule INV-R05

Por qué existe. El bucle descriptivo del paso 6 (D-24 de 05.1.1) declara el «other» de la raíz también como dmdSec MDTYPE=OTHER con href=metadata/descriptive/../other/<f>, y commons-ip2 materializa esa referencia como una segunda copia en metadata/other/<f> (DI-06.3-03). Es un comportamiento medido del servicio, no un error del productor, así que el inventario lo declara para no fallar todo AIP con «other».

Lo que NO hace. La regla declara la copia esperada; NO legitima el href con .. de esa referencia. La amenaza de esa referencia sigue enrutada a /gsd-secure-phase.

Condición de retirada. Cuando se corrija en origen el bucle descriptivo y desaparezca el href con .., la copia doble deja de existir y INV-R05 se retira. Retirarla es una versión nueva de este documento con URI nueva (§10); la v1 no se edita.

INV-R05 declares the measured second copy of a root other file caused by the descriptive loop; it does NOT legitimise the .. href. It is withdrawn in a new version once the loop is fixed at source.

6. Traducción de secciones METS de INV-R09 / METS section translation (INV-R09)

Las secciones se extraen como tokens del METS.xml raíz y de cada representations/<r>/METS.xml, en el SIP y en el AIP. Traducción medida (06.4-RESEARCH, «Secciones METS presentes»):

Secciones de servicio con mdRef todavía sin fichero. En el paso 7 el METS del AIP ya declara los digiprovMD de servicio, pero sus ficheros los añade el paso 10 (medido en 06.4-01, A3: el METS del paso 6 declara dss-validation-report.xml y el ZIP no lo contiene). Son secciones de servicio de esta regla: ni objeto que falta ni sección de más.

Precisiones de la tokenización (aprobadas en el checkpoint de 06.4-09).

• (a) Los digiprovMD del servicio se tokenizan por ID, no por MDTYPE. Las cuatro referencias de servicio que escribe el paso 6 llevan un ID fijo (digiprov-1 a digiprov-4) y producen el token digiprovMD[ID=digiprov-<n>]. No se tokenizan por MDTYPE porque ese atributo no las distingue de las del productor: medido, digiprov-4 (aip-timestamp.tst) es MDTYPE=OTHER. El resto de hijos de amdSec se tokeniza por MDTYPE.
• (b) La div envolvente del structMap no se tokeniza. El paso 6 cambia su OBJID, así que solo se tokenizan sus hijas, las divisiones de contenido de primer nivel (structMap[LABEL=<l>]/div[LABEL=<d>]).

Limitación conocida, aceptada. Un digiprovMD del productor cuyo ID tenga la forma digiprov-<n> se tokeniza como si fuera de servicio y produce un falso positivo que falla cerrado con INVENTORY_DISCREPANCY: el paso 7 termina en FAILED y no se emite sello alguno. Es un fallo seguro —nunca deja pasar una discrepancia real— y se acepta en la v1.

Precisions: service digiprovMD sections are tokenised by ID (digiprov-1..4), not by MDTYPE (digiprov-4 is MDTYPE=OTHER); the wrapping structMap div is not tokenised (step 6 changes its OBJID), only its children. Known, accepted limitation: a producer digiprovMD with an ID of the form digiprov-<n> yields a false positive that fails closed with INVENTORY_DISCREPANCY.

7. Lo que el paso 2 rechaza antes / What step 2 rejects first

El paso 2 rechaza con SIP_CONTENT_NOT_ARCHIVABLE (REJECTED, D-09a) el contenido que el servicio no archiva. Ese contenido nunca llega al inventario, y por eso no tiene regla:

1. secciones raíz technical/source/rights con MDTYPE=OTHER y las raíz PREMIS:OBJECT/PREMIS:RIGHTS;
2. metadata «other» de representación (representations/<r>/metadata/other/**);
3. documentation/ de paquete y documentation/ de representación;
4. schemas/ de representación;
5. en schemas/ de la raíz, todo XSD que no sea uno de los 4 del estándar (por nombre y huella, INV-R08);
6. rutas hostiles y metadata «other» por encima de los límites de tamaño (DI-06.3-04).

8. Relación con premis.xml / Relation to premis.xml

Los ficheros de metadata/preservation/producer/ y metadata/other/producer/ no se inventarían como objetos file de premis.xml (D-12). Ya tienen SHA-256 nativo en el METS y entran en el leaf set del sello #1 (06.3 D-04), y los cubre este inventario (INV-R03, INV-R04). premis.xml no cambia por este motivo. La regla vive en el inventario, no en el PREMIS.

Files under producer/ are not inventoried as PREMIS file objects; they carry native SHA-256 in the METS, are leaves of seal #1 and are covered by INV-R03/INV-R04. premis.xml is unchanged.

9. Partida del inventario / Inventory baseline

El inventario parte de lo declarado en el METS del SIP (D-17). Los ficheros del ZIP que el METS no declara no se inventarían: commons-ip2 los ignora y no llegan al AIP, así que contarlos daría un falso «bug nuestro». Vigilar ficheros no declarados del ZIP es una regla de seguridad del paso 2, fuera de esta versión.

The inventory starts from what the SIP METS declares. Undeclared ZIP entries are not inventoried; watching for them is a step-2 security rule outside this version.

10. Versionado / Versioning

• Vigente desde la fase 06.4 para todo AIP nuevo: la cita el evento sellado VALIDATION del paso 7, así que la v1 no se edita; un cambio es la v2 con URI nueva.
• Cualquier cambio —una regla nueva, una multiplicidad distinta, la retirada de INV-R05— es una versión nueva con URI nueva (.../sip-aip-inventory-rules/v2) y documento nuevo. La lista no se amplía en tiempo de ejecución ni por configuración.
• SipAipInventoryRulesDocTest comprueba que este documento y SipAipInventoryRules coinciden en IDs, multiplicidad, transitoriedad, huella, versión y URI, y fija la forma de las nueve reglas con un snapshot literal (RULES_V1_SNAPSHOT) que tampoco se edita.
• Vocabulario. El término PREMIS del evento es validation del vocabulario eventType de la Library of Congress (https://id.loc.gov/vocabulary/preservation/eventType/val.html, código val). Lo comprobó manualmente el responsable el 2026-10-28 en https://id.loc.gov/vocabulary/preservation/eventType.html.

In force since phase 06.4 for every new AIP: v1 is never edited; any change is v2 with a new URI.