Files

4.7 KiB

Installer Evidence Gate Allocation

Audit date: 2026-07-14
Gate 1 result: PASS — architecture ready for detailed Offline Workstation implementation planning; implementation/build remains unauthorized in this docs-only task.

Gate 1 Closure Test

The normative gate definition in contracts/installer-artifact-contract.md requires the release matrix, payload boundaries, threat model, trust ownership, manifest schemas, compatibility rules, recovery matrix and test inventory to be approved. It does not require an ISO, measured payload, physical installation or executed update/model test; those are explicitly Gates 2-5.

Gate 1 requirement Evidence Result
Four-product matrix and Workstation-first boundary spec.md FR-030/FR-031; artifact contract; G1-12/G1-16/G1-17 Pass
Exact offline and payload boundaries FR-032/FR-033/FR-047-FR-049; payload contract; G1-16 Pass
Threat model installer-threat-model.md; TM-01-TM-18; G1-06/G1-07 Pass
Trust ownership and signing architecture release-signing-trust.md; G1-01-G1-05 Pass
Manifest/signature schemas Draft 2020-12 schemas and fixture evidence; G1-08 Pass
Compatibility rules compatibility-evaluation.md, reason codes/vectors; G1-09 Pass
Recovery/interruption matrix Installer, update, license and model contracts; G1-20-G1-26 Pass
Test inventory and evidence method offline-validation-lab.md, threat abuse set; G1-27-G1-29 Pass
Architecture approval record G1-01-G1-30 have CT-G1-2026-001 through CT-G1-2026-009 Pass

Gate 1 therefore passes. This design-gate result does not prove that current scripts, the zero-byte repository ISO, a future ISO, physical hardware or any production service conforms.

Downstream Evidence Allocation

Open item Correct gate Reason
Signing devices/custodians/operators, lifetimes, revocation age and recovery procedure Gate 2 Concrete operators and policy are implementation-readiness inputs
Secure Boot/firmware/disk-encryption/admin baseline Gate 2 The threat control is approved; exact platform policy precedes implementation
Kernel/driver/CUDA/toolkit/Ollama/Python/container locks Gate 2 Pinned payload inventory is the explicit Gate 2 requirement
Starter-model files, notices and redistribution record Gate 2 License mapping and immutable inventory precede assembly
Complete package/image/wheel/runtime/source inventory Gate 2 Explicit implementation-ready evidence
Online endpoint/credential/proxy/CA/retry/cache values Gate 2 for Online Universal Independent of first Offline Workstation planning
Update mechanisms, backup quota/SLA, health and recovery values Gate 2 Concrete mechanisms/operators must precede coding
License timing/binding/rehost values and authority Gate 2 Concrete policy and operators must precede coding
Model-store transaction/quota/data-retention values Gate 2 Concrete implementation and data policy
Lab people/assets/tools/schedule and evidence repository Gate 2 Required before artifact/physical evidence execution
Build, SBOM/provenance, signatures, digests and measured size Gate 3 Exists only for a built candidate artifact
Physical, zero-network, interruption and reboot results Gate 4 Explicit Offline-install-ready evidence
Update/model/tamper/rollback/revocation results Gate 5 Explicit Update/model-ready evidence
Source-to-artifact review, support runbook and release approval Gate 6 Explicit release-ready evidence
Server L/Max split justification After Workstation Gates 1-5 Server-offline planning is deferred

Repository Contradiction Allocation

Contradiction Blocking gate
C1 missing offline builder; C2 Workstation/Server ambiguity Gate 2 implementation design
C3 checksum-only foundation; C4 mutable inputs Gate 2 implementation and Gate 3 artifact evidence
C5 zero-byte checked-in ISO Gate 3; it is not a release artifact
C6 no distinct Server L/Max payload Deferred Server decision after Workstation Gates 1-5
C7 driver 550/CUDA 12.4 vs approved R570/CUDA 12.8.1 Gate 2 correction and Gate 4 validation

Authorization Boundary and Next Gate

The next formal target is Gate 2: Implementation-ready for Offline Workstation only. It requires the immutable payload/license inventory, concrete mechanisms/policy values, restricted operators, lab/evidence assignments and an implementation task plan that corrects C1-C4 and C7.

This audit does not expand authority. No installer code, dependency download, payload assembly, ISO build, physical test, commit, push, deploy or runtime modification is authorized. Those actions require a separate explicit scope expansion.