SCF knowledge base

Version: 0.1

1. Purpose

The SCF knowledge base is the maintained body of knowledge for constructing, releasing, maintaining and retiring operating systems. It covers general purpose desktops and servers, appliances, kiosks, edge and embedded devices, recovery and installation media, security workstations, virtual and cloud images, container base images and white-label derivatives.

It is not a catalogue of build tools. SCF separates:

1. the obligations a system owes to the people and organisations that run it;
2. the provenance and integrity of everything that enters the system;
3. the portable model of construction, independent of package format;
4. the security properties the system must hold at rest, at boot and at run time;
5. the data and privacy contract;
6. the update, support and end-of-life contract;
7. the evidence that proves each of the above;
8. legal, licensing and regulatory governance;
9. operational and commercial practice.

2. Knowledge architecture

Layer A — Foundations

• what an operating system is as a product rather than as an image;
• the actors: producer, integrator, operator, administrator, end user, upstream maintainer, signing authority, regulator;
• threat modelling for systems, not for applications;
• failure taxonomy: build failure, boot failure, update failure, key compromise, supply-chain compromise, data loss, end-of-support exposure;
• the limits of derivation: what a downstream can and cannot change.

Layer B — Universal contract

• the Construction Constitution;
• secure and private defaults;
• human agency over the machine: the right to inspect, disable, migrate and erase;
• accessibility and interface obligations inherited from HIF;
• the normative vocabulary and the exception procedure.

Layer C — Portable construction model

• specification, resolution, lock, build, artefact, release, channel;
• the canonical construction pipeline and its stage contracts;
• the adapter contract for a platform family;
• entity mapping across deb, rpm, apk, BSD pkg, IPS, ports and source-built systems;
• privilege, isolation and hermeticity requirements of each stage;
• caching, mirroring and archive pinning.

Layer D — System properties

• boot integrity: signed boot, measured boot, verified root, anti-rollback;
• cryptography: algorithm policy, key custody, signing infrastructure;
• isolation: mandatory access control, sandboxing, kernel hardening, attack surface;
• identity and credentials;
• network defaults and time integrity;
• observability, diagnostics and recovery;
• hardware enablement and firmware.

Layer E — Data and people

• data classification and residency;
• encryption at rest and in transit;
• telemetry, lawful basis, minimisation and consent surfaces;
• erasure, factory reset and decommissioning;
• interface obligations for consent, warnings and destructive actions.

Layer F — Profiles

• general purpose desktop; general purpose server;
• appliance and embedded device; kiosk and single-purpose terminal;
• security and forensics workstation;
• immutable and atomically updated system;
• air-gapped and regulated deployment;
• installation, live and recovery media;
• virtual, cloud and container base images;
• white-label derivative.

Layer G — Evidence

• the evidence ladder and what each rung can and cannot prove;
• the verification corpus: checks that run offline against an image, checks that require a virtual machine with firmware and a TPM, and checks that require reference hardware;
• reproducibility and rebuild verification;
• conformance levels and the release gate;
• operational signals after release.

Layer H — Lifecycle and professional practice

• versioning, channels, promotion and demotion;
• support period, security-update availability and end-of-life notice;
• vulnerability intake, triage, coordinated disclosure and advisories;
• incident and exploitation reporting duties;
• migration and decommissioning of a product line;
• multi-tenant operation of a construction service.

Layer I — Law and governance

• product-security regulation and conformity assessment;
• licence obligations of every included work, including source availability;
• trademarks of upstream projects and of the producer;
• firmware and non-free component terms;
• export control and sanctions;
• records, declarations and retention.

3. Source policy

An SCF source MUST be traceable to a primary text. Priority:

1. regulation as published in an official journal, and binding technical acts;
2. a current standard or specification from its issuing body;
3. the upstream project's own documentation, source tree or release notes;
4. an original technical report or dataset from a responsible organisation;
5. an original peer-reviewed paper.

A secondary article, a translation, a vendor blog post or an unsourced checklist MAY help locate a primary source but MUST NOT serve as the evidentiary basis of a normative requirement.

Every platform statement MUST carry its scope: which system, which version, which architecture, which date. Platform behaviour changes; a claim without a version and a date is not usable.

4. Claim classes

Numbers MUST NOT be presented as universal thresholds unless a standard defines them for the stated scope. Build timings, image sizes and mirror volumes are measured claims and MUST carry their measurement conditions.

5. Navigating the corpus

Start with the Constitution. Choose a product profile. Express the system as a specification and map it onto a platform family using the portable build model. Plan verification before implementation using Evaluation and conformance, and keep traceability from an obligation to evidence.

For a derivative of an existing distribution, begin with the derivation limits in the Constitution: what the upstream signing chain permits, what the upstream licence and trademark terms require, and which upstream guarantees are lost the moment a component is rebuilt.

6. Maintenance

Every document MUST state a version or inherit the corpus version. A material change requires:

• the changed statement or requirement;
• the reason and the evidence;
• the affected profiles and tests;
• the migration and compatibility impact;
• the reviewer and the review date.

The following MUST be reviewed at least annually, and before any related work:

• product-security regulation and its dates of application;
• signing-authority policy and certificate validity;
• upstream support periods and end-of-life dates;
• hardening baselines and their current revisions;
• the algorithm policy and deprecations;
• upstream trademark and licence terms.