SIGNAL · CLEAR
LAT 37.1°NLON 93.0°WVOL XVII · 2026
DISPATCH 042 — STRUCTURE OVER STACK·FIELD NOTE — AUDITABLE BY DESIGN·DOCTRINE — DEFENSIBLE UNDER SCRUTINY·NEW SPRINT WINDOW OPEN · Q3·DISPATCH 042 — STRUCTURE OVER STACK·FIELD NOTE — AUDITABLE BY DESIGN·DOCTRINE — DEFENSIBLE UNDER SCRUTINY·NEW SPRINT WINDOW OPEN · Q3·
Atlas North Institute
ATLAS NORTH
INSTITUTE
Book a Briefing
Book a Briefing
N · 04
90 · S
GAD · Manifesto · Ceremony record

The Ceremony Record

Governed run 38, exported as a GAD envelope and published in its original export layout, so the sealed checksum file verifies as it was written.

Release status· Documentation release docs-2026.07-r3, candidate. Specification sealed at v1.3 (succession-7). Checksums ship unsigned; the findings register is published and open, and the documentation package’s exact evidence references are still pending before it calls itself the public distribution. Independent formal and cryptographic review has not begun; results are Propositions and Claims until it does.

Scope: the status above describes the documentation package, whose current release (docs-2026.07-r3) carries the prior revision of this document. The status of the sealed revision published here is the evaluator's four answers, printed on the manifesto page.

Text © 2026 Atlas North Institute LLC · CC BY-ND 4.0 · name and marks reserved · implementing the methodology requires no permission.

What is published here

Eighteen files. They are the record of the governed run that sealed the GAD manifesto: the core bundle, the evidence envelope, the RFC 3161 anchor over the record's root, the evaluator's signed judgment, and the two companions that explain and check the rest.

The layout is the exporter's own, not a tidied-up one, and that is deliberate. SHA256SUMS names these exact paths, so it verifies as written; and HANDOFF.md's instructions — run the sums check from the record root, run the evaluator from inside record-run-38-2026-08-25T22-55-47-343Z — are true against this tree rather than against some other machine's copy. Nothing here has been renamed, re-encoded, reformatted, or pretty-printed.

One filename differs from the courier bundle. The judgment arrives there as second-machine-judgment-q.json and publishes here as evaluator-judgment-q.json, at the same digest d7ce18cb — a reader holding the courier bundle can match the two by digest. The name changed because the bytes do not attest to which machine produced the judgment, and a filename should not claim what its contents do not.

What the checksum file covers

SHA256SUMS covers 14 of the 18 files. A passing sha256sum -c SHA256SUMS is not a check of the whole record, and should not be read as one.

The four files it does not cover, each with its digest:

  • gad-manifesto.md — 0fd6ff73b40cc974bf5323a1b394a3eea240d740520f4f6ebbc5962f7626a911
  • HANDOFF.md — 14433949f1dda7d6c345377741f9e487c2ce8201fc05d5f994d1865c20bfd728
  • evaluator-judgment-q.json — d7ce18cba41aebd837b3f4f81a5cb0aef7432f5a3c1375190031478845ac8b8c
  • SHA256SUMS — 7bd3fe0d6cd6913e60675e6d9a762b3282bffcb265fe9a45067e8587121b565b

Three of those four are outside the checksum file for a reason and one is a limitation. The manifesto is the object under governance, bound by the frozen plan and the run's checks rather than by this companion. The judgment is produced by the evaluator after the export and is signed in its own right. SHA256SUMS cannot cover itself; its authentication would be an operator detached signature, and this bundle ships without one. HANDOFF.md is simply uncovered: it is explanatory prose, and its digest is published here so it can be pinned anyway.

Verify the four against the digests above and the fourteen with the checksum file, and every published byte of the record has been checked.

Every file, with its digest

Checking it

Download the record with its paths intact, then from the record root:

sha256sum -c SHA256SUMS

Fourteen lines, all OK. Then check the four uncovered files against the digests above, and the anchor against the token:

openssl ts -reply -in record-run-38-2026-08-25T22-55-47-343Z/envelope/anchors/root-core-anchor.tsr -text

Its message imprint must equal root_core, 253d9e8c62154f5a3edfd409c1e7480fefd9ca978af86e1efd477c7b3e2fd629, and its serial is 0x07435033.

Recomputing the four answers — VALID_RECORD, OUTCOME, CONTRACT_SATISFIED, and DEFENSIBLE — needs the evaluator, not these checks. HANDOFF.md has the procedure; the manifesto page summarizes it.

What this record does not attest

The evaluation is stated by the operator to have run on a second machine. Nothing in these bytes attests to that, and the judgment's evaluator identity reads as a development credential. Under the trust policy's own definition — independence evaluated over the named parties, never over bytes — this evaluation is not independent, and the page does not call it that.

The record's further stated limitations, including the null spec_hash and the fixed development gate principal, are named in HANDOFF.md and carried as entries in the findings register.

Unlike every file listed above, the register is not pinned to a digest. It is the specification's open channel for findings: its contents grow as findings are recorded, so its bytes change by design and no manifest binds them. Cite it by entry number rather than by hash.