**GLO** **EXTERNAL ANCHOR ARCHITECTURE** *Canonical Specification · Closing the Gödelian Gap* --------------------- ------------------------------------------------- **Document ID** GLO-EAA-v1.0.0 **Status** CANONICAL --- Frozen on first anchor event **Version** 1.0.0 **Author** Daniel Sutherland \| glospec.org **Classification** GLO Core Infrastructure **Depends On** GLO-Core v1.2 · Constitution v0.02 · Lane-1 Kit v0.1.6 **Anchor Trigger** Every canonical release event (version bump to GLO-Core, Constitution revision, frozen artifact set change) **Copyright** © 2025--2026 Daniel Sutherland. All rights reserved. Canonical source: glospec.org. --------------------- ------------------------------------------------- **EXECUTIVE SUMMARY** This document specifies the GLO External Anchor Architecture (GLO-EAA) --- the mechanism by which GLO\'s canonical artifact integrity is verified by parties outside GLO\'s own trust boundary. It is the operational closure of the Gödelian incompleteness gap identified in the GLO governance architecture: the structural impossibility of any sufficiently powerful formal system proving its own consistency from within itself. The architecture does not claim to solve Gödel\'s incompleteness theorems. It implements the only honest engineering response to them: make any violation of canonical integrity permanently detectable by any third party, without requiring trust in GLO, its operators, or any single external authority. > *The external anchor does not prove GLO\'s consistency. It converts > silent internal failure into externally visible divergence --- making > dishonesty expensive and detectable rather than free and invisible.* The specification covers three architectural layers, one identity-binding mechanism, one implementation script (glo_anchor.py), a release gate policy addition to the Lane-1 Governance Kit, and a verification procedure table covering all anticipated auditor profiles. **PART I --- THE PROBLEM: THE GÖDELIAN GAP** **1.1 What the Gap Is** Every verification mechanism currently operating within GLO lives inside GLO\'s own trust boundary. The SHA-256 manifests are generated by GLO. The SQLite hash-chain is stored by GLO. The hash-chain head rehydration is performed by GLO. The pytest suite runs inside GLO. The ALC guard is itself a GLO component. This means that a sufficiently compromised GLO instance --- specifically one compromised at the ALC level, which is the failure mode already named and locked in the architecture --- can generate valid-looking SHA-256 manifests, pass its own pytest suite, and rehydrate a hash-chain head that attests to a history that was silently altered. The attestation is only as trustworthy as the attester, and the attester is the thing being attested to. ----------------------------------------------------------------------- **Gödel\'s Second Incompleteness Theorem:** A consistent formal system powerful enough to express arithmetic cannot prove its own consistency. GLO\'s current architecture proves GLO\'s integrity using GLO. That structural identity is the gap. ----------------------------------------------------------------------- **1.2 Why Externalizing Alone Does Not Solve It** Any external anchor system is itself a formal system with its own trust boundary, consistency assumptions, and potential failure modes. Adding an anchor moves the gap one level up --- it does not eliminate it. The blockchain has its own consensus mechanism. The timestamping authority has its own certificate chain. The regress is permanent. The correct framing is therefore not \'close the gap\' but \'govern it.\' The external anchor converts an undetectable internal failure into a detectable external divergence. That is the achievable and architecturally honest objective. **1.3 Why a Blockchain Is Not Required** The anchor only needs three properties: it must be outside GLO\'s trust boundary, it must be append-only and tamper-evident once written, and it must be independently verifiable by a third party without GLO\'s participation. A blockchain satisfies all three but adds unnecessary complexity and its own governance dependencies. The architecture specified here achieves all three properties using established open standards --- Sigstore/Rekor and RFC 3161 --- that carry broader institutional recognition, are free to operate, and impose no write-back relationship with GLO. **PART II --- THE ARCHITECTURE: THREE LAYERS + IDENTITY** The GLO External Anchor Architecture consists of four components operating in sequence at each canonical release event. The first is GLO-controlled. The remaining three are external and independent. -------- ------------- ------------------ -------------------------------- **\#** **Layer** **Technology** **Purpose** **0** **GPG GPG / Ed25519 Identity binding --- proves Signing** authorship before anything touches an external system **1** **Internal SHA-256 tree Binds entire canonical artifact Merkle Root** set to a single hash under GLO control **2** **Rekor / Transparency log Cryptographic-grade, publicly Sigstore** auditable, tamper-evident inclusion proof **3** **RFC 3161 Trusted timestamp Legal/regulatory-grade TSA** timestamped receipt, self-contained, forever verifiable -------- ------------- ------------------ -------------------------------- **Layer 0 --- GPG Identity Binding** Before submission to any external system, the GLO Merkle root is signed with the author\'s GPG private key (recommended: Ed25519 curve). This establishes authorship provenance. The Rekor and RFC 3161 proofs establish what existed and when. The GPG signature establishes who asserted it. Without this layer the architecture has proof of state but not proof of provenance --- a critical gap for regulatory and legal contexts. ----------------------------------------------------------------------- **Key Management Policy:** The GPG private key used for GLO anchor signing must be stored offline (hardware security key or air-gapped keystore). The public key must be published to at least two independent keyservers (keys.openpgp.org and keyserver.ubuntu.com) and recorded in the GLO-EAA manifest. Key rotation requires a new anchor event with both the old and new key signatures present in the transition release. ----------------------------------------------------------------------- **Layer 1 --- Internal GLO Merkle Tree** The internal Merkle tree is constructed from the canonical artifact set at each release event. It is the single object that is anchored externally. Its construction follows a deterministic algorithm to ensure any independent party can recompute the root and verify it matches the published anchor. **Construction Algorithm** Step 1 --- Enumerate: Collect all canonical artifact file paths in the release set, sorted lexicographically by relative path. Sorting is mandatory; non-deterministic enumeration produces different roots for identical artifact sets. Step 2 --- Leaf hashing: For each file, compute SHA-256(file_path_utf8 + \":\" + file_content_bytes). Including the path in the leaf hash prevents a substitution attack where a file\'s content is preserved but its identity is swapped. Step 3 --- Tree construction: Build a binary Merkle tree from leaf hashes using SHA-256(left_child_hash + right_child_hash) at each internal node. If the number of leaves is odd, duplicate the last leaf before pairing. Step 4 --- Root derivation: The root hash is the single hash at the apex of the tree. This is the value submitted to Layers 2 and 3. +-----------------------------------------------------------------------+ | MERKLE ROOT COMPUTATION (conceptual) | | | | artifacts = sorted(glob(\'canonical/\*\*/\*\'), key=lambda p: str(p)) | | | | leaves = \[sha256(path + \':\' + content) for path, content in | | artifacts\] | | | | tree = leaves | | | | while len(tree) \> 1: | | | | if len(tree) % 2 == 1: tree.append(tree\[-1\]) \# duplicate odd leaf | | | | tree = \[sha256(tree\[i\] + tree\[i+1\]) for i in range(0, len(tree), | | 2)\] | | | | merkle_root = tree\[0\] | +-----------------------------------------------------------------------+ **Layer 2 --- Rekor Transparency Log (Primary External Anchor)** Rekor is an append-only, tamper-evident transparency log operated by the Sigstore project under the Linux Foundation. It was designed specifically for software supply chain integrity and is the same infrastructure used to secure Kubernetes, major Linux distributions, and the Python package ecosystem. Submission produces a signed log entry containing the submitted hash, a server-generated RFC 3339 timestamp, a unique log UUID, and a log inclusion proof --- a cryptographic proof that the entry is in the log and cannot be removed or altered without the alteration being detectable by any party holding the log\'s public tree head. +-----------------------------------------------------------------------+ | **Why Rekor specifically:** It is free, production-grade, Linux | | Foundation backed, carries trajectory toward regulatory recognition | | in CISA and NIST supply chain guidance, requires no account or | | ongoing relationship, and imposes zero write-back to GLO. The log is | | publicly queryable forever using the UUID returned at submission | | time. | | | | **Endpoint:** https://rekor.sigstore.dev | | | | **Submission format:** Rekord entry with hashedrekord type, SHA-256 | | hash, GPG signature, and public key. | | | | **Verification:** rekor-cli verify \--uuid \ \--artifact-hash | | \ | +-----------------------------------------------------------------------+ **Layer 3 --- RFC 3161 Trusted Timestamp (Legal/Regulatory Layer)** RFC 3161 is the ISO standard for trusted timestamping. A Timestamp Authority (TSA) receives a hash, signs it with their private key, and returns a Timestamp Response (.tsr file) --- a self-contained, cryptographically bound receipt proving the hash existed at or before the stated time. The .tsr file is verifiable forever using the TSA\'s public certificate chain, which is independently published and not subject to revocation. No ongoing relationship with the TSA is required after issuance. This is the layer that holds up in a court, a regulatory audit, or an academic peer review. +-----------------------------------------------------------------------+ | **Recommended TSA:** DigiCert Timestamp Authority (primary) or | | Sectigo (backup). Both carry root certificates present in every major | | OS and browser certificate store. | | | | **Submission:** openssl ts -query -data \ -sha256 -cert | | -out request.tsq | | | | curl -H \'Content-Type: application/timestamp-query\' \--data-binary | | \@request.tsq \ -o anchor.tsr | | | | **Verification:** openssl ts -verify -in anchor.tsr -queryfile | | request.tsq -CAfile tsa_chain.pem | +-----------------------------------------------------------------------+ **PART III --- IMPLEMENTATION: glo_anchor.py** The glo_anchor.py script is the canonical implementation of the GLO-EAA anchor event. It is a single executable Python file that performs all seven steps of the anchor operation in sequence, writes a structured anchor log entry, and outputs a human-readable verification receipt. The script is itself a canonical GLO artifact --- its SHA-256 hash is included in each anchor\'s Merkle tree, ensuring that modifications to the anchoring mechanism itself are detectable. **3.1 Script Specification** +---------------------------------------------------------------------------------+ | #!/usr/bin/env python3 | | | | \"\"\" | | | | glo_anchor.py --- GLO External Anchor Architecture v1.0.0 | | | | Canonical implementation of the GLO-EAA anchor event. | | | | Copyright © 2025-2026 Daniel Sutherland. All rights reserved. | | | | Canonical source: glospec.org | | | | \"\"\" | | | | import hashlib, json, subprocess, sys, datetime, pathlib | | | | from dataclasses import dataclass, asdict | | | | from typing import List, Optional | | | | CANONICAL_ROOT = | | pathlib.Path(\'\~/Documents/GLO_MODELS/LIVE_MIRROR_REFERENCE\').expanduser() | | | | ANCHOR_LOG = | | pathlib.Path(\'\~/Documents/GLO_MODELS/GLO_RUN/anchor_log.jsonl\').expanduser() | | | | GPG_FINGERPRINT = \'\\' \# Ed25519 recommended | | | | TSA_URL = \'https://timestamp.digicert.com\' | | | | REKOR_URL = \'https://rekor.sigstore.dev\' | | | | \# ── STEP 1: Enumerate canonical artifact set ────────────────────────── | | | | def enumerate_artifacts(root: pathlib.Path) -\> List\[pathlib.Path\]: | | | | return sorted(\[p for p in root.rglob(\'\*\') if p.is_file()\], | | | | key=lambda p: str(p.relative_to(root))) | | | | \# ── STEP 2: SHA-256 each artifact (path-bound) ─────────────────────── | | | | def hash_artifact(path: pathlib.Path, root: pathlib.Path) -\> str: | | | | rel = str(path.relative_to(root)) | | | | data = rel.encode() + b\':\' + path.read_bytes() | | | | return hashlib.sha256(data).hexdigest() | | | | \# ── STEP 3: Build internal Merkle tree ─────────────────────────────── | | | | def build_merkle_root(leaves: List\[str\]) -\> str: | | | | tree = \[bytes.fromhex(h) for h in leaves\] | | | | while len(tree) \> 1: | | | | if len(tree) % 2 == 1: tree.append(tree\[-1\]) | | | | tree = \[hashlib.sha256(tree\[i\] + tree\[i+1\]).digest() | | | | for i in range(0, len(tree), 2)\] | | | | return tree\[0\].hex() | | | | \# ── STEP 4: GPG sign the Merkle root ───────────────────────────────── | | | | def gpg_sign(merkle_root: str) -\> str: | | | | result = subprocess.run( | | | | \[\'gpg\', \'\--armor\', \'\--detach-sign\', \'\--default-key\', | | GPG_FINGERPRINT, | | | | \'\--output\', \'-\', \'-\'\], | | | | input=merkle_root.encode(), capture_output=True, check=True | | | | ) | | | | return result.stdout.decode() | | | | \# ── STEP 5: Submit to Rekor ─────────────────────────────────────────── | | | | def submit_rekor(merkle_root: str, gpg_signature: str) -\> dict: | | | | \# Returns: { uuid, log_index, integrated_time, inclusion_proof } | | | | \# Implementation: rekor-cli upload \--type hashedrekord \... | | | | \# Full implementation in glo_anchor_rekor.py companion module | | | | pass | | | | \# ── STEP 6: Obtain RFC 3161 timestamp ──────────────────────────────── | | | | def get_rfc3161_timestamp(merkle_root: str, tsr_path: pathlib.Path) -\> str: | | | | \# Returns: path to .tsr file | | | | \# Implementation: openssl ts -query \| curl TSA_URL | | | | \# Full implementation in glo_anchor_tsa.py companion module | | | | pass | | | | \# ── STEP 7: Write anchor log entry ─────────────────────────────────── | | | | def write_anchor_log(entry: dict) -\> None: | | | | ANCHOR_LOG.parent.mkdir(parents=True, exist_ok=True) | | | | with ANCHOR_LOG.open(\'a\') as f: | | | | f.write(json.dumps(entry) + \'\\n\') | | | | \# ── ANCHOR LOG SCHEMA ───────────────────────────────────────────────── | | | | ANCHOR_LOG_SCHEMA = { | | | | \'schema_version\': \'1.0.0\', | | | | \'event_timestamp\': \'\\', | | | | \'glo_version\': \'\\', | | | | \'constitution_rev\': \'\\', | | | | \'artifact_count\': \'\\', | | | | \'artifact_manifest\': \[{\'path\': \'\\', \'sha256\': \'\\'}\], | | | | \'merkle_root\': \'\\', | | | | \'gpg_fingerprint\': \'\\', | | | | \'gpg_signature\': \'\\', | | | | \'rekor_uuid\': \'\\', | | | | \'rekor_log_index\': \'\\', | | | | \'rekor_log_url\': | | \'\\>\', | | | | \'tsr_path\': \'\\', | | | | \'tsa_url\': \'\\', | | | | \'prev_anchor_hash\': \'\\', | | | | \'notes\': \'\\', | | | | } | +---------------------------------------------------------------------------------+ **3.2 Anchor Log Chaining** Each anchor log entry includes the SHA-256 hash of the previous entry (prev_anchor_hash). This creates a cryptographically linked chain of custody. A gap or modification in the chain is detectable without any external system --- the internal chain integrity check is a necessary but not sufficient condition for validity. The external anchors provide the sufficient condition. The genesis anchor entry (the first ever produced) sets prev_anchor_hash to null. All subsequent entries must reference the hash of their immediate predecessor. The anchor log file itself is included in the canonical artifact set for the next release, making the chain self-referentially embedded in the Merkle tree it attests to. > *The anchor log chaining is the GLO equivalent of a blockchain\'s > linked block structure --- without requiring consensus infrastructure, > because the external Rekor and RFC 3161 layers provide the > tamper-evidence that blockchain consensus would otherwise supply.* **3.3 Verification Receipt** On completion, glo_anchor.py outputs a human-readable verification receipt to stdout and writes it as anchor_receipt\_\.txt alongside the anchor log. The receipt contains everything a third-party auditor needs to independently verify the anchor without access to GLO. +-----------------------------------------------------------------------+ | ═══════════════════════════════════════════════════════════════ | | | | GLO ANCHOR VERIFICATION RECEIPT | | | | ═══════════════════════════════════════════════════════════════ | | | | GLO Version : GLO-Core v1.2 / Constitution v0.02 | | | | Event Timestamp : 2026-03-08T18:00:00Z | | | | Artifact Count : \ files | | | | Merkle Root : \ | | | | GPG Key : \ | | | | REKOR | | | | UUID : \ | | | | Log Index : \ | | | | Verify URL : https://rekor.sigstore.dev/api/v1/log/entries/\ | | | | CLI Verify : rekor-cli verify \--uuid \ \--artifact-hash | | \ | | | | RFC 3161 | | | | TSA : https://timestamp.digicert.com | | | | Receipt File : anchor\_\.tsr | | | | CLI Verify : openssl ts -verify -in anchor.tsr -queryfile req.tsq | | | | -CAfile digicert_tsa_chain.pem | | | | CHAIN | | | | Prev Anchor : \ | | | | This Entry Hash : \ | | | | ═══════════════════════════════════════════════════════════════ | | | | Copyright © 2025-2026 Daniel Sutherland. glospec.org | | | | ═══════════════════════════════════════════════════════════════ | +-----------------------------------------------------------------------+ **PART IV --- RELEASE GATE POLICY** The following policy addition is hereby incorporated into the GLO Lane-1 Governance Kit (Master v0.1.6 / pilot-v0.02). It defines the anchor event as a mandatory release gate --- a prerequisite condition that must be satisfied before any GLO release transitions from STAGING to CANONICAL status. +-----------------------------------------------------------------------+ | **POLICY ADDITION: GLO-LANE1-ANCHOR-GATE-v1.0** | | | | **Trigger condition:** Any of the following events requires an anchor | | event before the release is considered canonical: version bump to | | GLO-Core; revision to Constitution; addition, removal, or | | modification of any file in the frozen artifact set; modification of | | glo_anchor.py itself. | | | | **Gate condition:** A release is STAGING until all three of the | | following are present in the anchor log entry for that release: (1) a | | valid Rekor UUID with verifiable inclusion proof, (2) a valid RFC | | 3161 .tsr file passing OpenSSL verification, (3) a valid GPG | | signature over the Merkle root by the canonical GLO signing key. | | | | **Failure mode:** A release lacking a complete anchor log entry is | | classified as STAGING regardless of its internal validation state. | | Internal pytest-passing status alone does not constitute canonical | | status. | | | | **ALC interaction:** The anchor event is the primary operational | | mitigation for the ALC (Audit-Layer Capture) failure mode. A | | compromised internal GLO instance cannot forge a Rekor inclusion | | proof or an RFC 3161 receipt for a hash it did not publish. These | | proofs are therefore the minimum external evidence required to assert | | canonical status. | | | | *This policy addition is effective immediately upon the first | | successful anchor event. Prior releases are retroactively classified | | as STAGING-LEGACY and may be anchored post-hoc using the genesis | | procedure defined in Appendix A.* | +-----------------------------------------------------------------------+ **PART V --- VERIFICATION PROCEDURES BY AUDITOR PROFILE** The following table specifies the exact verification procedure for each anticipated external auditor profile. All procedures are executable using standard open-source tooling with zero knowledge of GLO\'s internal architecture. --------------- ------------------ ------------------------ ------------- **Auditor** **Primary **Verification **Layers Question** Procedure** Used** **Academic *Has this artifact Recompute Merkle root GPG + Rekor Researcher** been modified from artifact set. Query since Rekor UUID. Verify publication?* inclusion proof against published log root. Hashes must match. **Regulator / *When was this Verify RFC 3161 receipt GPG + RFC Auditor** version certified against DigiCert TSA 3161 and by whom?* certificate chain via OpenSSL. Check GPG signature against published public key. **Legal / *Can you prove RFC 3161 .tsr file is RFC 3161 Court** this document the primary exhibit. TSA existed before certificate chain is dispute date?* independently verifiable. No GLO cooperation required. **Partner / *Is this the Verify Rekor UUID is Rekor + Integrator** canonical version present in anchor log. Merkle I should implement Confirm Merkle root against?* matches recomputed value from artifact set. **Security *Could GLO\'s own Rekor inclusion proof is Rekor Researcher** operators have verifiable against the forged this log\'s public tree head, record?* which GLO does not control. Forgery requires compromising the Sigstore infrastructure, not GLO. **Future GLO *Is the chain of Walk anchor log chain: All layers Auditor** custody unbroken verify each from genesis?* prev_anchor_hash links to prior entry. Verify each entry\'s Rekor and TSA proofs. Any gap in the chain is immediately visible. --------------- ------------------ ------------------------ ------------- **PART VI --- EXPLICIT TRUST ASSUMPTIONS** Intellectual honesty requires stating what this architecture assumes to be true. These are not hidden vulnerabilities --- they are acknowledged external dependencies that sit outside GLO\'s trust boundary and are accepted as necessary conditions for the architecture to function. +-----------------------------------------------------------------------+ | **TA-1 Rekor log integrity:** The Sigstore Rekor log is operated | | honestly by the Linux Foundation and has not been globally | | compromised. A Rekor compromise would be detectable by the broader | | software supply chain community, not only by GLO. | | | | **TA-2 RFC 3161 TSA integrity:** DigiCert\'s Timestamp Authority | | signs timestamps honestly and its certificate infrastructure has not | | been compromised. DigiCert is one of the world\'s largest CAs; its | | compromise would affect far more than GLO. | | | | **TA-3 GPG key security:** The GLO signing private key is stored | | securely offline and has not been extracted by an adversary. Key | | compromise is the single highest-impact failure mode in this | | architecture. Hardware security key storage is the mitigation. | | | | **TA-4 SHA-256 collision resistance:** SHA-256 has not been broken. | | This is a foundational cryptographic assumption shared by essentially | | all digital security infrastructure currently in operation. | | | | *These trust assumptions are not weaknesses unique to GLO-EAA. They | | are the shared foundation of global digital infrastructure. Accepting | | them is not a design compromise --- it is participation in the | | established cryptographic trust hierarchy.* | +-----------------------------------------------------------------------+ **APPENDIX A --- GENESIS ANCHOR PROCEDURE** The genesis anchor is the first anchor event ever performed for GLO. It establishes the root of the chain of custody. All subsequent anchors reference it via the prev_anchor_hash chain. The genesis procedure is identical to the standard anchor procedure with one exception: prev_anchor_hash is set to the string \'GENESIS\' rather than a hash value. The genesis entry should additionally include a narrative notes field describing the state of the artifact set at the time of anchoring, the GLO version being canonicalized, and the date of the first anchor event. Prior releases that predate the first anchor event are retroactively classified as STAGING-LEGACY. They may be anchored post-hoc by performing a standard anchor event for each release in chronological order, setting prev_anchor_hash to the hash of the immediately preceding anchor log entry. The first post-hoc anchor sets prev_anchor_hash to \'GENESIS\'. **APPENDIX B --- FILE AND PATH CONVENTIONS** --------------------- ------------------------------------------------------------------- **Anchor script** \~/Documents/GLO_MODELS/GLO_RUN/glo_anchor.py **Anchor log** \~/Documents/GLO_MODELS/GLO_RUN/anchor_log.jsonl **TSR receipts** \~/Documents/GLO_MODELS/GLO_RUN/tsr/anchor\_\.tsr **TSR query files** \~/Documents/GLO_MODELS/GLO_RUN/tsr/request\_\.tsq **Receipts (text)** \~/Documents/GLO_MODELS/GLO_RUN/receipts/receipt\_\.txt **TSA cert chain** \~/Documents/GLO_MODELS/GLO_RUN/certs/digicert_tsa_chain.pem **GPG public key** \~/Documents/GLO_MODELS/GLO_RUN/keys/glo_signing_pub.asc **Canonical root** \~/Documents/GLO_MODELS/LIVE_MIRROR_REFERENCE/ --------------------- ------------------------------------------------------------------- **CLOSING STATEMENT** > *This architecture does not satisfy Gödel\'s incompleteness theorems. > Nothing can. It implements the only intellectually honest engineering > response to them: acknowledge the gap, name it, bound it, and make any > violation permanently visible to observers outside the trust boundary. > That is GLO\'s epistemic position. It is a stronger position than > false completeness --- and the one that will hold under any serious > external scrutiny.* The GLO External Anchor Architecture is hereby designated a canonical GLO infrastructure specification. It is frozen at v1.0.0 upon the completion of the first successful anchor event that includes this document in its Merkle tree. Subsequent revisions require a new version number, a new anchor event, and an entry in the anchor log referencing the prior version. *Copyright © 2025--2026 Daniel Sutherland. All rights reserved. Canonical source: glospec.org.*