General rules for all information packages conforming to this profile: (1) All file paths are relative to the package root folder. (2) All file fixity checksums MUST use SHA-256 (CHECKSUMTYPE="SHA-256" in METS fileSec). SHA-512 is permitted as a higher-security alternative. SHA-384, MD5, and SHA-1 are PROHIBITED for any fixity use — this is an irrevocable rule that applies the Docuten eArchiving cryptographic policy published at https://docs.docuten.com/earchiving/crypto-policy/v1, the single source of that policy and of its scope (every use with evidentiary value), which this profile does not duplicate. (3) This profile is identified by the URI https://docs.docuten.com/earchiving/mets-profile/v1 — a stable identifier. PRE-07 publishes it at that address and DevOps confirms that it resolves (the status of each URI is recorded in docs/governance/published-uris.md); no consumer may depend on it resolving in order to validate a package. It is NOT the value of the PROFILE attribute of the METS root element, which MUST be the official E-ARK AIP profile https://earkaip.dilcis.eu/profile/E-ARK-AIP-v2-2-0.xml (D-06 of phase 05.1.1); each AIP cites this profile's URI in the metsProfile element of documentation/package-profile.xml. (4) Metadata classification (EVID-10, CEN/TS 18170 REQ-9.3-02): the metadata of every AIP is classified into the standard's three families only (descriptive, administrative and technical metadata), with the family of each AIP file and its METS section listed in section 3.3 of the readable profile (docs/governance/mets-profile.md); this classification adds no requirement and does not close the administrative gap that depends on the deposit agreement (B-04).
The OAIS package type MUST be declared in the metsHdr element using the csip:OAISPACKAGETYPE attribute. Valid values for this profile are SIP (Submission Information Package) and AIP (Archival Information Package). DIP (Dissemination Information Package) is deferred to a future phase.
The /metadata/ folder MUST be present in all information packages (CSIP, SIP, AIP). This requirement elevates CSIPSTR5 from SHOULD to MUST by internal design decision. Justification: operational simplification and deterministic validation. The absence of /metadata/ prevents unambiguous location of metadata by automated tools, introducing variability incompatible with QTSP audit requirements. Evidence: PackageGenerator.java always creates the metadata/ directory unconditionally for all package types.
The /metadata/preservation/ subfolder containing PREMIS 3.0 metadata MUST be present in all AIP packages. This requirement elevates CSIPSTR6 from MAY to MUST by internal design decision. Justification: eIDAS 2.0 Art. 45j (Reg. (EU) 2024/1183) traceability and chain of custody requirements. PREMIS events in /metadata/preservation/ are the only verifiable source of preservation events (ingestion, integrity calculation, access) required by qualified electronic archiving regulations. Evidence: PackageGenerator.java writes PREMIS.xml via PremisLibrary.java per representation in every AIP creation path.
The /representations/ folder with at least one representation MUST be present in all AIP packages. This requirement elevates CSIPSTR9 from SHOULD to MUST by internal design decision. Justification: an AIP without at least one representation cannot satisfy preservation requirements, as the representation is the content being preserved. An empty preservation package has no archival or legal value. Evidence: AipDescriptor.Builder.build() in PackageGenerator.java validates that the representations list is not empty before permitting package creation; throws an exception if no representations are provided.
The /schemas/ folder MUST be present in all AIP packages and MUST carry the TRANSITIVE CLOSURE of the XSDs required to validate the package's XML files without network access: not merely the schemas referenced by the METS.xml's xsi:schemaLocation, but also those they import via xs:import, recursively, until the chain closes. This requirement elevates CSIPSTR15 from SHOULD to MUST by internal design decision. Justification: the dc.xml this product emits carries no xsi:schemaLocation at all, so under the previous criterion ("the schemas the METS references") the only XML in the package holding client metadata would have qualified for no schema whatsoever. The transitive-closure criterion resolves that and makes the package self-sufficient for an offline validator, which is what a preservation package has to be. Current content (7 files): DILCISExtensionMETS.xsd, DILCISExtensionSIPMETS.xsd, mets1_12.xsd, xlink.xsd, plus the Dublin Core chain oai_dc.xsd, simpledc20021212.xsd and xml.xsd, each with its real SHA-256 fixity declared in the METS. Note for auditors: the bundled xml.xsd keeps its official DOCTYPE intact, so an external offline validator running with load-external-dtd enabled must disable that option or supply XMLSchema.dtd itself; DTDs are deliberately left OUT of the package. Evidence: DublinCoreSchemaValidator.java (earchiving-core) plus InformationPackageCreatedTaskletTest#aipBundlesTheThreeDublinCoreSchemasVerbatimWithRealFixity, which opens the built AIP and compares each schemas/ entry byte for byte.
All file fixity checksums MUST use SHA-256 algorithm (CHECKSUM attribute in METS fileSec, with CHECKSUMTYPE="SHA-256"). SHA-512 is permitted as an alternative. SHA-384, MD5, and SHA-1 are PROHIBITED for any fixity use. This restriction is irrevocable and applies globally to CSIP, SIP, and AIP package types. It applies to METS fixity the Docuten eArchiving cryptographic policy published at https://docs.docuten.com/earchiving/crypto-policy/v1 (docs/governance/crypto-policy-v1.md), the single source of that policy: it sets the policy scope (every use with evidentiary value, not only fixity) and holds the comparison table against ACM-ECCG, the reference designated by the annex of Implementing Regulation (EU) 2025/2532. This profile does not duplicate the policy text. Evidence: PackageGenerator.java uses MessageDigest.getInstance("SHA-256") as the sole checksum computation method; no MD5, SHA-1, or SHA-384 instantiation exists in the packaging engine.