Make the archive recoverable.

What the manifest actually verifies.

1. Inventory. Record each generated public file with its relative path and byte length, from pages and scripts to licensed assets, archive copies and data exports.
2. Digest. Calculate a SHA-256 checksum for each file after the build is complete. The manifest excludes only itself to avoid a self-referential checksum.
3. Compare. After an export, transfer or restoration, reject missing, additional and altered files. Keep a trusted manifest and independent copies; a hostile actor able to rewrite both file and checksum is not detected by fixity alone.
4. Restore. A tested ZIP export recreates the site in an isolated directory and checks the entire extracted collection against the manifest. The export is created by a local tool, not downloaded automatically from this public page.

Method informed by the Library of Congress data integrity management guidance. A checksum proves file equivalence to a baseline, not institutional custody or external-source accessibility.

Publication is a separate decision.

Indexing enabled by release configuration. Canonical URLs and sitemap checks remain separate from editorial approval.

• Automated site checks: navigation, source links, Bible and atlas fixtures, data integrity, and two URL-path builds. Continuous integration checks can fail a release but cannot certify every historical claim.
• Editorial governance: review roles, corrections and the public revision record are documented. Independent specialist sign-offs are not yet recorded.
• Language and accessibility: Syriac font shaping, keyboard-only use, screen-reader checks, reduced-motion paths and representative desktop/mobile browser testing still require real-device review.
• External references and media: provider availability, licensing and changing live URLs require periodic human review; the reference library and public heritage catalogue do not licence third-party audio or images.
• Offsite backups: multiple independently stored and periodically restored copies are a future operational task. GitHub source history and a website ZIP alone are not a documented multi-location backup programme.

Accessibility review is organised against the W3C WCAG 2.2 explanatory guidance. The archive makes no full WCAG conformance claim.

Restore without inventing a new source.

Use the maintained Python generator, offline validator and archive export script. The repository preservation and recovery runbook describes how to rebuild, verify, export, restore, retain independent copies and resolve discrepancies. The generated public data and preserved references are intentionally readable without a private database.

python generate.py
python scripts/validate.py
python scripts/export_archive.py --output ../assyria-site-backup.zip

Keep a separate copy of the matching source commit, the ZIP, its manifest and rights documentation. If a checksum does not match, investigate and restore a trusted copy rather than silently replacing the expected digest.

Preservation is more than files.

Scripture remains the starting primary text for biblical accounts. Archaeological records, textual scholarship, local history and community testimony require correctly labelled source roles. Permissions, independent review, correction decisions and the treatment of living people must be revisited by qualified humans. A preserved copy keeps a record available; it cannot resolve disagreement about the historical account.

See Next Chapters for the outstanding release gates, Evidence Register for editorial reference coverage and Community Heritage for narrator consent and rights guidance.