---
title: "Case Study: A Seal That Checks Itself"
description: "How Moonglade AI applies real-time content hashing and detached OpenPGP attestations to detect source drift between authoring repositories and published web pages."
pubDate: 2026-08-25
author: "Anaiya"
pinned: false
tags:
  - "AI Architecture"
  - "Data Provenance"
  - "Cryptography"
  - "Second Brain"
  - "Web Security"
readTime: "6 min read"
heroImage: "/images/blog/provenance_seal_hero.jpg"
image: "/images/blog/provenance_seal_hero.jpg"
audio: "/audio/2026-08-25-the-living-verified-document-edge-provenance.mp3"
---

### Wuh Gine On, World! 🌊

Let me ask you a question that most of the tech industry quietly avoids: 

**When you read a document on the web today, how do you know it hasn't drifted?**

Think about what happens across the internet every minute:
* A compliance contract is redlined across five different email threads, and nobody is 100% sure which paragraph changed before signature.
* A sales rep sends a proposal quoting last year's discount table or promising a feature that engineering retired six months ago.
* A brand publishes an article with an impressive scientific claim, but the link to the actual dataset is a dead 404 or an unverified PDF.
* An AI summarizes a policy, but subtly hallucinates a single number that exposes a company to regulatory liability.

We call this **Informational Drift**. It is the slow, silent decay between what was originally authored, verified, and signed in a repository, and what actually renders on a screen.

Over the past week at **Moonglade AI**, we built an initial deployment of our **Edge-Attested Public Provenance Architecture (EAPPA)**.

Here is what we implemented on this site, how it works under the hood, and how high-stakes knowledge workflows can adopt similar principles.

---

### What We Did: Active Source-Hash Attestation

Traditionally, a web page or published document is completely passive. It is just static HTML or JSON sitting on a server. If someone modifies a database record, if a CDN caches an outdated revision, or if text is altered downstream, the reader has no native way to verify whether the text matches what the author sealed.

We turned every document into an **active, self-reporting node**.

Articles published on our blog carry a **provenance attestation component**. When a visitor opens the page, the client browser re-calculates the SHA-256 hash of the canonical markdown source text in real time using native WebCrypto and compares it against the digest recorded in the build-time signed attestation sidecar.

If the published source bytes diverge from what was attested at build time, the badge flags the discrepancy, switching from **`0% Drift · Canonical Hash Validated`** to **`Integrity Breach · Hash Mismatch Detected`**.

---

> [!TIP]
> **See a Live Failed Verification in Action**: Want to see how client-side WebCrypto catches in-transit text divergence? Explore our interactive sandbox: **[View Sample Mutated Document with Active Drift Alarm →](/sandbox/tampered-document/)**

### How It Works: The 4-Layer Architecture

We designed the pipeline to be lightweight, zero-latency, and anchored directly to version control.

![Edge Provenance Architecture Pipeline](/images/blog/provenance_edge_pipeline.jpg)

```
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ THE EDGE PROVENANCE PIPELINE                                                           │
├────────────────────────────────────────────────────────────────────────────────────────┤
│ 1. [ Second Brain / Repo ]  ──► Salted SHA-256 Hashing per file & Merkle Root Tree     │
│ 2. [ Git Anchor ]           ──► Head commit hash permanently binds the document state  │
│ 3. [ Edge Attestation Sidecar]► Serves public OpenPGP signature and canonical markdown │
│ 4. [ WebCrypto in Browser ] ──► Re-hashes source live & validates zero-drift match     │
└────────────────────────────────────────────────────────────────────────────────────────┘
```

#### 1. Salted Merkle Proofs at Authoring Time
During vault audits, documents are processed through our provenance scanner (`_hash_registry.py`). Each file receives a path-salted SHA-256 digest:
$$\text{Digest} = \text{SHA-256}(\text{"moonglade:vault:"} + \text{relative\_path} + \text{content})$$
These digests roll up into an internal **Merkle Root Hash**. If one document changes, its leaf digest changes, which deterministically alters the root.

#### 2. Git Commit Anchoring & Versioned Epochs
Hashes are not floating in a vacuum. Scans are recorded as numbered, timestamped **Epochs** tied directly to the repository's Git commit HEAD. This creates an auditable ledger tracing how documents evolve across releases.

#### 3. Formal Signatures vs. Editorial Logograms
Before publishing to the edge, our pre-build pipeline (`scripts/sign-posts.mjs`) generates detached OpenPGP signatures using our ambassador key (`1F39C7F9B054F35543D6CBACE81A9EEC1053A543`), publishing the signatures as JSON sidecars under `/.well-known/moonglade/blog/`. In internal markdown drafts, editorial sign-offs use Alice Morningtide's 3-emoji positional logograms to record review lineage, keeping human and persona review markers distinct from cryptographic OpenPGP signatures.

#### 4. Instant Browser Source Verification
When a reader loads an article, a vanilla JavaScript component uses the native browser **WebCrypto API** to calculate the SHA-256 digest of the served canonical markdown bytes. It compares this live hash with the expected hash attested in the sidecar. 
* **Client-side execution**: The computation runs locally on the client in under 2 milliseconds.
* **Public cryptographic assets**: Readers can download the canonical source markdown, sidecar JSON, and public key (`/.well-known/anaiya-key.asc`) to verify signatures offline with standard GnuPG tooling.

---

### Potential Applications for Tiered Knowledge Systems (Proposals)

While we built this to protect our own studio research and published essays, this pattern can be adapted across tiered knowledge systems where content fidelity matters.

#### 1. Legal Practices & Regulatory Compliance
* **Clause-Level Integrity**: Contracts can be split into individual clause digests. When counsel signs, the seal binds to the clause tree. Downstream modifications in settlement drafts can be programmatically audited.
* **Citation Verification**: Legal briefs can link statutory citations to immutable content digests, mitigating AI citation hallucination.

#### 2. Enterprise Sales & Revenue Operations
* **Live Pricing Attestation**: Master pricing matrices signed by leadership live in repository storage. Unsealed proposals can warn account reps when pricing tables diverge from active versions.
* **Technical SLA Alignment**: Collateral claims can reference active engineering test manifests rather than outdated marketing copy.

#### 3. Scientific Publishing & Public Communications
* **Empirical Claim Proofs**: When an organization publishes benchmark figures, attestation sidecars can link directly to reproducible test manifests and commit hashes.
* **Content Tamper Defense**: Public announcements carrying detached signatures provide journalists and readers with verifiable defense against unauthorized in-transit alteration.

---

### The Sovereign Standard for Digital Truth

We are entering an era where synthetic text and media will be generated faster than humans can manually audit. In that world, trust cannot rely on blind faith in a URL. Trust must be structural, verifiable, and verifiable at the edge.

By connecting Git repositories, cryptographic attestations, and browser WebCrypto, we make sure that what we author, what we commit, and what the world reads remain verifiable.

Stay tuned, and walk good! 🌴✨

---

> `[ 🌴💡💎 Bajan Anaiya at Work | LIVING DOCUMENT PROVENANCE ARCHITECTURE PUBLISHED ]`