# Fresh Consistency Analysis: Installer Release Architecture

**Run date**: 2026-07-14  
**Scope**: `spec.md`, `plan.md`, `research.md`, `data-model.md`, `quickstart.md`, `tasks.md`, constitution,
installer artifact contract, and observed repository installer/offline documentation.  
**Result**: **CONSISTENT; GATE 1 PASS; GATE 2 IMPLEMENTATION/EVIDENCE IN PROGRESS; NO RELEASE ARTIFACT**

## Consistent Decisions

- The product taxonomy consistently keeps Workstation separate from Server S/M/L/Max and preserves
  compatibility slugs `starter/basic/pro/max`.
- The agreed four bootable products, Workstation-first order, separate large-model packs, and shared
  offline update format are now normative and do not require a separate feature spec.
- Zero-network acceptance, fail-closed integrity, durable operations, recovery evidence, and artifact
  provenance align with the constitution's lifecycle, entitlement, and evidence principles.
- The existing broad three-phase customer-experience rollout and the packaging workstream can coexist:
  packaging is cross-cutting and has independent artifact gates.

## Contradictions Requiring Correction During Implementation

| ID | Evidence | Contradiction | Required resolution |
|---|---|---|---|
| C1 | `autoinstall/offline/README.md` names `build-iso-offline.sh`; repository inventory lacks it | Documented build stage has no current build path | Implement only after approval, or change the referenced path when the design is selected |
| C2 | Offline directory describes “Server Payload” and script comments say “Server Starter”; README and variables describe Workstation | First implementation category is ambiguous in current runtime material | Rename/split runtime material during implementation and bind manifest category to `workstation` |
| C3 | README says ISO signature/integrity; current bundle builder writes SHA-256 only and asks for later signing | Current foundation does not enforce signature verification before mutation | Define manifest/signature tooling and trust policy before calling any artifact offline |
| C4 | Current builder fetches mutable install scripts/tags and records some digests after pull | Reproducibility and immutable input requirements are not yet met | Pin URLs by digest/version, images by digest, models by immutable revision, and record verified sources |
| C5 | `autoinstall/cezen-ai-ubuntu2204.iso` is 0 bytes | Repository artifact cannot be booted, verified, sized or called current | Replace only through an authorized reproducible build and record real artifact evidence |
| C6 | Server M/L/Max playbooks currently use the same role set; large models are now separate packs | Current source does not prove a materially distinct L/Max boot payload | Approve a support/validation/runtime distinction or reconsider duplication during implementation planning |
| C7 | NVIDIA role installs driver 550/CUDA 12.4; Starter declares CUDA 12.6; vLLM 0.10.2 uses CUDA 12.8.1; approved profiles include Blackwell | Current runtime declarations are mutually inconsistent and driver 550/CUDA 12.4 cannot cover the approved Blackwell-capable matrix | Approve `workstation-runtime-compatibility-baseline.md`, resolve exact R570/CUDA 12.8.1-compatible locks, then validate every physical profile and rollback path |

## Downstream Gaps and Readiness Blockers

The governing architecture choices are approved. These gaps are allocated to Gates 2-6 in
`gate-evidence-allocation.md` and remain real blockers at those downstream gates.

| ID | Severity | Blocker |
|---|---|---|
| B1 | Critical | `contracts/release-signing-trust.md` now defines separate release/license/test trust domains, purpose-constrained root/subordinate roles, separation of duties, dual-controlled offline custody, digest-bound signing receipts, rotation/expiry, monotonic offline trust distribution, revocation behavior, compromised-root recovery and acceptance vectors. Named owners, approved hardware/custody/backup, lifetimes/overlap, maximum revocation age, disconnected time policy, field root-recovery design, emergency authority and executed ceremony evidence remain outstanding. |
| B2 | Critical | Draft schemas, canonicalization, deterministic compatibility evaluation, all artifact-type examples and Ed25519 signatures, negative vectors, and passing automated Draft 2020-12/signature/compatibility evidence now exist. Technical fixture work is complete; security/platform approval remains outstanding. |
| B3 | Critical | Workstation is universal and hardware-adaptive within each CPU architecture; AMD64 scope/profile classes and later separate ARM64 identity are approved. `contracts/workstation-runtime-compatibility-baseline.md` now proposes an R570 (at least 570.124.06)/CUDA 12.8.1-compatible baseline because current driver 550/CUDA 12.4/CUDA 12.6/vLLM 12.8.1 declarations conflict. Exact physical machines, kernel/package/image/environment locks, model file inventory, redistribution approval and executed compatibility/rollback evidence remain outstanding. |
| B4 | Critical | `contracts/online-universal-acquisition.md` now defines endpoint classes, TLS/auth, signed index/manifest acquisition, cache/resume, failure recovery, and evidence gates. Production hostnames/owners, credentials, mirrors, proxy/customer-CA, retry/cache values, and approval remain outstanding. Current mutable default-branch clone remains contradictory legacy behavior. |
| B5 | High | `contracts/update-rollback-policy.md` now defines update classes, ownership, ordering, current/last-known-good retention, checkpoint scope, atomic activation target, ten-minute validation proposal, interruption and rollback outcomes. Actual switch/snapshot mechanisms, full backup inventory/SLA, supported prior versions, disk quota, driver/kernel recovery, and owner approval remain outstanding. Current data-only ZIP is explicitly insufficient as complete platform rollback. |
| B6 | High | `contracts/offline-license-policy.md` now defines offline import/activation, explicit staging, clock confidence/rollback, expiry continuity, binding/rehost, revocation/trust updates, interruption and evidence. Staging/expiry matrices, clock tolerance, device identity, rehost authority, revocation ages and owner approval remain. Current optional machine-ID enforcement and `basic` staging compatibility default are explicit implementation blockers. |
| B7 | High | `contracts/payload-inventory-sizing.md` now defines four-artifact boundaries, candidate inputs, role matrix, exact-digest deduplication, sizing worksheet, capacity arithmetic and evidence gates. Immutable resolved object inventories/build measurements are still absent; Server offline sizes remain unpublished and L/Max split justification remains open. |
| B8 | High | `contracts/offline-validation-lab.md` now defines isolation topology, packet-attempt detection, physical hardware matrix, clean/interruption/negative runs, evidence package, separation of duties and stop/retry rules. Named staff, exact machines/lab topology, approved tools, schedule, evidence storage and owner assignment remain outstanding. |
| B9 | Medium | `contracts/release-lifecycle-provenance.md` now proposes semantic versions, canonical filenames/identity, channels, SPDX 3.0.1 SBOM, in-toto Attestation Framework v1.2 Statement v1 with SLSA Provenance v1 (SLSA spec v1.2), reproducibility classes, retention, support/cadence and withdrawal. Toolchain, publication/archive locations, final periods/windows/cadence and named owner approval remain outstanding. |
| B10 | Medium | `contracts/model-pack-lifecycle.md` now defines bounded non-executable quarantine, malicious/partial import rejection, exact-digest object sharing, signed dependencies, atomic activation, uninstall/data preservation, reference-safe garbage collection, entitlement and redistribution-license changes, interruption tests and Gate 5 reconciliation. Store/transaction mechanisms, quotas/retention, customer-data rules, continuity/rehost policy, withdrawal/GC authority, named owners and executed evidence remain outstanding. |
| B11 | Critical | `contracts/installer-threat-model.md` now defines protected assets, adversaries, trust boundaries, eighteen threat/control cases, state invariants, abuse/interruption evidence and residual risks across source, build, signing, distribution, install, activation, recovery and evidence export. Owner acceptance, residual-risk assignment and linked executed control evidence remain outstanding; Secure Boot/firmware/TPM, build isolation, root/admin, disk encryption, evidence-signing and physical custody choices remain open. |

## Next-Step Remediation Completed

`contracts/architecture-decisions.md` records repository-derived defaults and separates them from
decisions requiring named Cezen approval. Draft JSON Schemas now cover the shared artifact manifest
and detached signature envelope. These drafts reduce B2/B3 ambiguity but do not close the gates until
owners approve them and immutable test vectors/payload revisions exist.

The next technical pass removed a circular self-digest from the manifest schema: the canonical
manifest digest belongs only in its detached signature envelope. `compatibility-evaluation.md` now
defines fail-closed evaluation order and stable reason codes, with non-production structural and
compatibility fixtures under `contracts/test-vectors/`. Cryptographic approval remains blocked until
a dedicated test key and real signatures are created under approved key-handling policy.

The B3 evidence pass verified immutable candidate pins for both Ollama starter models and the Hugging
Face Phi-3 snapshot, plus vendor hardware facts. It also surfaced a release-architecture contradiction:
the singular AMD64 Workstation ISO cannot also boot ARM64 DGX Spark. Following product clarification,
`contracts/workstation-hardware-model-baseline.md` now requires one universal hardware-adaptive ISO
per CPU architecture: the AMD64 artifact spans CPU-only and low/mid/high GPU classes, while a later
ARM64 artifact may cover DGX Spark under the same customer-facing Workstation category.

## Readiness Decision

The architecture is coherent and every Gate 1 requirement is approved. The closure audit in
`analysis/gate-evidence-allocation.md` records **Gate 1 PASS**. Subsequent explicit user authorization
permitted isolated Gate 2 resolver, verification, checkpoint and disposable-install evidence, but did
not authorize a release artifact, commit, push or deployment. Gate 2 remains blocked by operational,
immutable-inventory, mechanism, operator,
lab and evidence-storage items. Offline Workstation MUST remain the only first implementation candidate.
Offline Server S/M and L/Max remain planning-only until a real Workstation artifact passes the shared
zero-network, signature, update/model, interruption, rollback, and evidence gates. No ISO can be
called offline from the current repository material alone.

Gate 2 resolver evidence initially appeared to expose a bcrypt/Chroma contradiction, but fresh repo
inspection proved that the backend, Chroma and platform dependencies are installed into separate
virtual environments and wheelhouses. The corrected resolver preserved those boundaries and produced
363 measured wheel objects without changing either constraint. It also exposed the actual readiness
blocker: unpinned platform requirements currently select CUDA 13 Python components, conflicting with
the approved CUDA 12.8.1 runtime baseline. The candidate cannot be reviewed until that ML stack is
explicitly pinned and its three environments pass offline installation/import and license evidence.

Resolver increment 002 removes that version-selection contradiction using the exact dependency pins
embedded in vLLM 0.10.2: Torch 2.8.0, Torchaudio 2.8.0 and Torchvision 0.23.0. The fresh candidate has
no explicitly CUDA-13-named objects and 14 explicitly CUDA-12-named objects. This is not yet runtime
acceptance: physical R570/CUDA 12.8.1 testing, disconnected Python 3.11 install/import, license review,
and proof that the CPU-only profile does not require NVIDIA packages remain Gate 2 blockers.

Disconnected Python 3.11 validation subsequently passed for all three wheelhouses using a
digest-pinned validator container, `--network none` and `pip --no-index`. CPU execution passed with
CUDA hidden; a supplemental RTX 3050/Open Driver 595.58.03 test also executed CUDA 12.8 tensor work.
This narrows but does not close Gate 2: the 8 GB test is not the exact R570 reference or the 24/48 GB
matrix, and carrying CUDA wheels is not proof that CPU-profile installation excludes NVIDIA runtime
dependencies. License/provenance review and bare-metal/interruption/model-serving evidence remain open.

Profile-selection increment 001 closes the Python CPU payload-boundary ambiguity: the universal AMD64
medium carries profile alternatives, while installation selects exactly one. A strict 196-wheel CPU
selection contains no NVIDIA/CUDA/Triton/bitsandbytes objects and passed disconnected installation as
Torch `2.8.0+cpu` with no compiled CUDA runtime. The machine-readable selector and validator fail
closed on missing, altered or forbidden wheels. Installer integration, signed membership, detection,
journal/resume/rollback and tamper/interruption tests remain open and are allocated to T143.

Planner increment 001 now makes those state transitions deterministic without wiring them into the
installer. Six planner tests and build-host vectors prove safe CPU fallback, fully-ready NVIDIA
selection, same-profile resume and rollback-required profile changes. This is structural evidence only:
the test receipt is not cryptographically verified, and no atomic journal, checkpoint, installer
mutation, power-loss recovery or production signature-verifier integration exists yet. T143 remains
open; the planner prevents later wiring from inventing different state semantics.

Receipt increment 001 closes the unsafe bare-boolean handoff in the structural planner. A closed schema
now binds the manifest/envelope, key, trust snapshot, policy, namespace, profiles, time and verifier
build, and test receipts are forbidden by default. This is still not production signature evidence:
no production verifier, trust-policy evaluation, key ceremony or durable atomic journal/checkpoint
writer exists. Those blockers are explicitly allocated to T146 before T143 installer integration.

Atomic-journal increment 001 now implements the persistence mechanism and rejects stale writers,
altered records, identity changes, missing checkpoints and invalid transitions. Build-host vectors
reached `installing` only after a recorded checkpoint and retained mode `0600` plus digest linkage.
T146 is still open because a recorded checkpoint ID is not checkpoint creation/verification,
filesystem power loss has not been injected, and production Ed25519/trust-policy verification is not
implemented.

Ed25519 verifier increment 001 implements the cryptographic and structural handoff using OpenSSL and
passes positive/tamper/environment tests on Ubuntu with ephemeral test keys. It does not close T146:
there is no production key ceremony, approved trust snapshot, revocation/time-policy evaluation,
locked verifier/OpenSSL build, or independently approved production signature. The implementation is
ready for those inputs without treating test-key success as release evidence.

Checkpoint increment 001 now creates, verifies and restores hashed Python-environment snapshots and
handles originally absent targets without silent deletion. The build-host disposable vector restored
the original bytes exactly. Forced-process crash vectors now also prove that no partial checkpoint is
accepted, a published checkpoint verifies, interrupted restore completes from preserved quarantine,
and post-activation retry is idempotent. T146/T143 remain open because physical power loss,
disk-full tests, real target metadata coverage, orchestration and production trust inputs are absent.

Pre-mutation orchestration increment 001 connects the previously isolated components through durable
`checkpoint_ready` and proves idempotent re-entry with no package mutation. Remaining orchestration
starts at the mutation boundary: offline install, health validation, installed/rollback transitions,
service integration, real paths and production verification receipts remain unproved.

Disposable installation increment 001 crosses the Python mutation boundary for the strict CPU profile:
network-disabled install, pre/post activation health, fsynced atomic activation and final `installed`
state pass; offline dependency failure records rollback without changing the original target. This does
not close Gate 2 because NVIDIA execution, service integration, real paths/metadata, forced failure
after activation, reboot resume and bare-metal zero-network acceptance remain open.

Post-activation rollback increment 001 now proves the disposable CPU executor can recover from process
death after activation but before post-health/final journal commit. Exact checkpoint restoration,
failed-environment quarantine and terminal rollback all pass. Reboot/power-loss recovery, service-level
health, disk exhaustion, NVIDIA rollback and live installer integration remain blockers.

Disposable NVIDIA installation increment 001 proves the complete cu128 Python environment can install
and execute CUDA 12.8 tensors on the 8 GB RTX 3050 under Open Driver 595.58.03. It narrows the GPU gap
but does not satisfy the exact R570 reference, 24/48 GB matrix, vLLM/model-serving, NVIDIA rollback,
reboot recovery or bare-metal acceptance requirements.

`analysis/gate-1-decision-dossier.md` is now the consolidated approval surface. Its fresh count is
**30/30 mandatory architecture decisions approved; Gate 1 PASS; downstream evidence incomplete**. Cezen Technologies record `CT-G1-2026-001` approves G1-12
(AMD64 universal adaptive first-release direction with NVIDIA acceleration, CPU fallback and AMD GPU/
ROCm/Strix Halo acceleration excluded) and G1-17 (DGX Spark/ARM64 deferred to a separately evidenced
later build identity). G1-13's profile matrix is separately approved but lacks physical evidence.
G1-14 is approved under `CT-G1-2026-007` for Ubuntu 22.04.5 AMD64, R570 open driver at least
570.124.06, CUDA 12.8.1, vLLM 0.10.2 by immutable OCI digest and NVIDIA-independent CPU behavior;
exact locks and physical/rollback evidence remain open. G1-15 is approved under `CT-G1-2026-008` for
the pinned Phi-3 Mini Ollama manifest/layer, Nomic Embed Text v1.5 manifest and Microsoft Phi-3 Mini
commit with their recorded licenses and hardware boundary; packaged file/digest/notice and
redistribution evidence remain open. G1-16's Offline Workstation inclusion/exclusion boundary is
approved under `CT-G1-2026-009`; resolved signed object inventory, exact sizes/digests/licenses,
extracted-media reconciliation and measured capacity evidence remain open.
Existing schema/vector evidence and hardware/model
research are partial technical inputs, not approvals.
Cezen Technologies record `CT-G1-2026-002` additionally approves G1-08 through G1-11: the manifest/
signature schemas, deterministic default-deny compatibility, canonical naming/SBOM/provenance formats,
and immutable publication/withdrawal direction. Production tooling/sample-release evidence and exact
archive/access/retention values remain open.
Cezen Technologies record `CT-G1-2026-003` approves G1-01 through G1-07: separate trust domains,
offline-root/isolated-signer custody direction, rotation, monotonic revocation, compromised-root
recovery direction, TM-01–TM-18 controls and the requirement for a platform security baseline.
Concrete hardware/custody, timing values, recovery procedures, residual-risk assignments, exact
platform baseline and executed evidence remain open. Cezen Technologies record `CT-G1-2026-004`
approves G1-18 through G1-24: secure online endpoint/acquisition direction, scoped credentials and
resumable cache, staged/atomic update direction, last-known-good retention, explicit rollback classes,
restricted offline staging and binding/rehost/monotonic revocation. Production endpoints and numeric
operational values, exact mechanisms/runbooks and executed evidence remain open.
Cezen Technologies record `CT-G1-2026-005` approves G1-25 through G1-30: model quarantine/reference/
GC and customer-data preservation, the isolated lab and tamper-evident evidence methods, the complete
no-manual-repair acceptance inventory, and deferral of the Server L/Max split until Workstation evidence
proves a real distinction. Operational values, lab assignments and executed evidence remain open.
Cezen Technologies record `CT-G1-2026-006` approves the G1-13 representative profile matrix, but not
the existence or results of physical machines; exact CPU/GPU/RAM/storage, asset IDs, firmware and
availability remain evidence-open.
`gate-evidence-allocation.md` now separates Gate 1 approval evidence from Gates 2-6 execution evidence.

## Fresh Audit Pass 2

**Audit date**: 2026-07-14  
**Result**: **DOCUMENT SET INTERNALLY CONSISTENT; SUPERSEDED BY PASS 3 GATE ALLOCATION**

- All 12 checked-in JSON schemas/fixtures parse as JSON; the recorded full vector-suite evidence
  remains the technical result of record pending independent approval.
- Functional- and success-criterion identifiers have no duplicates; contract and analysis paths in
  the plan exist; Markdown whitespace validation passes.
- At Pass 2, C1-C6 remained repository/runtime contradictions; later explicitly authorized Gate 2
  increments changed the status of C2 and partially remediated C3/C4/C7 as recorded in Pass 4 below.
- Eight sizing rows contain 40 `TBD` markers in the measured payload worksheet. They are evidence
  holes, not unspecified behavior: T106 cannot resolve them without authorized immutable dependency
  resolution, artifact assembly and measurement.
- The signing decision package was aligned with the signing trust contract: the artifact signer is
  isolated from builders and is not described as an online build signer.
- There are 18 unchecked installer task lines. They are not 18 sequential documentation passes:
  most consolidate into the 30 decisions in the Gate 1 dossier, followed by evidence execution and
  a Gate 1 rerun. T083 is intentionally later, after Workstation passes Gates 1-5.

Pass 2 correctly blocked while decisions were open. All decisions are now approved; Pass 3 in
`gate-evidence-allocation.md` supersedes that result and allocates remaining evidence to Gates 2-6.

## Fresh Audit Pass 4 — Gate 2 Implementation Evidence

**Audit date**: 2026-07-14  
**Result**: **INTERNALLY CONSISTENT; GATE 2 NOT READY; OFFLINE WORKSTATION REMAINS THE ONLY BUILD CANDIDATE**

All specification JSON files parse, the current local deployment suite passes 36 tests with one
expected Mac OpenSSL/Ed25519 capability skip, shell/Python syntax and whitespace checks pass, and the
artifact directory remained empty in every recorded build-host increment.

### Contradiction Reconciliation

| ID | Pass 4 status | Evidence and remaining work |
|---|---|---|
| C1 | Open | `build-iso-offline.sh` is still referenced but absent. No lock-consuming media builder exists. |
| C2 | Resolved for the new path | New resolver, profile and evidence surfaces consistently identify Offline Workstation. Legacy Server material has not been promoted. |
| C3 | Partially remediated | Ed25519/profile receipt, fail-closed planner, journal/checkpoint and disposable mutation exist; production keys/trust policy and release-artifact signature enforcement do not. |
| C4 | Partially remediated | Source, OCI manifests, APT closure and Python wheels have candidate locks. Ubuntu media, runtime archives, OCI exported bytes, models, repository/index provenance and licenses remain unresolved. |
| C5 | Open | The checked-in ISO remains zero bytes; no bootable artifact exists or is claimed. |
| C6 | Deferred | Server L/Max material distinction remains intentionally deferred until Workstation passes its gates. |
| C7 | Partially remediated | Python uses the vLLM-aligned Torch 2.8.0/CUDA 12.8 split and CPU-only alternative. The production NVIDIA Ansible/package path still declares legacy driver/CUDA behavior and the exact R570 matrix is unproved. |

### Gate 2 Readiness Blockers

1. Candidate payload lock resolution 004 is not reviewed/signed and still lacks complete Ubuntu,
   runtime, model and measured container objects.
2. APT/Python/OCI index provenance, licenses/notices and redistribution approval remain incomplete;
   49 Python license fields require review.
3. Production release keys, trust snapshot, revocation/time rules, verifier/OpenSSL build locks and
   independent signing evidence do not exist.
4. Exact R570 validation plus 24 GB and 48 GB-or-higher physical profiles remain absent; RTX 3050/
   driver 595 evidence is supplemental `gpu-lite` coverage only.
5. No lock-driven acquisition/assembly path or bootable Offline Workstation ISO exists; the legacy
   mutable builder remains intentionally unreachable.
6. Sudden-power-loss recovery, post-activation or recovery-reserve exhaustion, production service-stack
   health, real ownership/ACL/xattr behavior and bare-metal zero-network acceptance remain unproved.
   Controlled OS-reboot and pre-activation target byte/inode exhaustion are proven only for disposable
   strict-CPU vectors; an external post-activation service-probe rollback is also proven only in
   disposable staging.
7. Named lab/operators, restricted evidence store, retention and independent approval remain open.
8. The payload-sizing worksheet still has eight unmeasured rows (40 `TBD` markers); media capacity and
   extracted peak/rollback space cannot be approved before real assembly evidence.
9. The checked-in real service graph is incomplete: `cezen-api.service` orders after Ollama without
   requiring it, omits ChromaDB dependency/ordering, and no production proxy dependency or consecutive
   semantic-health window is wired to rollback. T163 proves only an isolated mock graph; T164 provides
   structurally validated candidate definitions but does not replace or validate the real units.
10. T165 supplies deterministic health-window implementation and disconnected loopback evidence, but
    no signed production health profile, approved timing, real Nexus semantic endpoint matrix or
    production unit installation/security evidence exists.

Gate 2 therefore remains **NOT READY**. The next implementation evidence may continue on Offline
Workstation, but Offline Server S/M and L/Max and all release/build claims remain blocked.

Operator-flow remediation T156 removes the misleading executable build sequence from the offline
README. It now identifies every current tool as candidate-resolution, structural/disposable evidence,
available fail-closed validation, or blocked/absent assembly. C1 remains openly documented rather than
being implied complete by instructions that referenced a nonexistent script.

NVIDIA rollback increment T158 closes the disposable 8 GB Python post-activation process-crash case:
checkpoint restoration, executable failed-environment quarantine and terminal rollback pass. The
remaining NVIDIA blockers are reboot/physical-power recovery, exact R570 and 24/48 GB hardware,
vLLM/service/model health, real paths/metadata and bare-metal zero-network installation.

Boot-dispatcher increment T159 closes the narrower fresh-process recovery wiring gap for the strict
CPU profile: a distinct offline container recovered a generation-3 `installing` journal to generation
5 `rolled_back`, restored the checkpoint, retained the activated environment and no-op'd on a second
terminal invocation. This is consistent with the interruption contract but does not change the Gate 2
decision: actual OS reboot and sudden-power-loss durability, production boot ordering, real filesystem
metadata, capacity exhaustion and service health remained unproved at T159; T160/T161 narrow those
gaps below.

The post-T159 synchronized build-host suite passes 29 tests with no skips and zero artifact entries.
This refresh does not alter any open contradiction or readiness blocker.

Controlled-reboot increment T160 closes the disposable strict-CPU OS-reboot recovery gap. It also
proved persistent static networking at `172.16.10.144/24`. An initial exact-path mismatch failed
closed before restore; a fresh mount-consistent vector then recovered during boot to generation 5
`rolled_back`. The temporary boot unit was removed. Gate 2 remains not ready because physical power
loss, production unit packaging/order, live paths and metadata, capacity exhaustion, service/model
health and bare-metal zero-network installation remained unproved at T160; T161 narrows target
pre-activation exhaustion below.

Capacity increment T161 closes pre-activation target byte and inode exhaustion for disposable
strict-CPU installs. The vectors independently constrained the executable target to 128 MiB and 2,000
inodes, produced real `ENOSPC`, preserved the original target and reached generation 5 `rolled_back`
using separately reserved journal/checkpoint capacity. Gate 2 remains not ready: production capacity
reservation/preflight, reserved-state exhaustion, post-activation exhaustion, live metadata and
service-level rollback are still open.

Service-health increment T162 closes the generic external-probe failure path after strict-CPU atomic
activation: the probe observed the new environment, exited `23`, and exact checkpoint rollback plus
quarantine and generation-5 terminal state passed. Gate 2 remains not ready because the probe is not
yet a locked production component and no real Nexus systemd/API/portal/model service dependency graph,
health window, live path metadata or traffic behavior has been validated.

The post-T162 synchronized build-host suite passes 31 tests with no skips and zero artifact entries.

Systemd increment T163 proves explicit dependency ordering, three consecutive semantic-health samples
and `OnFailure` rollback in a fully isolated four-service graph. A forced vector 503 restored the
checkpoint and quarantined the candidate at generation 5. All temporary units were removed. This does
not close production service readiness: the real unit graph and actual Nexus model/vector/API/proxy
health semantics remain unimplemented/unvalidated and are now an explicit Gate 2 blocker.

Candidate-unit increment T164 defines the corrected production dependency and rollback direction while
preserving nginx recovery/help access during API failure. `/tmp`-only systemd 249 structural validation
passes without candidate errors or cycles. Gate 2 remains not ready: the health-window executable,
signing/locking, category-specific graph generation, real executables/nginx, approved timing, actual
restart/timeout behavior and production security analysis are absent, and current Ansible units remain
unchanged.

Health-window increment T165 closes the isolated validator behavior for ready, explicitly allowed
optional degradation, timeout, malformed JSON and HTTP-503 rejection. Rejection exit 23 now matches the
candidate systemd `OnFailure` contract. Gate 2 remains not ready because profiles/tool/unit bytes are
unsigned candidates, the real service graph/endpoints and total health deadline are unproved, and no
production units have been installed or security-scored.

The post-T165 synchronized build-host suite passes 36 tests with no skips and zero artifact entries;
the updated candidate health unit also passes `/tmp`-only systemd 249 structural/cycle validation.

Deadline/storm increment T166 closes isolated monotonic total-window enforcement and pre-HTTP systemd
restart-ceiling behavior. Real temporary units produced exit-23 `WINDOW_TIMEOUT` and `RESTART_STORM`
evidence, and were removed afterward. Gate 2 remains not ready: production timing/restart limits are
unsigned/unapproved, restart baseline/reset semantics and real-unit storms are unproved, and these
failure codes have not yet been chained through the candidate rollback unit in one transaction.

The post-T166 synchronized build-host suite passes 38 tests with no skips and zero artifact entries;
the deadline-aware candidate unit also passes `/tmp`-only systemd 249 structural/cycle validation.