Technical Architecture · Draft 1.0 · Last updated August 2026
Cryptographic Authenticity Infrastructure for Digital Archival Materials
GAMI is an open, non-proprietary infrastructure that enables archives, memorial institutions, and libraries to create long-term, publicly verifiable proofs of existence, integrity, and institutional provenance for digital materials.
Core Guarantees
What a GAMI Proof Establishes
The system is built on a straightforward premise: a digital file's authenticity cannot be established by assertion alone, but it can be anchored cryptographically.
For each anchored file, a successfully verified GAMI Proof Record (GPR) establishes four things, each resting on independently verifiable cryptographic evidence.
Existence
This exact file demonstrably existed no later than the anchoring date, proven by a commitment in the Bitcoin blockchain that is verifiable by anyone.
Integrity
The file has not been modified since anchoring. Any change, even a single bit, produces a different fingerprint and breaks the proof.
Institutional attribution
A named institution signed this proof with a private key only they hold, verifiable against their published public key without any intermediary.
Metadata integrity
The metadata recorded at anchoring time has not been altered and is covered by the institutional signature. Sensitive fields may be kept private; only their hash is committed to the record.
The system does not store content, does not require trust in GAMI for proof validation, and does not alter existing archival practice. Original files remain exclusively under institutional control. Discovery via the public verifier and DID resolution fallback rely on GAMI infrastructure, but neither affects the validity of an existing proof.
I · System Architecture
Four Layers, One Self-Contained Proof
The architecture consists of four tightly integrated layers. Each contributes a property the others cannot provide alone. The hash proves file identity. The signature proves institutional responsibility. The timestamp proves temporal existence. The Proof Record bundles all three into a single verifiable document, independently auditable against open public infrastructure.
- 01
File Fingerprinting
SHA-256 hash computed inside institutional infrastructure.
- 02
GAMI Proof Record
Hash, metadata, and chain reference bundled and canonicalised.
- 03
Institutional Digital Signature
Ed25519 signature; institutional key identity published via DID:webvh (backwards-compatible with DID:web).
- 04
Distributed Timestamp Anchoring
Merkle aggregation submitted to Bitcoin via the OpenTimestamps protocol.
Every algorithm and format is an established open standard with published specifications and independent implementations. No proprietary technology at any point.
File Fingerprinting
For each file, a SHA-256 hash is computed locally, inside the institution's infrastructure. SHA-256 is a cryptographic hash function that takes input of arbitrary size and produces a fixed-length 256-bit output. The original file never leaves institutional custody.
$ gami hash oral_history_DM_2024_00451.mp4
SHA-256 fingerprint · 256 bits
3a7f91c2e8b4d6a0f1c3e5b7d9a2f4c6e8b0d2f4a6c8e0b2d4f6a8c0e2b4d6f8
A single-bit change in the input produces an entirely uncorrelated output. No partial overlap.
Original file
3a7f91c2e8b4d6a0f1c3e5b7d9a2f4c6…
One bit flipped
7c4e1a9f2b3d56e8a0b71c4f8d2e3a9b…
Properties
Determinism
The same file always produces the same hash.
Pre-image resistance
Reconstructing a file from its hash is computationally infeasible.
Collision resistance
Finding two distinct files with the same hash is computationally infeasible.
Quantum-resistant
Grover's algorithm reduces effective security to 128 bits, which remains secure by current standards.
SHA-256 is the same hash function used by OpenTimestamps, C2PA, Archivematica, and Preservica. For institutions running OAIS-conformant systems, hashes generated during ingestion can be reused directly, eliminating the rehashing phase entirely.
The GAMI Proof Record
Each file's hash, institutional signature, metadata, and timestamp proof are bundled into a single JSON document, the GAMI Proof Record (GPR). The GPR is the fundamental unit of evidence in the system: it carries the full proof in one portable file, independently auditable against the Bitcoin blockchain and the institution's published public key.
Format
Canonical JSON (RFC 8785 / JCS). The signature covers the canonical byte representation, so every field is protected without conforming to a fixed schema. The @context can lift a record into W3C Verifiable Credentials and other linked-data tooling; this is optional and not exercised by the core verification pipeline.
Metadata
Free-form. Institutions are not required to map their fields onto a fixed vocabulary; whatever they provide is carried verbatim, covered by the signature, and displayed as provided at verification. Sensitive fields can stay internal, committed to the record only by hash.
Footprint
Typically 1–3 KB. The GPR carries the complete proof independently of any database.
Versioning
The format is versioned; v1 is published as a JSON Schema at /schema/v1/gpr-schema.json, with the JSON-LD context at /schema/v1/context.jsonld. The canonical @context URI /schema/v1 resolves to it.
"@context": "https://authenticmemory.org/schema/v1",
"type": "gami-proof",
"schema": "v1",
"id": "sha256:c3ab8ff1...", // content-addressed: hash of the canonical GPR itself
"subject":
"hash": "sha256:1f4d66495e...",
"filesize": 734003187
,
"institution":
"name": "KZ-Gedenkstätte Flossenbürg",
"key_id": "did:web:gedenkstaette-flossenbuerg.de#key-1"
,
"metadata":
"public":
"collection": "AGFl",
"classificationCode": "AGFl/AV.22.0787",
"filename": "AGFl_AV.22.0787.mp4",
"dateSubmitted": "2026-06-23T10:14:00Z"
,
"private_hash": "sha256:99af2b...", // hash of sensitive metadata kept off-record
"private_hash_canonicalization": "JCS"
,
"parent": null, // reference to predecessor GPR for append-only updates
"signature": "ed25519:7f3a91...",
"timestamps": [
"method": "opentimestamps",
"calendar": "bitcoin",
"status": "confirmed",
"blockHeight": 953214,
"proof": "<base64-encoded OTS proof>"
,
// optional supplementary anchor for redundancy (planned)
"method": "opentimestamps",
"calendar": "<second calendar>",
"status": "pending",
"proof": "<base64-encoded OTS pending proof>"
]
Institutional Digital Signature
The hash alone identifies a file. It does not say who is vouching for it. The institutional signature adds that attribution and makes it independently verifiable. Each GPR is signed by the anchoring institution using Ed25519 (RFC 8032), an elliptic-curve scheme widely deployed in SSH, TLS 1.3, and the Signal protocol. Ed25519 produces 64-byte signatures and provides 128-bit classical security with mature implementations in every major language.
Signing process
- 01
The GPR is constructed with all fields populated except signature and timestamps.
- 02
The document is canonicalised (RFC 8785 / JCS) to produce a deterministic byte representation, ensuring the signature covers an unambiguous encoding.
- 03
The canonical bytes are signed directly with the institution's Ed25519 private key, with no pre-hashing. The key never leaves institutional infrastructure.
- 04
The resulting 64-byte signature is inserted into the GPR.
Verification reverses these steps: remove the signature and timestamps fields, canonicalise, and validate the signature over the canonical bytes against the institution's published public key. If the check passes, the signature was provably produced with that private key; as long as the key remains under the institution's sole control, only the institution could have produced it.
GAMI cannot sign
Only the institution's private key produces a valid signature. The key never leaves institutional infrastructure.
Non-repudiation
The OTS timestamp proves the signature existed while the published key history listed the key as valid. Disputing authorship afterwards requires a public key-compromise claim, and the hash-chained key history cannot be rewritten to backdate one.
Mature deployment
Ed25519 is the same scheme used by SSH, TLS 1.3, the Signal protocol, and the C2PA standard.
Key management — DID:webvh
Institutional identity is managed using W3C Decentralised Identifiers, resolved from the institution's own domain. GAMI uses DID:webvh ("DID:web + Verifiable History"), which extends plain DID:web with a self-certifying identifier and an append-only, hash-chained log of every version of the DID document: public keys, validity periods, rotations, revocations. Verifiers resolve the institution's DID against its well-known URL and validate signatures locally; GAMI is never on the trust path. Existing DID:web identities remain fully supported and can be upgraded in place.
Self-sovereign
The institution controls its own keys and identity. GAMI has no access to private keys at any point. No certificate authority, no GAMI-issued credential.
Verifiable key history
Every key rotation and revocation is an entry in a cryptographically chained log. A verifier checks the entire history, not just the current state: the key that signed a GPR can be validated against the log entry that was authoritative at signing time.
Self-certifying identifier
The identifier embeds a hash derived from the initial DID document. Whoever later controls the domain cannot forge a substitute identity or rewrite the log without breaking the chain.
Pre-rotation
Institutions can commit to future keys by hash before activating them, so even a compromise of the active signing key does not permit an unauthorised rotation. GPRs signed before a revocation remain valid; their temporal position is established independently by the OTS timestamp.
Domain-loss resilience
GAMI maintains an archived, timestamped copy of all partner DID logs. Because the log is self-certifying, anyone can recompute its hash chain; the archive only needs to be available, not trusted. The identifier itself survives a move to a new domain.
Backwards-compatible
DID:webvh publishes alongside a plain DID:web document on the same domain, so tooling that only understands DID:web keeps working while verifiers gain the stronger history guarantees.
Distributed Timestamp Anchoring
After signing, the complete GPR (minus the timestamp proof field) is hashed, and this hash is submitted to the OpenTimestamps protocol. OTS aggregates submitted hashes into a Merkle tree and embeds the tree's root hash in a Bitcoin transaction. Once confirmed in a block, that commitment is secured by Bitcoin's global proof-of-work network.
Thousands of GPR hashes per batch
Pairwise SHA-256 → intermediate nodes
Single Merkle root
root = a3f8d2c1e94b076f5512ad3c8b2e1f47d09c563ae781b24d60f93e5c71820da4
A single Bitcoin transaction commits the root of a Merkle tree containing thousands of GPR hashes. Each individual GPR carries the Merkle path needed to prove its inclusion, without revealing any other hash in the batch.
Why a Merkle tree
Batching thousands of proofs into a single Bitcoin transaction keeps cost minimal and throughput effectively unbounded. The Merkle path lets any single hash be independently verified without exposing the rest.
Why Bitcoin
The largest and most heavily computationally secured public ledger in continuous operation: running since 2009, no successful attack on confirmed blocks, fully public, no account or fee required to verify. A second, independent timestamping method is planned, to give institutions seeking redundancy more than one anchor.
What the anchor proves
A publicly verifiable lower bound on the GPR's existence. If a GPR is anchored in a 2026 Bitcoin block, it is mathematically provable that the GPR, and the file it references, existed no later than that date. Not an assertion by any authority; a consequence of the blockchain's structure.
II · Verification
Independent, Reproducible, Real-Time
Verification is the critical public-facing function of the system. It must be independently reproducible by anyone, require no trust in GAMI for proof validation, and produce results in near-real-time. The design goal is that the verification process can be fully reimplemented by a third party using only the published standards and the open-source toolchain, and that the result would be identical.
Lookup mode
Verifier has only the file
The hash is computed client-side via the Web Crypto API. The 64-character hash is submitted to a GAMI-compatible index node, and the matching GPR, if any, is returned. All subsequent validation steps run against that GPR. This is the mode implemented by the public verifier at verify.authenticmemory.org.
Direct mode
Verifier has the file and the GPR
No external lookup. The proof is validated entirely locally against the Bitcoin blockchain and the institution's published public key. Suitable for court submissions, classified environments, or decades-future verification.
The three independent checks
In both modes, validation runs three checks. All three either pass or fail independently. A partial result (for example, a valid signature on a non-matching hash) is clearly surfaced and does not produce a positive verification.
- 01
File hash check
~2 s · client-sideCompute SHA-256 of the file. Compare to subject.hash in the GPR. Proves the file matches the one originally fingerprinted.
- 02
Signature check
< 1 msRemove the signature and timestamps fields, canonicalise (JCS), and validate the Ed25519 signature over the canonical bytes against the institution's public key, resolved from its DID document (DID:webvh / DID:web). Proves the named institution signed this exact GPR.
- 03
Timestamp check
< 10 msRemove the timestamps array, canonicalise, hash, and validate the OTS proof against the Bitcoin blockchain. Proves this signed GPR existed at the attested date.
-
Result
< 5 s end-to-endAll three checks pass independently: file matches, institution signed it, and this signed record existed at the attested date. < 5 s for a 1 GB video; < 1 s for an image or document.
What a verification result displays
- File integrity status (match confirmed / not found / mismatch)
- Signing institution and key validity
- Anchoring date and Bitcoin block reference
- Public metadata: title, collection, classification code
- Provenance history, if available (PREMIS fixity chain from the source archive system)
Contextual metadata provided by the institution is displayed alongside the cryptographic proof, clearly distinguishing what is proven from what is institutionally declared. Institutions can also embed the verifier as a widget in their own catalogues.
Validity is self-contained · discoverability is a convenience
The validity of a proof is entirely self-contained in the GPR and the Bitcoin blockchain. It does not depend on GAMI, on any mirror, or on any network connection. The discoverability of a proof (finding it by submitting only a file hash) does depend on an index node being available. This is the same separation that exists between a document's authenticity and a library catalogue's ability to help you find it. If every index node disappeared, every existing proof would remain fully valid and verifiable by anyone holding the GPR file directly.
Performance
| Step | Duration | Where it runs |
|---|---|---|
| Hash computation (1 GB video) | 2–3 s | Client-side (browser, Web Crypto API) |
| GPR lookup by hash | < 1 ms | Server (B-tree index, PostgreSQL on commodity hardware) |
| Signature verification | < 1 ms | Server or client (pure elliptic-curve arithmetic) |
| OTS proof verification | < 10 ms | Server or client (Merkle path + Bitcoin block header lookup) |
| End-to-end (large video) | < 5 s | Hash dominates; cryptographic checks add < 15 ms total |
| End-to-end (image / document) | < 1 s | End-to-end |
The lookup is a B-tree index query keyed on a 32-byte hash; sub-millisecond response remains achievable into the hundreds of millions of records on a single PostgreSQL server. The system scales linearly with collection size without architectural changes.
Index and mirrors
The index is a discovery layer: a way to retrieve a GPR from a file hash. The proof itself is carried by the GPR; no database query is part of validation.
Global index
A publicly accessible database keyed by file hash, holding only proof records, never original files. Upon anchoring, GPRs are published immediately. Storage footprint: 10–30 GB per 10 million GPRs. This is the only mandatory layer in every integration.
Mirror protocol
An open export format lets any institution, university, library, or media organisation operate a mirror over a full or partial copy. A mirror requires no coordination with GAMI beyond the initial export and periodic sync. Partner institutions are encouraged to mirror at least the subset covering their own collections; resilience grows with adoption.
Verifiers can be configured to query multiple index nodes and fall back automatically if one is unavailable. And for verification without any web dependency at all, the same checks run with command-line tools against a local Bitcoin node, given only the file and its GPR, with no connection to GAMI or any mirror required.
III · Archival Integration
Post-Ingestion Layer Within OAIS Workflows
GAMI is designed as a post-ingestion layer within OAIS-conformant workflows (ISO 14721). It does not replace, modify, or interfere with existing preservation processes. It reads existing data and adds a cryptographic proof layer on top.
GAMI never writes to the preservation system. It consumes what the system already produces. No schema changes. No plugins. No database modifications.
Integration model
The integration follows a consistent four-step pattern regardless of the underlying system.
- 01
Read
existing AIPs, METS, PREMISAccess file hashes and metadata from the existing preservation system. Where SHA-256 hashes are already computed, GAMI reuses them directly.
- 02
Build
construct GPR · sign Ed25519Construct GPRs from the collected hashes and metadata. Sign with the institution's Ed25519 private key.
- 03
Anchor
Merkle root → OTS → BitcoinAggregate GPRs into a Merkle tree and submit the root via OpenTimestamps to the Bitcoin blockchain.
- 04
Store
global index · public verifierCompleted GPRs are submitted to the global index, immediately discoverable via the public verifier and any mirror node.
The same four-step loop runs for every batch (daily, weekly, or per-file) without coordination with GAMI.
System-specific integration
The archival landscape is diverse. The integration model accommodates this range without requiring institutions to standardise first.
| System | Type | Integration approach |
|---|---|---|
| Archivematica | Open-source OAIS | Read SHA-256 hashes from METS files and PREMIS event logs. Ingest provenance chain (fixity history). No API required: direct filesystem access to AIP structure. |
| Preservica | Commercial OAIS | Query content objects via REST API. Retrieve fixity information and descriptive metadata. Read-only API access. |
| CollectiveAccess | Collections management | Query via REST API or direct database access. Map collection metadata to GPR fields. |
| Filesystem / NAS | Unmanaged file storage | Walk directory tree, compute hashes, optionally read metadata from sidecar files or CSV manifests. |
| Custom systems | Institution-specific | Generic adapter framework: any system that can export file paths, hashes, and metadata in CSV/JSON can feed into GAMI. |
OAIS positioning
Mapped onto the OAIS reference model (ISO 14721), GAMI sits at the boundary between archival storage and access, as an external service rather than an OAIS functional entity. It reads the fixity hashes and PREMIS provenance events recorded in the AIP, together with descriptive metadata where the archive holds it, and publishes the resulting GPRs to the global index. GAMI never writes to or modifies an AIP: it is a strictly read-only consumer of existing archival data.
IV · Security & Long-Term Resilience
Cryptographic Foundations
Every component in the proof chain uses published, independently audited standards with no proprietary modifications.
| Component | Standard | Security level | Status |
|---|---|---|---|
| File hashing | SHA-256 (FIPS 180-4) | 128-bit post-quantum (Grover) | Industry standard · no known weaknesses |
| Digital signature | Ed25519 (RFC 8032) | 128-bit classical; quantum-vulnerable (Shor) | Protected retroactively by OTS |
| Timestamp anchoring | OpenTimestamps + Bitcoin | Bitcoin proof-of-work | Computationally infeasible to alter |
| Serialisation | RFC 8785 (JCS) | Deterministic representation | IETF standard |
| Key identity | DID:webvh / DID:web | Self-certifying, hash-chained key history over DNS + HTTPS | W3C DID Core · DIF specification |
| Descriptive metadata | Free-form JSON | Carried verbatim under the institutional signature | Displayed as provided |
| Field vocabulary | Schema.org + Dublin Core | Recommended term names for cross-system field semantics | Optional |
| Digital preservation | OAIS (ISO 14721), PREMIS | Integration with existing preservation workflows | Read-only consumer |
| Post-quantum signatures | SLH-DSA (FIPS 205) | Planned for the renewal chain | Not yet deployed |
Post-quantum resilience
SHA-256 is considered quantum-resistant: Grover's algorithm reduces its effective security to 128 bits, which remains secure by current standards. Ed25519 is vulnerable to Shor's algorithm on a sufficiently powerful quantum computer, but this risk is structurally mitigated by the OTS timestamp. Even if a signature could be forged in the future, a forger cannot create one that was anchored in a 2026 Bitcoin block. The timestamp retroactively protects the integrity of all prior signatures.
As a proactive measure, GAMI periodically re-anchors all existing GPRs using updated algorithms, a process we call the renewal chain. The process hashes all GPRs with a post-quantum algorithm, aggregates them into a new Merkle tree, signs with a post-quantum scheme (SLH-DSA, FIPS 205), and anchors the root via OTS. This proves that at the time of renewal, when previous algorithms were still fully secure, all existing GPRs already existed. The renewal is a single batch operation running in minutes, repeated every 3–5 years, well ahead of any practical quantum threat.
Failure modes and mitigations
Every system can fail. The architecture is designed so that no single failure invalidates existing proofs.
| Scenario | Impact | Mitigation |
|---|---|---|
| Institution's private key compromised | Future signatures invalid; all past GPRs remain valid, because the OTS timestamp proves they predate the published revocation. | Publish revocation date in DID document; rotate to new key pair. |
| GAMI ceases to exist | No impact on existing proofs. Any GPR can be verified using only the GPR file, the file itself, the Bitcoin blockchain, and the institution's public key. | Open-source toolchain published; mirror nodes maintain independent copies of the index; no central dependency for proof validation. |
| Institution's website goes offline (DID resolution) | DID resolution against the institution's live domain fails. | Key resolution falls back to GAMI's timestamped DID archive. For DID:webvh identities the archived log is self-certifying: anyone can recompute its hash chain, so the archive needs only to be available, not trusted. For legacy DID:web documents this fallback is a weaker trust model, disclosed as such; the OTS timestamp on each GPR bounds the trust requirement to the period the domain was live. |
| OTS calendar server unavailable | New anchoring delayed; existing proofs unaffected. | Multiple OTS calendar servers; anchoring retried automatically. |
| SHA-256 weakened | Theoretical: hash collisions become feasible. | Renewal chain re-anchors with stronger algorithm proactively, well before any weakness becomes exploitable. |
Transparency and auditability
Every verification step uses standard algorithms with published specifications, so any third party can reimplement the verifier and arrive at the same result. The cryptographic design has been developed in dialogue with the project's academic advisory board: researchers in coding theory, post-quantum cryptography, and digital trust at TU Munich, LMU Munich, and Princeton. An independent third-party security audit is planned ahead of broader deployment; the codebase and the resulting audit report will be published publicly.
V · Operational Footprint
Linear Scaling on Commodity Hardware
The architecture has no algorithmic bottleneck, consensus protocol, or coordination requirement that limits throughput. The only practically significant cost is I/O and CPU time for the initial hashing. Where preservation systems already produce SHA-256 fingerprints, even that cost is zero.
| Throughput | SHA-256 sustains roughly 500 MB/s per modern CPU core. Extrapolated to a 1 PB collection (10M files at ~100 MB each), hashing completes in days on a single 8–16 core server, and in hours across parallel nodes, bound by storage I/O rather than by GAMI itself. |
| Recommended cadence | Daily or weekly batches against new ingest. Resumable progress log; only new files are processed. |
| Hardware | Single dedicated server (8–16 cores, 64 GB RAM, NVMe). No cluster, no distributed system, no specialised hardware. |
| GPR storage | 10 million GPRs occupy 10–30 GB. A decade of anchoring at that volume stays under 1 TB, trivially archivable alongside source material. |
VI · Interoperability
Relationship to C2PA
The Coalition for Content Provenance and Authenticity (C2PA), backed by Adobe, Microsoft, Google, the BBC, and others, is the leading open standard for content credentials: a signed manifest bound to a digital asset that records its origin and edit history. For newly created recordings we explicitly recommend that institutions adopt C2PA at the point of capture. GAMI does not duplicate it. It is built for the case C2PA was not designed for: the existing archival corpus, created before such credentials existed, and authenticity that must stay verifiable for decades or longer.
| Property | C2PA | GAMI |
|---|---|---|
| Where the proof lives | In the asset, as an embedded manifest | In a separate record; the asset is never modified |
| Applying it to an existing collection | A manifest must be written into every file | Reuses the fixity hashes the archive already holds; read-only |
| Surviving metadata stripping or re-encoding | The embedded manifest is lost; a soft binding may re-match through a lookup service | A bit-exact copy has nothing to lose; re-encoded copies fall back to perceptual matching |
| Who counts as a legitimate signer | A signing certificate checked against a trust list the C2PA program governs | The institution's own key, on its own domain and embedded in the record; no authority authorises signers |
| Long-term temporal proof rests on | Timestamping authorities and certificate chains staying valid, maintained by periodic re-timestamping | Historical Bitcoin block headers, immutable and needing no maintaining authority |
| Ongoing dependency for verification | The signer's CA, the timestamp authority, and the trust-list maintainer, or their archived validation data | None beyond public Bitcoin headers; the record is self-contained and discovery is served by independent mirrors |
| Content edit history | Recorded | Not recorded; an append-only event chain is possible |
For cultural heritage, three differences are decisive
01Sovereignty
C2PA recognises a signer by checking its certificate against a trust list maintained centrally by the C2PA program, today dominated by a few commercial actors. A national archive or memorial institution is unlikely to accept that the authenticity of its own historical record depends on membership in such a list, particularly in cross-border use. Under GAMI's DID model each institution is its own trust root: it publishes its keys, together with their full verifiable history under DID:webvh, on its own domain, and verification checks the institution's own signature, not a central authorisation. Because the signing key is embedded in the record, with its binding independently timestamped, verifying an existing proof needs no certificate authority and no live service.
02Lifespan
A C2PA timestamp depends on timestamping authorities and certificate chains staying valid. Sustaining that across fifty or a hundred years means re-timestamping before certificates expire and preserving the validation data to prove they were valid when signed, an obligation that cannot lapse. GAMI's temporal proof rests on historical Bitcoin block headers, which are immutable, verifiable offline, and bound to no authority that has to survive, so a record stays verifiable even if GAMI as an organisation does not.
03Adoption
Memorial sites and national archives change preservation practice slowly, often over years, and bringing them onto a shared system worldwide is the hardest part of any such effort. A method that writes into preservation masters runs straight into what makes that hard: the security and integrity review that altering authoritative holdings demands, and re-ingesting collections that can reach petabytes. GAMI requires none of this. It reads the fixity hashes an archive already maintains and never alters a file, so there is no migration and far less to review. This lowers both the time and the cost of adoption, and time is the binding constraint: the window for anchoring the world's historically significant material is closing as AI-generated content nears the point where it can no longer be distinguished from authentic recordings.
What no signature settles: domains vs. institutions
A valid signature on yadvashem.com (instead of yadvashem.org) is cryptographically sound, but it does not show the domain is Yad Vashem rather than a lookalike. This gap is not fundamental, because domain ownership is publicly checkable. GAMI can package that check as an optional directory of confirmed institutional domains, maintained by the memory institutions themselves, which the public verifier uses to label a recognised institution and flag lookalike domains. It is not a central trust list and never sits in the verification path: a record from an unlisted domain stays fully valid and independently verifiable. The directory only surfaces what anyone could confirm for themselves, rather than deciding, as C2PA's list does, whether a proof counts as trusted at all.
The two standards compose in both directions
While the GPR's append-only chain reference can log institutional events over time, it does not record the content-level edit history that C2PA does. The two are complementary:
C2PA → GAMI
A file that already carries C2PA credentials, for example from a C2PA-enabled camera, can be anchored by GAMI with the manifest referenced in the GPR metadata. C2PA then documents how the file was made, and GAMI establishes that this exact file existed and was vouched for, on terms that outlast both the device vendor and any certificate. GAMI references the prior claim rather than re-validating the device attestation.
GAMI → C2PA
A GPR can travel as a C2PA custom assertion in a manifest on a distribution copy, leaving the original untouched. A generic C2PA viewer today shows only that an assertion is present; verifying it needs GAMI-aware tooling, with checks reproducible from the open standards GAMI publishes. The intended path is for C2PA viewers to recognise the assertion type, so the record is surfaced and verified inline wherever C2PA is supported.
VII · Evidentiary Framework
What a Proof Establishes — and What It Does Not
This distinction is material. Verification results are displayed to journalists, researchers, and legal practitioners who require an accurate account of which claims are cryptographically proven and which are institutional declarations.
What a GAMI proof does not establish
Content truthfulness. A witness may be mistaken; a photograph may be staged. Questions of historical interpretation, not cryptographic proof.
Pre-anchoring integrity. GAMI does not prove the file was unmodified before anchoring. Where available, pre-anchoring fixity records are included as Tier 2 (institutionally declared) evidence.
Uniqueness. GAMI does not assert the anchored version is the only or original version of a file.
Full archival authenticity. Authenticity in the archival sense encompasses creation context, custodial history, and fonds membership: dimensions that extend beyond what any cryptographic system can prove. GAMI captures these as signed metadata where available, complementing but not replacing traditional archival practice.
Two tiers of evidence
Most institutions operating OAIS-conformant systems already maintain documented integrity histories. Archivematica, for instance, generates PREMIS events with fixity timestamps throughout a file's lifecycle. GAMI captures those records as metadata within the GPR, extending the documented chain backwards in time. The verification interface displays both tiers with explicit attribution, so users can distinguish what is cryptographically proven from what is institutionally declared.
Tier 1 — Cryptographically anchored
The OTS timestamp provides an independently verifiable existence proof from the anchoring date forward. Requires no trust in any institution.
Tier 2 — Institutionally documented
Fixity records from the archive system document integrity for the period before GAMI anchoring. Requires trust in the institution's preservation infrastructure, but is signed and timestamped together with the GPR.
Evidentiary weight and timing
The evidentiary weight of an existence proof depends on when the timestamp was created relative to the state of synthetic media technology. A timestamp anchoring a file to 2026 carries a different implication than one anchoring it to 2032.
If a file can be shown to have existed in exactly this form in 2026, and if it is historically clear that visually and technically indistinguishable synthetic fabrications were not achievable at that time, then the file predates the capability required to fabricate it. This inference holds regardless of what synthetic media technology becomes capable of later. The timestamp does not expire; it places the file in a specific historical moment whose technological conditions are independently knowable.
A timestamp created after indistinguishable synthetic fabrication becomes feasible can no longer support this inference. The existence proof remains valid, but it no longer rules out the possibility of synthetic origin. Files anchored before that threshold retain the stronger evidentiary property permanently. This is the basis for treating anchoring of existing historical collections as time-sensitive.
Two anchoring scenarios: same proof mechanism, different evidentiary weight
anchored 2026
Strong evidentiary weight
Proves existence before indistinguishable synthetic fabrication was technically feasible. Rules out synthetic origin. Permanently retains this property.
anchored 2032
Existence proof only
Proves the file existed in exactly this form at the anchoring date. Does not rule out the possibility that the file was synthesised.
What this means for your institution
Understand what a pilot integration looks like in practice: what your team does, what GAMI does, and what you receive.
For institutionsSee it as a story
Walk through the full authentication journey for a single file, from first recording to independent verification decades later, in an interactive narrative.
How it worksThe GAMI Proof Record schema v1 is published as a JSON Schema at authenticmemory.org/schema/v1/gpr-schema.json. Reference implementations and open-source tooling are in preparation alongside the first pilot integrations and will be published once stabilised. Technical questions and integration discussions with institutional IT departments are welcome. Write to info@authenticmemory.org.