Roadmap
Delivered scope from inception to the first staged release, with the tracking issue for each step. Every item below was completed as a tested pull request and verified by execution; the dates are the issue-close dates.
Project timeline
3 October — baseline
- The product specification — the implementation plan — is written and reviewed before implementation; the board graduates to the GitHub org as issues KA-01…KA-44 with the label, effort and milestone catalog, and repository governance follows: branch protection, contributing and security policies, Renovate (KA-21, 46–57).
- The engineering standard is committed before any build work: hypothesis-first TDD with watched-RED commits, and the OpenSSF Scorecard and Best Practices badges in the default row (PR, badges).
9 October — the two-repo foundation
- The OS repository revives as a real flake — pinned inputs, explicit unfree posture, no global CUDA — and the minimal profile evaluates with zero categories enabled, producing a system closure (KA-01: skeleton, flake, closure).
- The overlay repository (kailash-packages) seeds as an independently consumable flake — the nixpkgs↔︎NixOS split — and the OS flake.lock pins it at the first lock-time evaluation (KA-02: overlay flake, pin).
- The engineering standard hardens in-repo: harness-before-capability ordering, GitHub Actions as the authoritative check surface, and flake-check matrices evaluating both declared systems on hosted runners in both repositories (ordering, hosted gates).
10 October — the taxonomy becomes data
- categories.yaml locks the post-purge census: CORE plus CLASSIC (C-1…C-10), ATTACK (A-1…A-8), DEFENCE (D-1…D-7) and OPS (O-1…O-7), with MITRE ATLAS and OWASP-standards mappings carried as manifest data (KA-04: CLASSIC census, OPS + rename).
- tools.yaml defines the entry schema and the manifest validator — unique identifiers, category existence, per-layer reconcile counts — committed watched-failing before any tool data lands (KA-05.1, PR).
- The first bespoke derivations land: garak is pinned commit-exact and smoke-checked against its probe index — a hosted-runner packaging defect is caught and fixed the same day — PyRIT is packaged, and the kailash CLI opens list / search / info over the manifest (garak, PyRIT, CLI).
- CI becomes manifest-driven: a committed generator expands the manifest into the build matrix in both repositories, and the negative gate — a deliberately broken manifest fails the build before any matrix leg runs — is proven (generator, negative gate).
11 October — manifest complete, gates enforced
- Every surviving tool is entered: CLASSIC 142, ATTACK 58, DEFENCE 46, OPS 91 primary slots — 337 across 32 census categories, data-packs excluded from counts — and the per-layer totals reconcile in the validator (KA-05, CLASSIC entries).
- The flagship evaluation stack builds green on hosted runners — garak, PyRIT, promptfoo (its freshness decision recorded), ART, counterfit — each acceptance smoke joined to its build leg (KA-10–12, acceptance smokes).
- Safety becomes mechanical: every tool carrying safety: exp is wrapped by the generator to refuse execution outside the double-key lab-mode gate (the host option plus KAILASH_LAB_MODE per invocation), and CI fails on wrap or manifest drift (KA-18/19, drift gate).
- The hardened profiles — redteam-ai (ATTACK full + O-4) and minimal — evaluate and build (KA-17, PR).
- Release engineering is fixed: calendar release trains on 2026.xx with the two-digit release index, update cadences by tool-staleness class, the lockfile as the version, and the kailash binary cache live (KA-16, KA-47, cadence policy).
12 October — the four layers become modules
- Layer CLASSIC completes C-1…C-10: the exemplar module lands first per the §4.5 contract and the siblings generate from it; the Burp-family tools are pinned exact via the lock; exploitation remains software-only; the SDR pack is recorded as opt-in data, never on default images (KA-06/07, exemplar PR).
- The OPS platform modules land: the MLflow service, k3s/podman compute with ollama and llama.cpp, the langchain SDK stack with torch as a Shape-4 pair (non-GPU default, explicit -nvidia variant), native and containerised vector stores, local-LLM web UIs, an authoring stack, and per-category devShells (KA-08/09, torch shape).
- Layer ATTACK opens as category modules: A-1 AI reconnaissance and A-2 prompt injection, payload packs as opt-in data, trufflehog cross-listed by the secondary-tags rule (KA-13, PR).
- Layer DEFENCE completes D-1…D-7 — guardrails, evals, provenance, threat modelling, governance mapping, standards verification — with the packaging-reality gate recording which defences ship as derivations (KA-24, PR).
- The VM smoke suite boots the shipped categories inside the distribution and enforces the module contract (suite PR).
13 October — 2026.01-alpha.1: the first staged cut
- The ATTACK long tail completes: the agentic/MCP and supply-chain categories (mcp-inspector, mcp-scan, guarddog, picklescan, modelscan) and A-5…A-8, with the mlflow-bypass integration leg — an attack tool exercised against the platform’s own lab deployment (KA-22/23, integration leg).
- O-7 ships agent and MCP operability with short-lived, human-minted capability grants — read-class defaults for unsupervised agents (KA-25, PR).
- GVM/OpenVAS arrives as a service module, and the kailash.data.* wordlists and data packs flip opt-in with proof legs (KA-27, KA-29).
- Platform VM acceptance: a booted platform profile completes an ollama prompt and serves MLflow on :5000 (KA-08.5, transcript).
- The deliverable shape is decided: QEMU images primary, ISOs secondary; the budgets are CI-enforced (KA-28, matrix PR).
- The first release publishes: 2026.01-alpha.1 — the full four-layer catalogue on a pinned, reproducible NixOS base, 32 census categories and 337 tool slots; ISO and QEMU artefacts attach from hosted runners with artefact-naming and upload-actor checks, and the release body carries the gate table: the hosted build (37 legs), flake-check, OpenSSF Scorecard, the manifest validator at the pin, and the §11.2 refusal contract — the generator refuses the exp-carrying A-8 emit by name (KA-46, lock bump).
- Every artefact is born attested: the release workflow holds an OIDC identity token and emits, per artefact and before upload, an in-toto SLSA v1.0 build-provenance statement and an SPDX SBOM, signed with a Sigstore certificate and recorded in the public Rekor transparency log — verifiable with gh attestation verify (KA-48 slice, attestation listing).
- The image-matrix completeness amendment builds the four targets the initial cut had not, from the tag’s pin, and SHA256SUMS covers all twelve matrix artefacts (completeness, attach from hosted runners).
14 October — release engineering completes; the documentation estate opens
- Oversized QEMU images publish in attested chunks with per-leg checksum sheets, keeping SLSA attestation intact past GitHub’s per-asset cap — and the workflow-trigger defect that would otherwise have left four matrix targets never-built is found and fixed (chunked publishing, trigger fix).
- The standing release ladder is codified: alpha → rc.1 → GA, the standing cut checklist, and per-criterion verdicts at every stage (KA-49).
- The implementation specification is published in-repo, every section citation hyperlinked to its anchor — the citation convention all prose surfaces enforce (KA-51, docs/spec.md).
- The aarch64 legs of the matrix build natively under the split-arch strategy (hosted x86_64, native arm); Raspberry Pi-class support is reported as partial, with the posture decision recorded (KA-36).
- The documentation estate goes live: the Kailash OS Guide — the taxonomy census, the build’s security and governance model, the administrator guide and the manifest-generated category directory — and the Kailash OS Cookbook with task-oriented recipes (first image, the garak LLM01 prompt-injection scan, attack-then-verify, administrator procedures) (KA-WS-5, KA-WS-6).
Roadmap
Work is tracked on the Kailash Roadmap board as issues KA-01…KA-51 across the kailash-os organisation — the OS, the packages overlay and the website are separate repositories with a single dependency graph (the canon map). Every issue lands a runnable artefact with an exit criterion.
| Train | Items | Status |
|---|---|---|
| 2026.01-alpha.1 — DELIVERED | KA-01–KA-29, KA-36, KA-45–KA-47, the release slices, KA-49, KA-51: two-repo skeleton; taxonomy as data (32 census categories, 337 slots); the four layers as modules; the flagship derivations; CLI core; manifest-driven CI on both systems; the §11.2 double-key lab-mode gate; hardened profiles; the image matrix; the first staged cut | 2026.01-alpha.1 published |
| 2026.01 — completion (rc → GA) | KA-48: attestations across the remaining artefact surfaces (published containers, the release-notes bundle — images and ISOs already carry them); then the release-candidate cut of the same train. The lockfile is the version — rc and GA are pin states, not feature deltas; bare 2026.01 is reserved for GA | rc |
| 2026.02 — next train | KA-26 desktop menu generation · KA-30 manifest-driven website build (category, tool, ATLAS and standards views) · KA-31 Quarto report templates + kailash report new · KA-32 golden-image diff + two-machine reproducibility gate · KA-33 full release workflow (changelog from the lock delta, aibom.cdx.json dogfood) · KA-34 ATLAS tactic matrix, all 16 tactics · KA-35 standards-first navigation (kailash verifier) · KA-44 the zero-to-Nix-derived learning track | next |
| backlog — later trains | KA-37 torch-family fallback overlay · KA-38 upstreaming novel derivations to nixpkgs · KA-39 brand system · KA-40 D-6 IRAP/ISM governance lens pack · KA-41 kailash doctor (store-path provenance reporting) · KA-42 kailash container provisioning · KA-43 headless-agent image polish | later |
Engineering discipline
Hypothesis-first TDD with watched-RED commits is the engineering standard: the failing test is written first and committed watched-failing, then made to pass — the RED→GREEN pair is visible in every item’s history. Harness-before-capability: the check that would catch a regression ships in the same pull request as the capability it guards. Each roadmap item decomposes into hour-scale leaf slices; every commit and tag is GPG-signed, merge-verified against branch protection. Releases follow the cadence policy: a train every six weeks, alpha → rc.1 → GA, the lockfile as the version, and nothing updates itself in the background. The loop is documented on the Build page.
Documentation
The specification and its practice are published on three surfaces, generated and verified against the same pinned manifest revision:
- kailash.site — this site: the specification overview (taxonomy, architecture, verification standards, governance) and the generated tools catalogue.
- docs.kailash.tools — the Kailash OS Guide, generated from the manifest: Part I–IV with the taxonomy census, the build’s security and governance model, the administrator guide, and the per-category directory (KA-WS-6); the per-tool reference-page generator, with the exemplar reference page live, is the open lane (KA-WS-6.6).
- book.kailash.tools — the Kailash OS Cookbook: worked, task- oriented recipes with real commands and expected output (KA-WS-5); the recipe directory and per-family walkthroughs continue on the book (book upkeep).
Contributing
Contributions follow the contributing guide and the engineering standard — add tools through a manifest entry, never hand-edited module files; CI validates, builds and VM-tests every change; commits and tags are GPG-signed; work lands on leaf branches cut from the default branch. Pick an item from the 2026.01 completion or the next train — the spec section cited in the issue body is the design source. Kailash OS is BSD-3-Clause.