Aptlantis Archive Multi-Hash Standard
Defines archive integrity records, preservation hashes, and validation.
Applies to: Long-term archives, collections, datasets, evidence bundles and release snapshots requiring recoverable integrity records.
Explanation reviewed 2026-10-01. Catalog identity and source review have separate dates.
Read public MarkdownPurpose and applicability
A preserved collection needs more than a single release checksum. AAMHS connects files, a declared hash suite, an integrity record and a future revalidation procedure.
Long-term archives, collections, datasets, evidence bundles and release snapshots requiring recoverable integrity records.
How it works
Declare archive identity and coverage, file paths/sizes and the selected hash suite. Record generation tools/date and validation procedure. When signatures are used, identify signature files, tools, key references and independent verification results.
Outputs are the hash manifest, archive integrity record, optional detached signature evidence and preservation/recovery notes. Missing files and validation limits belong in the record, not behind a success badge.
In practice
The two specimens separate hash integrity from signature evidence. The canonical minimal manifest declares SHA256 only and no signatures; that example does not demonstrate a completed multi-hash archive or signed collection.
Sanitized teaching relationship; no copied placeholder hashes or retired source paths.
Source: AAMHS/examples/Example-Archive-Integrity-Record.mdArchive integrity record
coverage → approved bundle file list
manifest → hashes/bundle.hashes.toml
hash policy → declared algorithms and encodings
validation → recompute each covered file; compare manifest
gaps → missing bytes or unsupported algorithms remain explicit
recovery → retained originals + documented restore procedure
Manifest file entry: relative path + measured size + actual digests.
Current specimen: illustrative; no byte verification.Separate signature-policy specimen; no cryptographic authenticity claim.
Source: AAMHS/Validation-Checklist.mdDetached signatures used: no (illustrative policy).
Signature file/key reference: not applicable.
Signature verification: not performed.
Hash verification: not performed.
If required by context: record tool, signature file, signing identity, date and verification procedure.
Recovery limit: a digest mismatch detects change; it cannot recreate missing bytes.Adopt one part
Start with a bounded surface or record. Complete the relevant adopter checks before extending the claim.
- Choose one preservation bundle and define its exact file coverage and hash policy.
- Generate a real manifest and integrity record; retain validation commands and missing-file limits.
- Document signature policy and verify signatures separately when used; test the recovery procedure against retained bytes.
Sources and limits
No archive or signature was verified here. The example’s placeholder integrity values are not published as real hashes. Detached archive signatures do not replace Store/Authenticode/package provenance; public releases still use ARHS separately.
These are reviewed public explanations, not the normative specifications. Suite references are relative to the canonical collection; site/ references identify committed website sources and webserver/ references identify serving configuration. Illustrative examples demonstrate record shape; they do not establish compliance. Suite checks and adopter validation are separate.
AAMHS/AAMHS.manifest.tomlAAMHS/Adoption-Guide.mdAAMHS/Validation-Checklist.mdAAMHS/Aptlantis Archive Multi-Hash Standard.mdAAMHS/examples/Example-Archive-Integrity-Record.mdAAMHS/examples/Example-Hash-Manifest.toml