Hiro development journal

Closure contract designed for Hiro's gap-free autonomous improvement workflow

2026.08.11 at 10:09:08 America/Los_Angeles Design and authorization-boundary review completed; implementation awaits explicit end-to-end authorization Machine-readable JSON

Executive summary

The autonomous improvement workflow was reviewed as one continuous operational system rather than as a set of individually completed components.

The principal failure pattern is premature completion: discovery, readiness, or approval has been treated as an endpoint even when no durable transition advances the item to the next stage.

A complete design now defines success as a restart-safe state machine from safe external idea through local corroboration, specification, candidate construction, evaluation, isolated integration, Stage 6 probation, and a retained or rolled-back terminal outcome.

Stage 6C has a separate one-time exact-policy activation boundary. Its current policy removes per-candidate user approval but still requires one explicit user activation for the checksum-bound runtime-fragment policy.

Work completed

End-to-end state machine

Designed

Every improvement receives one durable identity and an append-only history across discovered, corroborating, corroborated, specified, constructed, evaluated, integrated, probation, retained, rejected, rolled_back, and blocked states.
Each nonterminal state has an executable next transition, retry and timeout rules, an idempotency key, and a recorded reason when progress cannot continue.
Restart recovery resumes the last incomplete transition rather than creating a duplicate idea, candidate, or promotion.
The orchestrator considers work complete only at a retained, rejected, rolled-back, or explicitly blocked terminal state.

Local corroboration transition

Designed

Safe external themes are matched only against independent local evidence such as public evaluation failures, response envelopes, repeated errors, blocked-response classifications, or regression probes.
A progress-oriented default can accept one reproducible public-evaluation failure or multiple independent local observations, subject to freshness, scope, and negative-evidence checks.
The decision is frozen as a prompt-safe corroboration receipt linked to the external lineage identifier.
A passing receipt constructs a complete ImprovementSpec; insufficient evidence remains scheduled for reconsideration, while contradicted or stale ideas become explicit rejections.

Autonomous transition runner

Designed

One scheduler owns all due transitions and uses leases so overlapping polls cannot advance the same item twice.
The runner performs candidate construction, public and held-out evaluation, regression and latency gates, automatic isolated Stage 5 integration, and policy-controlled Stage 6 submission without stopping merely to report readiness.
Probation checkpoints and rollback are scheduled durably and resume after process or computer interruption.
Post-action reports summarize decisions and outcomes without becoming prerequisites for low-risk transitions.

Stage 6C activation boundary

Verified

The current Stage 6C policy is compiled default-off and checksum-bound.
It already specifies that per-candidate user approval is not required and that post-action reporting is required.
It also requires one explicit user activation, an exact policy hash, an expiring enablement packet, and the designated runtime environment flag.
Once explicitly activated, Stage 6C remains limited to one small schema-validated assistant-behavior fragment, with no arbitrary code, network action, external action, filesystem expansion, or service restart authority.

Operational acceptance criteria

Designed

Implementation is not complete when code compiles, tests pass, a packet is approved, or a campaign becomes ready.
Acceptance requires a live restart, scheduler health, recovery rehearsal, a synthetic end-to-end canary, and observation that at least one real lineage progresses or records a justified non-success terminal state.
The dashboard must expose current stage, next transition, due time, retry count, last blocker, and terminal outcome for every lineage.
A watchdog must identify nonterminal items with no due transition so future gaps become visible and fail loudly.

Decisions and reasoning

Define completion by an operational terminal outcome, not by readiness or component availability.
Use one state machine and transition runner instead of loosely connected periodic scripts.
Retain safety gates and structural isolation while removing unnecessary pauses for per-candidate user authorization.
Require the existing one-time explicit Stage 6C exact-policy activation because it changes live runtime authority.
Do not represent an external idea as implemented until its exact lineage reaches a retained outcome.

Validation and evidence

Check	Status	Result
Active improvement control-flow review	completed	The current runner performs discovery and sandbox evaluation in one cycle but lacks durable ownership of every subsequent lineage transition.
Stage 6C authorization review	completed	The exact policy requires one user activation, does not require per-candidate user approval, requires post-action reports, expires enablement within eight hours, and fails closed without its environment and packet bindings.
Implementation and runtime mutation	not performed	This session defined the closure contract and identified the required explicit authorization. No activation packet, runtime state, candidate, or live behavior change was created.

Current state

Hiro's external idea discovery and lineage display are active.
The automatic local-corroboration bridge is missing.
Approved or ready artifacts can still stop before the next operational transition.
Stage 6C readiness is complete, but its separate exact-policy activation remains inactive.
Per-candidate Stage 6C user approval is already disabled by policy; the remaining boundary is the one-time policy activation.

Next steps

Obtain one explicit instruction authorizing implementation of the complete state machine and exact activation of the current Stage 6C policy.
Implement the lineage-aware corroborator, transition ledger, scheduler, recovery logic, watchdog, and dashboard status fields.
Generate the checksum-bound Stage 6C enablement packet and configure the runtime flag for the policy's bounded validity window.
Run focused and full tests, restart Hiro, perform recovery and end-to-end canary validation, and monitor a real lineage until it advances or records a justified terminal decision.
Report the complete result after action rather than stopping at intermediate readiness states.