Org-specific forks, maintained by AI

Take the upstream changes that matter to you. Leave the rest on the tree.

AI is going to make software move faster and faster. Most of those changes touch code your machines never run. graft keeps your own fork of upstream and carries only the changes that reach what you actually run, so you update when it matters to you.

There is security in differentiation, too. An instance that carries 21% of upstream's changes skips the exposure of the rest, and an instance unique to you can be a harder target than the copy everyone else runs.

upstream Talos v1.13.0 → v1.13.10 · 6,911 changes
your fork 1,458 carried ship-now ship-batch
Fig. 1 One mark per ~192 upstream changes. The pinned base is the rootstock; the carried series grafted onto it is the scion.

01

The Red Hat model, one level down

An enterprise Linux vendor pins a release and maintains a patch set on top of it, so customers get fixes without absorbing every upstream change. graft extends that model down to the customer. Each org keeps its own fork that tracks upstream, and AI maintains a patch series of just the changes that matter to what the org actually runs.

rootstock
A pinned upstream base release. It supplies the roots: the build, the release line, the support window.
scion
The patch series. Cherry-picks of the upstream changes that reach your instance, each carried for a stated reason.
union
Your own installer, built from base plus series and tested by the exact digest of that series.

02

How it works

  1. 1Profile

    Read-only probes record what the running instance actually uses: bound drivers, loaded modules, the kernel config, mounted filesystems, socket families, listening ports, extensions and machine-config features.

  2. 2Triage

    Every upstream change is placed against that surface. Rules decide first:

    • Kbuild tells which CONFIG_ symbols and module a kernel file compiles into.
    • Unmounted filesystems and unbound hardware drivers are off-surface.
    • CVEs come from the kernel CNA's records, with CVSS setting urgency.

    A local model judges only what the rules can't. It runs on the org's own GPU, so the attack-surface map never leaves. The model can raise a tier, and it can never lower a rule's floor.

    The four tiers, with backtest counts
    outside5,260
    touches nothing the instance uses. Never carried.
    hold193
    touches the surface, but is a feature, refactor, or a fix for a case this instance cannot hit. Not carried.
    ship-batch618
    a real fix to code the instance runs. Carried and released on cadence.
    ship-now840
    a security fix to code the instance runs. Released as soon as the policy allows.
  3. 3Series

    A pinned upstream base plus cherry-picks of only the carried changes. The branch is regenerated from the series, so the series is the source of truth and every branch is reproducible from it.

  4. 4Build and test

    graft builds the org's own Talos installer and boots it in a QEMU VM. The test records the exact series digest it booted, and only that digest can be promoted.

  5. 5Release

    A release happens only when something that matters changed. A new upstream release on its own never causes one. The release pipeline is model-checked in TLA+, and TLC found three real races in the naive design:

    • promoting a series that was never tested, because promotion re-read the live series;
    • an older build overtaking a newer one, so an "upgrade" silently dropped patches;
    • a model verdict overwriting a rule's tier and un-shipping a fix the rules required.

First target Talos Linux. The first customer is a Talos VM in QEMU. A Dell server running Talos is next, with a different profile and a different patch set.

03

Backtest: four months of Talos Linux

We replayed upstream Talos from v1.13.0 to v1.13.10 (27 April 2026 to 3 September 2026) against one instance, deciding and releasing the way the live loop would. 6,911 upstream changes arrived: 156 in talos, 65 in pkgs and 6,690 in linux-stable (Linux 6.18.24 → 6.18.48).

Changes installed

1,458

of 6,911 upstream (21%)

CVE fixes deferred as off-surface

2,088

of 2,981, each with a stated reason

Days until a ship-now fix runs

2.0

fast policy, vs 7.9 following upstream

What the instance installs Changes over the window. The 2,088 CVE fixes graft leaves out touch code this instance does not run.
  • Follow upstream
  • graft

All upstream changes

6,911
1,458

CVE fixes

2,981
893
Days until a ship-now fix is running Mean over 840 ship-now fixes, by release policy. Fewer days costs more releases.
  • Follow upstream
  • graft
Follow upstream · 10 releases 7.9 d
graft, fast · 45 releases 2.0 d
graft, weekly · 20 releases 3.8 d
graft, upstream-paced · 11 releases 7.5 d

The trade is cadence against speed. Upstream-paced releases 11 times against upstream's 10 while installing 21% of the changes. Fast releases 45 times and has a ship-now fix running in 2.0 days instead of 7.9. Weekly sits in between. Every policy installs the same 1,458 carried changes; only the timing differs.

Release policies over the backtest window
Policy Releases Ship-now fix, days CVE fix, days Installed
Follow upstream 10 7.9 7.6 6,911
graft, fasturgent releases at least 1 day apart, fixes batched every 7 days 45 2.0 2.0 1,458
graft, weeklyurgent releases at least 7 days apart, fixes batched every 7 days 20 3.8 3.8 1,458
graft, upstream-pacedurgent releases at least 14 days apart, fixes batched every 30 days 11 7.5 7.3 1,458

Days are the mean time from a fix being available upstream to the instance running it. CVE fix days for graft cover the 893 CVE fixes it carries. Changed lines installed: 168,575 following upstream, 36,354 with graft.

04

Risks, stated plainly

Security fixes are often unlabelled

Many fixes land without a CVE or a security note. Triage is rules-first for that reason, and the model can only raise a tier above a rule's floor, so a model mistake costs an extra release rather than a fix the rules required.

Unreachable means not compiled and not loaded

Code the instance does not compile or load is treated as unreachable. Physical access is out of scope for the VM profile: plugging in a USB NIC loads a driver the profile never saw. Profiles for real hardware have to account for it.

The base goes end of life

A pinned base is only safe while upstream supports it. The org must rebase before its base goes end of life, and graft flags the rebase ahead of that date.

05

What's next

  1. A Dell server running Talos

    Same upstream, a different profile (real network and storage hardware), so a different patch set. The second instance is where per-org stops being a claim.

  2. The model pass

    The local model judged 526 changes the rules could not place. Its share will grow, and the numbers above will move.

  3. A kernel trimmed to the surface

    The differentiation step. Build a kernel that compiles in only what the profile uses, so the 2,088 deferred CVE fixes point at code that is absent from the image, not merely idle in it.