Hiro development journal

Designing fail-closed boundaries for Hiro Stage 6

2026.08.04 at 11:04:15 America/Los_Angeles Validated and published Machine-readable JSON

Executive summary

Designed the authority, scope, evidence, rate, concurrency, monitoring, rollback, and kill-switch boundaries for a future narrow Stage 6 automatic-promotion process.

Stage 6 was not enabled. The machine-readable policy is intentionally marked draft_disabled with enabled false, and Hiro's authoritative auto-promote setting remains false.

The first future mutation level is restricted to adding at most two small non-runtime evidence files. Existing-file changes, runtime code, prompts, configuration, evaluators, services, schedulers, permissions, external actions, and restarts remain ineligible.

Activation requires a new user-bound policy approval after a shadow benchmark of at least 30 decisions with 100 percent classification accuracy and zero false allows, plus interruption and rollback drills.

Six focused policy-contract tests and all 291 repository tests passed. No active branch, service, schedule, evaluation result, or runtime behavior was changed.

Work completed

Authority and activation boundary

Designed; disabled

Defined a three-level ladder: shadow decisions with no mutation, a future evidence-only mutation level, and a later designated runtime fragment that is not yet designed or allowed.
Required a versioned immutable user enablement packet bound to repository, branch, policy identifier and hash, authority level, expiration no longer than seven days, promotion count, and the approving interaction.
Specified that the legacy low-risk integration flag is not Stage 6 authorization and that starting Hiro, Daylab, or nightly evaluation cannot activate Stage 6.
Required both an exact environment opt-in and an external persistent disable sentinel, checked repeatedly through the transaction and probation window.

Initial mutation allowlist

Designed; inactive

Limited a future v1 promotion to at most two new UTF-8 text files, 16 KiB and 120 added lines total, with no modification, deletion, rename, mode change, symlink, submodule, binary, or executable content.
Allowed only documentation evidence notes, passing deterministic regression captures, and quarantined benchmark candidates in dedicated opportunity-key directories.
Kept benchmark candidates outside all scored suites until a later human-reviewed admission decision, preventing a candidate from manufacturing its own favorable evidence.
Excluded runtime code, prompts, model settings, context limits, evaluator and ledger controls, configuration, authentication, tools, memory policy, schedulers, services, dependencies, databases, external writes, and service restarts.

Evidence and transaction integrity

Designed

Required mutually matching frozen packets from opportunity selection through isolated integration and monitoring, with the candidate base exactly equal to current active HEAD.
Specified a clean repository, no in-progress Git operation, one atomic global lease, an immutable pre-promotion reference, a fresh external worktree, and full tests before any active-branch mutation.
Allowed only a fast-forward to an already verified integration revision; prohibited merge commits, force updates, rebases, automatic conflict resolution, and automatic candidate repairs.
Required append-only transition events and idempotent recovery so an uncertain restart inspects Git and ledger state instead of applying a candidate twice.

Canary, probation, and rollback boundary

Designed

Defined a five-minute immediate canary window and a 24-hour probation with checkpoints at promotion, 15 minutes, 60 minutes, 6 hours, and 24 hours.
Limited throughput to one promotion per rolling 24 hours and three per rolling seven days, with only one active promotion or rollback lease and no stacking during probation.
Defined fail-closed rollback triggers for identity or hash mismatch, policy or test failures, health/invariant failures, missing monitoring, material compatible error or latency regression, or either kill switch.
Required history-preserving Git revert, verification against the pre-promotion tree, full retesting, activation of the persistent disable sentinel, and emergency stop if rollback cannot be completed safely.

Machine-readable contract and consistency checks

Passed

Added a disabled draft JSON policy and focused tests that assert default-off authority, bounded allowlist, protected paths, strict rate and probation limits, history-preserving Git behavior, and the activation benchmark.
Reconciled the older transition plan, removing its broader prompt/config scope and two-repair allowance from the initial Stage 6 description.
Frozen an internal design record that explicitly reports Stage 6 disabled, zero active mutation authority, validation results, and the next shadow benchmark gate.

Decisions and reasoning

Treat the user's request as authorization to design boundaries, not to implement or activate automatic mutation.
Start with evidence-only, add-only artifacts because they can improve test diversity and durable learning without changing Hiro's runtime behavior or authority.
Do not permit a designated prompt or configuration fragment in v1. Such a fragment first needs a purpose-built data-only surface, schema validation, atomic hot reload, and proven rollback, followed by a new policy version and user approval.
Use zero automatic repair attempts at this stage. A rejected candidate needs a new identity and fresh evidence so the promotion engine cannot expand scope while trying to fix itself.
Treat unavailable, stale, ambiguous, mismatched, or corrupted state as rejection. Infrastructure and model failures remain separately classified and never count as successful promotion evidence.
Require an explicit user approval bound to the final policy hash after shadow benchmarking; successful Stage 5 graduation alone grants no Stage 6 mutation authority.

Validation and evidence

Check	Status	Result
Machine-readable policy parse	passed	The disabled Stage 6 draft parsed as valid JSON.
Focused Stage 6 design-contract suite	passed	6 tests passed in 0.89 seconds, covering default-off state, user-bound authority, dual kill switches, add-only non-runtime scope, rate and probation limits, history-preserving rollback, and the shadow activation benchmark.
Repository-wide regression suite	passed	291 tests passed in 136.77 seconds.
Bundled Python child-process startup	passed	Hiro's bundled Python executable started successfully and ran the focused and full suites.
Production authority boundary	passed	No active-branch mutation, service or schedule change, restart, deployment, external action, evaluation result change, or Stage 6 activation occurred.
Hiro journal tests and frontend build	passed	Timestamped-entry unit tests passed; the generator produced and validated 61 journal pages, and the TypeScript and Vite production build completed successfully.

Current state

The Stage 6 boundary contract and disabled machine-readable draft exist and agree with the transition plan.
Stage 6 automatic promotion remains disabled and has no implemented active-branch authority.
The next safe engineering step is a shadow-only engine that records allow and deny decisions without modifying Git or runtime state.
The eventual evidence-only level remains unavailable until the shadow benchmark, interruption tests, rollback drills, final policy review, and separate user activation approval are complete.

Next steps

Implement the Stage 6 policy evaluator, packet validator, lease model, and append-only decision record in shadow-only mode with active-branch mutation structurally unavailable.
Build at least 30 historical and adversarial replay cases covering every allowed class and path, traversal, links, binary and mode changes, stale or dirty state, packet tampering, rate limits, lease collision, and kill switches.
Exercise at least five interruption boundaries and three rollback drills, including one overlapping-state emergency stop, while verifying exact idempotent resume.
Review the measured false-allow and false-deny results and update the draft if necessary; require 100 percent decisions and zero false allows for activation consideration.
Ask the user for a separate explicit approval bound to the final policy hash before enabling even the evidence-only level.