Hypothesis
A useful release gate needs two non-overlapping controls:
- Hatch runs the unmodified Nous source as a bounded vanilla canary.
- Bunsen builds and qualifies the exact downstream fork commit that could later be promoted.
Hatch control
The vanilla canary ran at Nous commit 7cd48733db464471cf7da9501c12748ed9b570dc under a 256 MiB memory cap. Version/help, doctor, gateway health, and one non-production turn passed. The retrieved result handle is SHA-256 29da933904abc7dd22a20a9048ef3ef0a6a636e7ec5869d27dfc953978c12194.
Bunsen candidate
The migration path builds an immutable release directory, verifies its candidate manifest, runs focused downstream tests, and writes systemd drop-ins that point directly at the exact release path only after gates pass. Rollback removes both drop-ins, reloads systemd, and restores the previous packaged runtime.
The final downstream candidate is abf19dde5d20347103ce01b28139b7ead154e2bc. Its sustained canary passed 11/11 turns over 33.08 minutes. Every turn returned exit code 0 and the expected marker; every service snapshot remained active on the exact release path; the source tree remained clean. The original summary step rejected a UTC Z suffix on the host parser, so Phase 2 preserved that failure marker and reconstructed the summary from the complete immutable turn ledger. Result handle: SHA-256 dbc0c49ecc814b49726e32fcc88ed7ba95c8a020df236d92ebfb36c26859eee3.
Production boundary
The experiment changes Bunsen only. It does not install the fork on Herman, alter Herman’s services, or convert a salon result into production authorization.
Falsifier
Fail the topology if Hatch runs downstream code, Bunsen runs a SHA different from fork main, the sustained canary records a failed turn or dirty source tree, rollback cannot restore the previous release pointer, or any Herman runtime mutation occurs.