> For the complete documentation index, see [llms.txt](https://osintelligence-llc.gitbook.io/osintelligence/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://osintelligence-llc.gitbook.io/osintelligence/evidence-and-seals/verifying-a-seal.md).

# Verifying a Seal

*Read this once; every evidence page in this section assumes it. It explains what a seal on this record actually is, and how a reader with a text editor and a hash utility can check one without trusting this site, the author, or any model.*

## What a seal is

Each experiment in this section was **pre-registered**: its hypotheses, decision bars, banks, and analysis plan were written down and frozen **before any result data existed**. At the moment of freezing, a SHA-256 hash was computed over the pre-registration's text and written to a small companion file, the **`.sha256` sidecar**, beside it. From that instant the methodology is fixed: any later change to the frozen text changes the hash, and the original hash is already on the record.

This is the ordinary discipline of pre-registration from the empirical sciences, made mechanical. The seal does not ask the author to promise the methodology was not changed after the fact; it lets anyone prove it was not.

## The canonical-prefix self-hash

The hash is computed over a **canonical prefix** of the document, not the whole file, so the seal can be recorded inside the same document it seals without a chicken-and-egg problem. The algorithm, from the released `seal_prereg.py`, is exactly:

1. Read the document's raw bytes.
2. Normalize line endings: CRLF and CR become LF.
3. Find the seal marker, the line beginning `## 16. Seal` (the pre-registrations in this record place their seal section there; the released tool takes the marker as a parameter).
4. Take the prefix from the start of the file up to that marker.
5. Strip trailing whitespace from the prefix and append a single newline.
6. Compute SHA-256 over those UTF-8 bytes; render it lowercase hex.

Everything above the seal marker is the frozen methodology; everything at and below it, the seal section itself and any later corrigenda, sits outside the hash. That is deliberate: the record can grow a corrigendum below the line without ever disturbing the sealed prefix above it.

**Why the hex is never printed in the body.** The self-hash lives in the sidecar and the experiment marker, never inlined into the pre-registration's own frozen text. Inlining it would be self-referential (the hash would change the bytes it hashes) and, historically in this program, was the source of a documented failure class: a symbolic hash carried across some twenty documents that had never actually been computed. The rule the program settled on, and that this section follows, is that a hash is written once, hash-first, to a sidecar, and only ever quoted from there.

## How to verify one, step by step

Every evidence page prints its experiment's sidecar hex and prefix-byte count. To check it:

1. Obtain the frozen pre-registration text (reproduced verbatim on the evidence page, and on disk in the sealed repository).
2. Run the canonical algorithm above over it. A minimal Python reproduction:

```python
import hashlib, pathlib
raw = pathlib.Path("PRE_REGISTRATION.md").read_bytes()
lf = raw.replace(b"\r\n", b"\n").replace(b"\r", b"\n")
marker = lf.find(b"## 16. Seal")
prefix = lf[:marker].rstrip() + b"\n"
print(hashlib.sha256(prefix).hexdigest(), len(prefix))
```

3. Compare the printed hex and byte count against the values quoted on the evidence page (and in the `.sha256` sidecar). A match proves the methodology you are reading is byte-for-byte the one frozen before the run.

The released package ships a `verify_package.py` that does this over a whole download and independently re-derives its bundled example's seal; the same one-command check runs on any platform.

## The freeze-gate and the deviation discipline

A hash proves the text did not change; a **freeze-gate** stops it from changing in the first place. While an experiment is registered, a deterministic hook fires before every edit, write, and shell call and blocks any write to a frozen artifact unless a **deviation** has been logged for it. There is no override flag; disabling the gate means editing the hook itself, which leaves its own trace.

So a change to a sealed methodology has only one sanctioned path: log the deviation in the experiment's permanent ledger, then make the edit as a visible **corrigendum**, with the original preserved by strikethrough rather than overwritten. Where the evidence pages in this section show a corrigendum, that is the mechanism at work, and the frozen text above the seal is untouched.

## What closes an experiment

At the end of a run the experiment is **final-sealed**: its verdict is adjudicated mechanically against the pre-registered bars (no post-hoc discretion), and a **post-run integrity envelope** records every artifact the run produced, each by SHA-256. Each evidence page carries that verdict and that envelope alongside the frozen pre-registration, so the full chain, methodology frozen → run → verdict → artifacts, is checkable end to end.

The tooling that enforces all of this is released open source and described in [**The Instrument · MethodSeal**](/osintelligence/the-instrument-methodseal.md); this page is only what a reader needs to check a seal, not to run the discipline themselves.

***

*Verifying a Seal · Evidence & seals · The Sovereign Stack · CC BY 4.0 · © Jamey Kistner, OSINTelligence LLC*