Prior art and research

K draws on existing installer designs. This page records the ideas and their limits. It is not a claim that K supersedes every updater or that another project lacks a feature.

Design influences

The original surveys used upstream source snapshots or moving main links and were not exhaustive product audits. Attribution is summarized in NOTICE.

Source	Idea used in K	Boundary
Rustup	Thin bootstrap and an installer that can execute independently of the installed program	Helper code still has a version, trust requirements and platform-specific replacement constraints
Tailscale clientupdate	Respect installation ownership; distinguish replacing bytes from restarting the service	K uses an external runner; it does not embed the transaction in the application daemon
Datadog installer	Stable/experiment slots with promotion and rollback	K does not adopt a package catalog, permanent installer daemon or fleet control plane
Tailscale distsign	A studied example of distribution authentication	K currently checks SHA-256 and size, not publisher signatures; no signing roadmap is implied

Source

Idea used in K

Boundary

Rustup

Thin bootstrap and an installer that can execute independently of the installed program

Helper code still has a version, trust requirements and platform-specific replacement constraints

Tailscale clientupdate

Respect installation ownership; distinguish replacing bytes from restarting the service

K uses an external runner; it does not embed the transaction in the application daemon

Datadog installer

Stable/experiment slots with promotion and rollback

K does not adopt a package catalog, permanent installer daemon or fleet control plane

Tailscale distsign

A studied example of distribution authentication

K currently checks SHA-256 and size, not publisher signatures; no signing roadmap is implied

The external installer research below gives source links and explains the execution-boundary decision. K's supported contract is defined by its design, not by feature comparisons with other projects.

The original test survey also informed table-driven platform tests and observing events after a known marker. K adds its own fault injection, seeded simulation and real-runner tests; these do not establish exhaustive platform reliability. See the harness guide for what each layer proves.

These are conceptual influences. The project's attribution record states that no upstream implementation code was copied.

Two shipped installers, read against the contract

The installer contract was checked against two curl | sh installers in September 2026. Neither is a claim about the products beyond what the scripts do.

Codex install.sh: Self-update is the CLI re-running the bootstrap with CODEX_NON_INTERACTIVE=1 after the TUI exits; the contract's self upgrade row is that shape. Presence is one variable, then /dev/tty, then stdin. Unattended defaults every prompt to no rather than refusing, which works because the upgrade itself never asks. Versioned release directories and an atomically swapped current symlink are slots without a rollback command. Another manager's copy is detected and only ever removed on an attended yes. The lock reclaims by age, which K refuses. Consent is to "latest"; the channel is resolved inside the installer, which the contract moves into the entry.
Raft Computer install.sh, before this contract: The strongest verification chain seen: release authority and CDN must agree on sha256 and size before download, bytes are hashed before and after staging, the binary's platform is checked against the host, and the candidate must report the requested version. The contract's verify rules are taken from it. It has no presence model, no consent and no lock; a refused downgrade exits 0; and whenever K state exists it stops the service, quarantines the state and overwrites the binary, which is the contract's repair path taken on every run. The reference implementation replaces that with settle first, then a managed upgrade with rollback, and repair only for a machine that is actually broken.

External installer research

The 2026-09-06 survey asked whether install, self-update and remote upgrade could share an external executor without introducing another permanent service. These are source-reading observations and K design inferences, not results from running those products. Moving upstream links are not a frozen comparison.

Rustup: a thin bootstrap and replaceable installer

rustup-init.sh selects a platform download and runs the installer. The shell does not implement Rust installation. Self-update also obtains an installer executable; the helper has a release version and may remain until a later invocation cleans it up.

Unix replacement and Windows replacement handle different execution/deletion constraints. A different PID alone does not prove that an updater can survive stopping a service or replace a running Windows executable safely.

Tailscale: installation and service readiness are separate

The surveyed Linux binary path in clientupdate.go attempts a service restart separately and reports when bytes were updated but restart failed. Platform/package-specific paths respect the installation owner. This observation does not establish whether other paths have rollback.

Datadog: reuse slots, not a second control plane

The earlier survey informed K's stable/experiment slots. The published Windows installer test interface distinguishes direct install from starting, promoting and stopping experiments. The follow-up did not verify all current installer internals.

What K took from each is in the table above. The resulting design specifies a built installer, a bounded request protocol and an external controller. Product data compatibility, platform packaging and remote authorization remain product responsibilities.