The Aptlantis Ecosystem

This page describes the Aptlantis product itself — the live archival and application platform that AADR (and its sibling standards AAMHS and SEMS) were extracted from. The material here is preserved product context, not standard specification text; for the governing standard, see AADR Overview and, for the archival hashing side, AAMHS Overview.

:::note Older source copies AptlantisEcosystem/Standards/ contains earlier, pre-governance-wrapper copies of the AADR, AAMHS, and SEMS standards (AADR v1.0.md, AAMHS v1.0.md, SEMS v1.0.md), plus the whitepaper this page is drawn from. Those copies are historical source material only — treat docs/aadr/overview.md and docs/aamhs/overview.md as canonical, not the copies preserved there. SEMS itself is tracked as its own standard elsewhere in City Hall (position 23). :::

What Aptlantis Is

Aptlantis is a unified architecture for post-quantum archival and data-driven applications. It addresses a basic tension in long-lived digital systems: the need for archival data to stay permanent and verifiable while the applications that present that data need to keep evolving. Aptlantis resolves this by splitting the two concerns cleanly:

AAMHS (the Aptlantis Archive Multi-Hash Standard) guarantees long-term, verifiable integrity for archived artifacts.
AADR (the Application-as-Data Runtime) treats the application itself — UI, layout, behavior — as versioned data, so the site can evolve without rebuilds.

Archival integrity is treated as the non-negotiable foundation; application logic is treated as mutable, versioned data on top of it.

The Archival Foundation (AAMHS)

AAMHS mandates a diverse suite of hash algorithms and a dual-signature model so that no single cryptographic break can compromise an archive:

Algorithm Family	Specific Algorithms	Strategic Role
SHA-2 / SHA-3	SHA256, SHA512, SHA3-256, SHA3-512	Dual-family cryptographic resilience against a break in either family.
BLAKE	BLAKE3	Modern speed and strong integrity for high-performance verification.
Keccak Variant	K12	Post-quantum-friendly hashing for the transition as quantum computing matures.
Utility / Legacy	xxHash64, CRC32	Fast non-cryptographic checks and legacy tooling compatibility.

Authenticity is guaranteed by a dual-signature model: a mandatory PGP signature for backward compatibility with existing tooling, plus a recommended post-quantum signature (SPHINCS+ or Dilithium) as a forward-looking guarantee once classical cryptography is no longer trusted.

An AAMHS-compliant snapshot bundles the artifact itself (e.g. a .tar.gz or .zip), a snapshot-hashes.txt file with the canonical hash set, and a snapshot-hashes.txt.asc PGP signature — all following a deterministic naming convention for stable, reproducible referencing.

The Runtime (AADR)

AADR treats the entire application state as a collection of versioned documents in a database rather than static code. The web application becomes a generic loader and interpreter for that data. Its design goals:

Application as Data — UI, layout, and behavioral logic live as documents (MongoDB), decoupling application state from runtime code.
Zero-Rebuild Live Editing — changes to defining documents take effect immediately, with no compile or deploy cycle.
Schema-Driven, but Evolvable — schemas give structural integrity while document versioning allows graceful evolution without disruptive migrations.
LLM- and Automation-Friendly — structured JSON state gives AI agents and scripts a clean interface to inspect, propose, and generate content.
Archival and Reproducibility — the entire application state can be exported as a snapshot and archived under AAMHS, allowing perfect recreation of the site from any point in its history.

AADR's architecture has four logical layers: a Storage Layer (MongoDB, canonical source of truth), a Runtime/Loader Layer (Node.js/Next.js, dynamically renders pages from the database), a Delivery Layer (Caddy and Cloudflare, public-facing), and a Control Plane (MongoDB Compass, Jupyter Notebooks — out-of-band bulk management decoupled from the request/response path).

This adds up to a deployment philosophy: deploy code rarely, ship data constantly.

Where AAMHS and AADR Meet

AADR's runtime natively consumes AAMHS data: artifact_entry documents in MongoDB carry an AAMHS-conformant hash set, and the UI exposes the full suite of hashes and signatures directly to end-users — integrity becomes a visible, interactive feature rather than a background process. Because the whole application state is structured data, the entire system (not just the archived files) can be snapshotted and preserved under AAMHS, giving total, reproducible state-in-time recovery.

Automation and AI

Because all system state is structured JSON, Aptlantis defines a clear "Agent Contract" for LLMs and automation: agents treat schema_definition documents as the canonical source of truth for data shapes, and prefer creating draft versions of UI or content documents for human review rather than writing directly to production. Bulk operations (ingesting datasets, scripted schema migrations, large-scale reconfiguration) run through the Control Plane as repeatable scripts, with human approval as the final gate.

SEMS (SVG Embedded Semantic Metadata) is a related case study in this philosophy: it embeds machine-readable metadata directly inside SVG assets (in the <metadata> tag) so that an asset's context and purpose survive mirroring, scraping, and archival without relying on a sidecar file that can get lost.

Slide Decks

Two slide decks from the Aptlantis Ecosystem material go deeper on the architecture and the AI-facing side of the platform:

Video Walkthrough

A recorded walkthrough of the Application-as-Data runtime is preserved from the source material: ApplicationAsData.mp4. It's a large screen-capture video (~36 MB) not practical to embed inline in a documentation page — it's copied to the site's static files and linked directly:

Download / view ApplicationAsData.mp4