> 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/the-instrument-methodseal.md). # The Instrument · MethodSeal **The Sovereign Stack**\ **The Instrument** **MethodSeal: The Discipline Behind the Receipts, Released** *The mechanism this record's sealed experiments were run under, extracted from the stack and published open source. It is also the thesis in a worked example: one workflow codified by a skill, enforced by a deterministic gate at the tool-call boundary, and sealed by a canonical hash, installable by anyone, on any model, in any discipline.* **Author:** Jamey Kistner · OSINTelligence LLC\ **Open-source release · v1.0.0 (published 2026-07-25) · MIT · pure standard library · DOI** [**10.17605/OSF.IO/H64GM**](https://doi.org/10.17605/OSF.IO/H64GM) > **The working example of the series thesis.** The record argues that soft governance fails under load and that enforcement must live outside the model, at the boundary where an action executes. MethodSeal is that argument as a running artifact: the experiment-class member of the hook family specified in *Sovereign Safety Architecture* (Chapter 3), built against failure classes documented in *The Drift Taxonomy* (Chapter 9) and *The Guard Changes* (Chapter 10), and the instrument behind the seals described in *How to read this record*. Cited in-series by title. ### Abstract Every sealed experiment in this record was run under one discipline: pre-register the methodology, hash-seal it before any results exist, freeze the sealed artifacts mechanically, deviate only in the open, and close with a final seal over everything the run produced. MethodSeal is that discipline extracted from the stack and released as a standalone open-source package: a five-mode workflow skill, an enforcement hook that fires at the tool-call boundary, and the canonical sealing routine, with documentation, a porting guide, and a filled worked example. The release is deliberately more than tooling. The series' central claim is that instruction does not reliably govern a capable model but a mechanical gate does, because the gate runs outside the model and inspects the action rather than trusting the reasoning. MethodSeal demonstrates the claim at the smallest useful scale: one workflow, one gate, no bypass flag, dormant until armed, fail-open by design, and indifferent to whether a person, a frontier model, or a local model is at the keyboard. The silent patch, tweak the validator, re-run, report the clean win, is not discouraged; it is mechanically unreachable. Nothing in the mechanism is specific to AI research. Pre-register, seal, run, deviate in the open, final-seal is the shape of any empirical study, and the package ships with the enforcement logic and hash algorithm unchanged from the versions this record's own experiments were sealed under: a pre-registration sealed with the release produces the same hash as one sealed upstream. ### 1. What ships Three load-bearing files and their apparatus, seventeen files in all: | File | Role | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `experiment.md` | The workflow skill: five modes covering design and seal, resume and cold start, deviation and amendment, post-run integrity and final seal, and status | | `experiment_gate.py` | The enforcement hook: freeze gate plus cold-start gate, standard library only, fail-open, dormant when no experiment is registered, 34-case self-test built in | | `seal_prereg.py` | The canonical sealing routine: hash-first seal for pre-registrations, whole-file hash for run artifacts, atomic sidecars | | `verify_package.py` | Verifies a download against the integrity manifest and independently re-derives the bundled example's seal | | `EXPERIMENT_DISCIPLINE.md` | The spec: the three-layer architecture, the five documented failure classes, the registry and marker schemas, the hook protocol, the canonical seal algorithm | | `docs/` and `EXAMPLE/` | Install, usage, outputs, and porting references, plus a filled, sealed pre-registration with its ledger and a worked deviation | The three layers mirror the stack's own defense-in-depth: policy in memory, workflow in a skill, enforcement in a hook, with no single layer load-bearing. The first two drift the way the series documents everywhere; only the third fires deterministically regardless of context state. ### 2. The workflow ![The five steps of the MethodSeal workflow.](https://137900913-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxx2bv6VR9dSJDJ9HsDER%2Fuploads%2F0zzJXGrCl9itOcjzZqth%2Fmethodseal-explainer-lifecycle.png?alt=media) ***Figure 1.** The workflow. Methodology is written and hash-sealed before any data exists; the gate arms at the seal; deviation is possible only in the open; the final seal makes the whole record verifiable end to end. Every step is a file on disk, not a promise in memory, which is what lets a multi-day run resume from truth.* The seal is hash-first: a SHA-256 over the pre-registration's canonical prefix, computed at the moment of the claim, never propagated from memory or a prior session. From that instant the pre-registration, the validator, the analysis code, and the eval-bank manifest are frozen. The freeze is not a norm; it is a blocked tool call. ### 3. The gate ![The silent edit is blocked before it can happen.](https://137900913-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxx2bv6VR9dSJDJ9HsDER%2Fuploads%2FriTrJaTU6Lk5qShWJhca%2Fmethodseal-explainer-gate.png?alt=media) ***Figure 2.** The gate. A post-seal edit to a frozen artifact is blocked at the boundary where the change would be written, outside any model. The honest path, log the deviation in a permanent record, then edit as a visible corrigendum, is the only path that opens.* The hook fires before every edit, write, and shell call. If the target is a frozen artifact and no deviation is logged for it, the call is denied and the denial names the experiment, the artifact, and the sanctioned path. If a deviation row is open, the corrigendum edit is allowed, with the original preserved by strikethrough rather than overwritten. There is no `--force`, no environment variable, no mode file: disabling the gate means editing or deleting the hook itself, which leaves a trace in the operator's own history. A second gate covers long runs, and it was built from a specific incident rather than a principle. Training runs in the source system hold the model in passive monitoring for days at a stretch, three, four, sometimes five, and every return from that idle is in effect a cold start. On one such run, an instance came up out of a cold restart in response to an alert and corrupted a live experiment, acting on what it remembered of the run rather than on what the files said. That incident is the main reason this gate exists; codifying the resume discipline so it is repeatable and enforceable is the rest. While an experiment is RUNNING, any experiment-touching build or edit call is blocked until both the pre-registration and the deviation ledger have been re-read in the current session, and the check is mechanical: the hook scans the session's own transcript for those reads rather than asking the model whether it remembers them. A multi-day experiment resumes from the files, never from memory. That is the series' truth-not-memory rule as a mechanism. ### 4. Two planes of integrity ![Two independent planes of integrity, checked by the same hash.](https://137900913-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fxx2bv6VR9dSJDJ9HsDER%2Fuploads%2FRgJky5R9W53MQQSv2SzA%2Fmethodseal-explainer-planes.png?alt=media) ***Figure 3.** The chain of custody. The local plane freezes the methodology on the operator's disk before and through the run; the external plane freezes the record at upload on infrastructure the operator does not control. Each plane closes the other's blind spot, and the same hash checks both.* A hash proves the methodology did not change; it cannot prove when the methodology existed. Third-party timestamping closes that gap: the sealed pre-registration is registered on public research infrastructure at seal time, before the run, so the order of events is attested by someone other than the author. The released package documents this as an optional integration, and this record's own experiments use it. ### 5. Built against documented failure MethodSeal was not designed from principle and then defended with anecdotes. Its spec opens with five failure classes, each a dated incident from this record's own history: a symbolic hash carried across some twenty documents without ever being computed; a hash written that had never existed; a seal marker that collided with its own prose mention; a status stamped outside its document's declared schema; and a handoff authored under saturation that carried an unverified claim forward as ground truth. Every design choice in the gate answers one of them, and the spec says which. The model of the discipline working is equally concrete. In one published run, a schema collision between pre-registration and validator was caught mid-run, logged, and the validator was not patched: the run closed against the sealed thresholds, with the mismatch on the record. A non-pre-registered workflow would have silently patched the validator, re-run, and reported a clean win. The discipline is the finding. ### 6. Design properties **Fail-open by design.** On any parse error, unreadable registry, or timeout, the hook allows the call. A missed enforcement beats a deadlocked session; the package states plainly that it is a discipline enforcer, not a security boundary against an adversary with filesystem access. **Dormant until armed.** With no active experiment registered, the hook has no opinion and normal work is untouched. Registration at seal time is the operator's explicit opt-in. **The files are the state machine.** Registry, marker, ledger, and decisions log hold the experiment's state, never the model's memory. That is what survives compaction and week-long runs. **Author-only.** Sealing, running, deviation-logging, and final-sealing are never delegated to sub-agents: an agent's unverified claim about a sealed hash is the exact failure the discipline exists to prevent. **Universal by construction.** The enforcement inspects the tool call, not the reasoning, so any model over any runtime that can run a command before a tool call executes can enforce it, and the lifecycle fits any field with a methodology worth freezing: a wet-lab protocol, a user study, a materials test, a backtest. ### 7. The release Version 1.0.0 was published 2026-07-25 under MIT, seventeen files plus an integrity manifest, with the canonical home and DOI at [doi.org/10.17605/OSF.IO/H64GM](https://doi.org/10.17605/OSF.IO/H64GM). The manifest's own SHA-256 travels with the release announcement so a mutated copy is detectable from outside the archive: ``` SHA256SUMS own hash a371bdab9155c63131e2c906374fce0533e28b0c7bb3837d14e1f7837b69adff ``` Verification is a one-command check on any platform, and the seal algorithm is fully specified in the shipped documentation, so any seal can be re-derived with a text editor and a hash utility, no tooling from the package required. Verify, don't trust; the package applies that rule to itself. Two compatibility contracts govern the version number: any change that alters a computed hash is a major release, and any state-schema change an older hook cannot read is a major release. Provenance is continuous: the release derives from the live implementation with ecosystem-internal references removed and no change to enforcement logic or the hash algorithm, executed and verified on a clean target machine before publication. An independent usefulness assessment scored the release 89.79, loaded on utility, innovation, and timing, in its first week ([HackerNoon coverage](https://hackernoon.com/methodseal-earns-an-8979-proof-of-usefulness-score-for-enforcing-reproducible-experiments)). ### 8. Where it sits in the series The stack enforces many workflows with the same pattern this package enforces one with: a skill that codifies, a hook that denies, files that carry the state. *Sovereign Safety Architecture* (Chapter 3) specifies that pattern fleet-wide; MethodSeal is its experiment-class member, small enough to read in an afternoon and complete enough to run. The failure classes it hardens against are the record's own, catalogued in *The Drift Taxonomy* (Chapter 9) and narrated in *The Guard Changes* (Chapter 10). The keystone, *The Why*, argues that a capable model is governed by comprehension held in the moment and by mechanical boundaries it cannot reach, and by nothing softer; MethodSeal is the smallest complete demonstration of the second half of that sentence, and the seals on every experiment in this record are the first half practiced daily. It is also the record's open door. Every other artifact here is evidence to be read; this one is a mechanism to be run. A reader who wants to test the thesis does not have to take the telemetry's word for it: install the gate, seal an experiment, and try to patch the validator. ### Pointers **Get it:** DOI [10.17605/OSF.IO/H64GM](https://doi.org/10.17605/OSF.IO/H64GM), the canonical archive with the versioned release, the loose integrity manifest, and the browsable documentation and example. **The pattern fleet-wide:** *Sovereign Safety Architecture* (Chapter 3), the deterministic gate at the tool-call boundary; *The Hook Telemetry Record* (Chapter 11), the gates firing in production. **The failure record it answers:** *The Drift Taxonomy* (Chapter 9) · *The Guard Changes* (Chapter 10) · Appendix A, the raw cascade catalogue. **The discipline this record is kept under:** *How to read this record*, front matter, on seals, tiers, and versions.