# Aptlantis Archive Multi-Hash Standard

Defines archive integrity records, preservation hashes, and validation.

Catalog: active · v1.0.3 · reviewed 2026-09-23

Source maturity: candidate · Explanation reviewed 2026-10-01

Applies to: Long-term archives, collections, datasets, evidence bundles and release snapshots requiring recoverable integrity records.

[Public page](https://aptlantis.net/city-hall/aamhs)

<a id="purpose-and-applicability"></a>

## Purpose 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.

<a id="how-it-works"></a>

## 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.

<a id="in-practice"></a>

## 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.

### Archive record relationship

illustrative · teaching example, not a verification result

Sanitized teaching relationship; no copied placeholder hashes or retired source paths.

Source: `AAMHS/examples/Example-Archive-Integrity-Record.md`

```text
Archive 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.
```

[Inspect Archive record relationship](/city-hall/standards/aamhs/example-1.txt)

### Signature evidence, separately

illustrative · teaching example, not a verification result

Separate signature-policy specimen; no cryptographic authenticity claim.

Source: `AAMHS/Validation-Checklist.md`

```text
Detached 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.
```

[Inspect Signature evidence, separately](/city-hall/standards/aamhs/example-2.txt)

<a id="adopt-one-part"></a>

## Adopt one part

Start with a bounded surface or record. Complete the relevant adopter checks before extending the claim.

1. Choose one preservation bundle and define its exact file coverage and hash policy.

2. Generate a real manifest and integrity record; retain validation commands and missing-file limits.

3. Document signature policy and verify signatures separately when used; test the recovery procedure against retained bytes.

<a id="sources-and-limits"></a>

## 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.toml`
- `AAMHS/Adoption-Guide.md`
- `AAMHS/Validation-Checklist.md`
- `AAMHS/Aptlantis Archive Multi-Hash Standard.md`
- `AAMHS/examples/Example-Archive-Integrity-Record.md`
- `AAMHS/examples/Example-Hash-Manifest.toml`

[Reviewed manifest facts](/city-hall/components/aamhs.md)

## Related responsibilities

- [APTlantis Release Hashing Standard](/city-hall/arhs): Defines the hash manifest for a published release artifact.
- [Dataset Development Standard](/city-hall/dds): Owns dataset provenance and license constraints.
- [Desktop Application Release Standard](/city-hall/drs): Owns the desktop release whose evidence bundle may be archived.