@@ -613,11 +613,13 @@ negative tests land while release qualification remains pending. The
 maintainer then:
 
 1. runs the engineering baseline on the two exact owned profiles;
-2. commits the canonical, redacted raw evidence under
-   `docs/validation/firmware/oi1/`;
-3. derives every profile threshold mechanically with the frozen formulas;
-4. commits the populated policy and its evidence SHA-256; and
-5. builds the final tagged candidate and reruns verify-mode HIL on both exact
+2. runs `assemble-oi1-baseline` against the immutable staged inputs and the
+   two bench fragments so the tool creates the canonical, redacted evidence
+   under `docs/validation/firmware/oi1/`, derives every threshold with the
+   frozen formulas, and atomically updates the policy with its evidence
+   SHA-256;
+3. reviews and commits those mechanically assembled files; and
+4. builds the final tagged candidate and reruns verify-mode HIL on both exact
    profiles.
 
 A policy has exactly two threshold-bearing profile entries and one deferred
@@ -632,6 +634,10 @@ matching baseline-evidence digest, and immutable build measurements in
 `PYBLE_HIL_RECORDS_V2`. Its runtime observation is pending. Finalization may
 fill observations, operator fields, and derived checks only; it must prove the
 policy and build portions remain byte/semantically equal to the candidate.
+The `assemble-hil-report` helper accepts only bounded per-profile mutable
+evidence, copies candidate-frozen fields from the pending report, derives the
+footprint/reliability pass from validated observations, and emits the completed
+V2 report atomically before finalization.
 
 The validator recomputes image/headroom arithmetic, sample counts, heap
 minima, latency maximum, goodput from recorded durations, threshold
 
@@ -1,9 +1,10 @@
 # PyBLE ESP32-Family Browser Flashing and Release Bundle
 
-Status: **FROZEN v1.26** · Owner: project maintainer · Frozen:
-2026-07-30 (`[docs]`; pre-v1 two-profile release eligibility and explicit
+Status: **FROZEN v1.27** · Owner: project maintainer · Frozen:
+2026-07-31 (`[docs]`; pre-v1 two-profile release eligibility and explicit
 C3 deferral; evidence-derived resource policy and exact HIL V2 records;
-pre-policy two-root baseline-input staging;
+pre-policy two-root baseline-input staging and mechanical baseline/policy
+assembly;
 exact-profile manifest, C3 silicon-revision,
 license-audit safety, candidate-finalization, and candidate pin-state
 amendments, plus the real-tool license-evidence and exact license-catalog
@@ -18,7 +19,8 @@ markers, generated-header inputs, and direct-object reconciliation, plus
 component-owned linked outputs, lexical exact-path validation, nested-build
 logical paths, shell-free compiler/linker command receipts, executable
 version-matched recovery-command syntax, and the canonical pre-v1 same-origin
-publication channel with an optional byte-identical mirror, on the same date)
+publication channel with an optional byte-identical mirror, plus bounded
+completed-HIL report assembly, on the same date)
 
 This document is the source of truth for the initial browser-provisioning
 release bundle. It refines
@@ -201,6 +203,30 @@ policy, baseline-evidence file, release tag, license evidence, or HIL approval.
 Its output is measurement input only: it is not a release candidate and MUST
 NOT be accepted by the website or public release validator.
 
+After both exact-profile baseline runs succeed, the release tool MUST provide
+an `assemble-oi1-baseline` operation. It accepts the immutable staged baseline
+input tree above, exactly two canonical single-profile fragments emitted by
+the OI-1 bench, the clean canonical PyBLE proof checkout, and one explicit UTC
+`created_at` value. It MUST derive `source_commit` from that checkout's exact
+`HEAD` and `firmware_version` from its `versions.lock`; operator-supplied
+substitutes for either identity are forbidden. Before writing, it MUST require
+the proof checkout to be clean, require exactly one fragment for each profile
+regardless of input order, validate every fragment and observation field,
+bind each fragment's firmware hash, manifest hash, and build measurements to
+the corresponding staged bytes, and mechanically derive all nine thresholds
+with the frozen formulas.
+
+The operation MUST canonicalize and create the baseline evidence at
+`docs/validation/firmware/oi1/<HEAD>.json`, compute the digest of those exact
+bytes, and atomically update `firmware/qualification/oi1-gates.json` with the
+exact frozen policy shape and derived thresholds. The baseline path is
+no-replace: an existing different file is fatal; an existing byte-identical
+file is an idempotent input. The policy update MUST be an atomic same-directory
+replacement, and both complete byte payloads MUST pass the production
+baseline/policy validator before either destination is changed. This operation
+is evidence assembly only; it does not approve a release or mutate staged
+measurement inputs.
+
 The protected candidate site's build-selected SHA-256 of `release.json` is the
 root identity of the candidate exercised during HIL. The completed HIL
 evidence MUST record that exact lowercase 64-hex digest. Public finalization
@@ -1246,6 +1272,28 @@ In a candidate every value is `pending`. In a public report every value is
 `passed`; `footprint_reliability` MUST be set by the validator only after the
 V2 observations pass, not accepted as independent operator testimony.
 
+The release tool MUST provide an `assemble-hil-report` operation so completing
+this contract never requires hand-editing `HIL_REPORT.md`. It accepts one
+immutable pending candidate, exactly two JSON completion fragments (one per
+profile, in either input order), the canonical qualification checkout, and one
+new no-replace output path. A completion fragment contains only the mutable
+profile ID, physical board descriptions/capacities, UTC test time,
+operator/sign-off and environment strings, the six operator-demonstration
+checks other than `footprint_reliability`, one completed `oi1_observation`, and
+the redacted console log. It MUST NOT accept status, release identity, artifact
+hashes, policy, or build measurements from an operator fragment.
+
+The assembler MUST validate the pending candidate first, compute the exact
+candidate `release.json` SHA-256 itself, copy every candidate-frozen field from
+the embedded pending records, require all six supplied checks to be `passed`,
+validate the observation and every profile threshold, and only then insert
+`footprint_reliability: passed` and `status: passed`. It MUST render exactly one
+canonical `PYBLE_HIL_RECORDS_V2` marker, validate the completed payload against
+the candidate bytes and committed policy, write the output atomically, and
+prove the candidate and completion-fragment inputs did not change during the
+operation. It never mutates the candidate and does not perform public bundle
+promotion; `finalize-public` remains the only promotion step.
+
 `oi1_observation` is JSON `null` in a pending candidate. In a completed report
 it is an object with exactly:
 
 
@@ -109,12 +109,26 @@ For the owned N16R8 S3, change the identity arguments to:
 
 Baseline output is deliberately one **profile fragment**, not a release
 approval and not a malformed one-profile substitute for the frozen
-two-profile baseline envelope. Retain both successful fragments and assemble
-them, in policy order, with the common source commit, firmware version, and
-UTC timestamp before committing the baseline evidence. The command prints the
-mechanically derived profile thresholds for review; those numbers do not
-become policy until the retained two-profile baseline and its digest are
-committed.
+two-profile baseline envelope. Retain both successful fragments, then assemble
+the envelope and policy without hand-editing JSON:
+
+```sh
+python3 ../../../firmware/scripts/release_bundle.py \
+  assemble-oi1-baseline \
+  <private>/oi1-inputs \
+  <private>/esp32-4mb-baseline-profile.json \
+  <private>/esp32-s3-n16r8-baseline-profile.json \
+  --repo-root ../../.. \
+  --created-at 2026-08-01T00:00:00Z
+```
+
+The helper obtains the common source commit and firmware version from the
+clean proof checkout, binds both fragments to the staged bytes, creates the
+canonical commit-scoped evidence file, and atomically updates
+`firmware/qualification/oi1-gates.json` with mechanically derived thresholds.
+Review and commit both generated files together. The individual bench command
+also prints its derived thresholds for review; neither fragment nor assembled
+baseline is release approval.
 
 After that policy exists, run the exact final candidate in verify mode:
 
@@ -146,6 +160,26 @@ release finalizer. It does not edit a policy, release bundle, or HIL report.
 Any workload, integrity, threshold, or physical-power-cycle failure exits
 non-zero without writing a successful observation.
 
+After all other protected-candidate checks pass, put each verify observation
+and that profile's bounded operator metadata/checks into one completion JSON
+fragment, then create the completed report without editing Markdown:
+
+```sh
+python3 ../../../firmware/scripts/release_bundle.py \
+  assemble-hil-report \
+  <private>/candidate-v0.4.2 \
+  <private>/esp32-4mb-hil-completion.json \
+  <private>/esp32-s3-n16r8-hil-completion.json \
+  <private>/completed-HIL_REPORT.md \
+  --qualification-repo-root ../../..
+```
+
+The completion fragment has only mutable board/operator/environment fields,
+six operator-demonstration checks (all `passed`), `oi1_observation`, and the
+redacted console log. The helper computes the selected candidate digest,
+copies every frozen identity/policy/build field, and derives the
+`footprint_reliability` pass only after validating the observation.
+
 The C3 profile is intentionally refused by the CLI. A source build or license
 audit for `esp32-c3-4mb` is not HIL evidence and cannot enable that profile.