1. Overview
Linux distribution configured declaratively from plain-text files, with rollback to earlier system generations.
Category: OS & Infra.
2. Version and scope assessed
Version assessed: Pinned evidence 44d27ba452c1c4177882732bd48fabd7d332e38d.
3. Overall determination
Computing determination
4. Principle profile
| Order | Principle | Finding |
|---|---|---|
| I | Sovereignty | Not assessed |
| II | Longevity | Not assessed |
| III | Locality | ✓ Meets |
| IV | Transparency and Control | Not assessed |
5. Fundamental requirements
| Requirement | Status |
|---|---|
| E1 Independent access to essential information | ✓ Pass |
| E2 Practicable exit and migration | ? Not Verified |
| E3 Independent interpretation and recovery | ? Not Verified |
| E4 Continuing authority and custody over already-created work | ✓ Pass |
| E5 Governability of consequential actions | ? Not Verified |
6. Evidence and verification
- E1: NixOS configurations are declared in source files and each rebuild creates a system generation that can be inspected and selected. (source), confidence high
- E2: Configuration files can be copied to another machine and rebuilt, but package caches, secrets, hardware, and channel pinning affect portability. (source), confidence high
- E3: The previously unread state section explicitly requires persistent /nix including daemon database, roots and profiles, plus /boot and /var/lib/nixos for stable UID/GID allocation. With mutable users, passwd/group/shadow and subordinate-ID files must persist too. A configuration file alone is not that state backup. (source), confidence medium
- E4: System configuration and rollback are operator-controlled, with optional binary caches rather than a required provider. (source), confidence medium
- E5: The full rollback section distinguishes switching the running system from selecting a bootable generation and making it the boot default. Boot-menu recovery is limited to configurations not garbage-collected; rollback is not represented as reversing service/user data changes. (source), confidence medium
- sovereignty: A positive Sovereignty finding requires established E1, E2 and E4 in the declared scope. The existing access/exit/custody record for NixOS does not establish all three minimums. The prior positive finding is withdrawn; recorded storage and portability strengths remain facts, not a verified failure. (source), confidence medium
- longevity: E3 is not established for NixOS's existing essential-record scope. The previous Longevity finding is replaced by Not assessed, not a verified failure or a positive placeholder. (source), confidence medium
- locality: NixOS can build and operate locally, though remote caches are optional accelerators. (source), confidence medium
- transparency: The positive control observations above do not yet establish whole-scope E5. The methodology requires that minimum before a positive Transparency and Control finding; the previous positive finding is therefore withdrawn to Not assessed, not changed to Does not meet. (source), confidence medium
- E3: The retained state documentation explicitly requires persistent store/daemon/profile/root and boot/UID-allocation data, plus mutable account files where configured. A declarative configuration alone does not reconstruct services, secrets and closure inputs. No pinned offline complete state restoration is established. (source), confidence medium
- E5: Generation selection and running/boot-default rollback are distinct, and garbage collection can remove recovery generations. Service/user data are not rolled back by those mechanisms. Effective activation/GC authority, inspectable consequences and recourse for mutable-state changes remain insufficiently covered. (source), confidence medium
7. Migration and recovery
Native storage format: Declarative Nix configuration files.
Synchronization or runtime model: Nix store with pinned inputs; configuration kept in version control.
Example export or inspection command (not verified against any particular version or data set): nixos-rebuild build --flake .#workstation
8. Architectural strengths
Established strengths and their scope are recorded in the evidence and assessment findings on this page.
9. Architectural limitations
- Source/retained-input inspection only; no installation or application restore performed.
- Pinned-closure rebuilds, offline cache completeness, mutable service/secret restoration and actual rollback/GC trials remain open.
10. Assessment findings and remaining work
Verification scenario: Build from a pinned configuration on a clean or offline host using preseeded dependencies; test rollback, secrets, and state restoration.
What may invalidate an overconfident claim: Declarative system configuration does not automatically reproduce mutable user data.
Documentation starting point: https://nixos.org/manual/nixos/stable/
Evidence update: 23 October 2026
- Resolved: The previously unread state section explicitly requires persistent /nix including daemon database, roots and profiles, plus /boot and /var/lib/nixos for stable UID/GID allocation. With mutable users, passwd/group/shadow and subordinate-ID files must persist too. A configuration file alone is not that state backup. Source.
- Resolved: The full rollback section distinguishes switching the running system from selecting a bootable generation and making it the boot default. Boot-menu recovery is limited to configurations not garbage-collected; rollback is not represented as reversing service/user data changes. Source.
- Open: Pinned-closure rebuilds, offline cache completeness, mutable service/secret restoration and actual rollback/GC trials remain open. E5 needs effective activation/GC policy, boot versus running-state choices and mutable-data correction; retained generations are conditional recourse.
Assessment follow-up: These bounded findings are incorporated into the evidence above. Eligibility and principle ratings are deliberately unchanged; their reconciliation and any blank-status fixes are deferred to the next pass. Reproduction details and retained inputs are in evidence/third-pass/batch-9/.
Human-readable criteria: Can an administrator reproduce, inspect, recover, and operate the system from user-controlled configuration and packages without a vendor-controlled permission path?
Rating reconciliation: 24 October 2026
E3 and E5 remain Not Verified for the existing declared scope. Longevity and Transparency and Control are Not assessed pending their required minimums. Sovereignty is also Not assessed because the required access/exit/custody minimums are not all established. This is a targeted evidence decision, not a finding that the product fails. Existing E1, E4 and Locality findings were not re-certified.
Remaining: Pinned-closure rebuilds, offline cache completeness, mutable service/secret restoration and actual rollback/GC trials remain open. E5 needs effective activation/GC policy, boot versus running-state choices and mutable-data correction; retained generations are conditional recourse.
Next without installing locally: Use a synthetic pinned configuration/closure/cache plus mutable-state/secret-substitute manifest and expected users/services; inspect preservation records and obtain externally recorded offline rebuild/activation/GC recovery checks.
The individual decision and provenance are retained in evidence/rating-reconciliation/batch-9/. Overall: Insufficient evidence.
Contribute verification evidence for NixOS
Have you tested clean-machine restoration, format migration, or failure rollback for NixOS? We welcome reproducible laboratory logs, synthetic test fixtures, and independent assessments to resolve open findings.
Read the evaluation protocol · Submit verification records on GitHub
Individually reconciled in rating batch 9 on 24 October 2026. E3/E5 remain Not Verified for explicit missing coverage; dependent unsupported findings corrected. Previously resolved questions are retained, not counted again. E1/E4/Locality were not re-certified by this targeted review. The assessment procedure is described in the methodology.