Horizon

[1zeroone0]

Never merged. Each comment below is a future PR in the description template; update it as intent clarifies, and when one is ready, open its PR and delete the comment. Close this PR when it is empty.

🤖 Generated with Claude Code

[1zeroone0]

tracer: aya, traces before policy

Spec: the witness record in Decide; executed is what it witnesses.

What this PR does

• eBPF via aya, keyed by cgroup only, in the machine's kernel, outside the model's reach. Seeing behaviour comes before writing policy.
• Span tracking via read tracing (read/pread with fd, offset, length), not page faults: memfd pages are resident, fault-around is coarse, and head/sed/grep use read(), not mmap.
• Prefer syscalls over pseudo-filesystems (pidfd over parsing /proc).
• Record the kernel version and seccomp filter hash in the manifest's measurement, so a job names its exact interface.
• Every doc the model opens is seen; repeated reads of a page signal a missing prompt line.
• For interpreters, the witness moves from execve to syscall level (opens, reads, forks). Record whether executed code came from the model or from state.
• Leaning: tracepoints are fairly steady, kprobes on function names are not; BTF and CO-RE soften struct drift (verify). Acceptable because the kernel is pinned and measured; a kernel upgrade re-validates the tracer. Open: tracepoints only.

What this PR does not do

• Key on any service's process structure (Postgres is process- or thread-per-connection).
• Enforce anything.

Merge requirements

• Every allowed call's witness record is attributed by cgroup, however many processes the command spawned.
• Measurement: tracer CPU and per-syscall overhead, probes on vs off.

[1zeroone0]

policy: Cedar compiled to exec allowlist, seccomp and Landlock

Spec: Policy, Decision, property 3 (DenyNeverRuns).

What this PR does

• The manifest names a Cedar policy file; cead compiles it into kernel rules installed in the fork–exec gap. Permit-all is a declared Cedar policy, not an absence.
• Seccomp cannot be the call table: it filters syscall numbers and raw registers, not the path behind execve. The call table is an exec policy (a rootfs of sanctioned binaries plus Landlock execute rights); seccomp covers the syscalls those tools need. Both render from the call table.
• Seccomp default for unknown syscalls: ENOSYS, not kill or EPERM, so libc falls back to older calls and task images keep working as they age (clone3 is the known case; verify before citing). Dangerous calls still denied hard. Generate per architecture.
• The allowlist is derived per authority: a fixed binary needs little; an interpreter needs the broad set and rests on Landlock, cgroup and no network. git exec via hooks and aliases funnels through execve.
• Admission for anything on the model's PATH: in distribution? needed for this task? zero privilege beyond the process's policy?
• Position decides role: the same Cedar policy enforces in the kernel and decides in userspace. Userspace (on brush's parsed AST, before spawn) sees argv the kernel cannot (--force) and gives a denial the model can read; it is bypassable (python -c), so enforcement is the kernel. Leaning: position is derived from which entities and actions a policy references, not a new manifest field.
• Position by time (sandlock, read 2026-09-27). Before exec, static rules fail closed: seccomp-bpf, Landlock, cgroup. During the syscall, seccomp user notification holds execve, connect or openat while the harness reads argv and decides: argv rules become enforced, not advisory. After the fact, the tracer witnesses and never decides. At the node, the host's kernel (Tetragon, Envoy), trusted like the host. On the path to the model, separate silicon (a DPU), trusted even when the host is not. In the ISA, capability hardware (CHERI): descriptors the CPU will not let a process forge or widen. Reach for the earliest that can express the constraint.
• Leaning: user notification beside the seccomp deny filter, not instead of it. argv is read with the task frozen (TOCTOU). Cost: a trusted process in the syscall path, latency on held calls.
• Leaning: Cedar's own Lean model is the spec for the compiler. Theorem: the compiled rules allow exactly what the Cedar authorizer allows; differential tests tie it to Rust.
• Open: policy that depends on state, not only the command ("require wait before ending"). It breaks Policy as a constant in the spec; settle it here.
• Open: sandlock-core as the boundary crate vs landlock plus seccompiler, under the Cargo.toml allowlist. Its gap sequence is ours: setpgid, NO_NEW_PRIVS, Landlock, seccomp last, close fds 3+, exec.

What this PR does not do

• Decide what any model should be allowed to do; users bring their own policy.
• Admission at the host (which manifests may boot); host level, later.

Merge requirements

• A deny appears in the log both as a decision record and as kernel enforcement.
• Measurement: denials per job, advisory vs kernel-enforced; ENOSYS fallbacks observed.

[1zeroone0]

shell and calls: brush, uutils, man pages

Spec: the commands Issue carries; the call table itself is below the spec.

What this PR does

• brush is the language, uutils the tools; brush has no head of its own. Leaning: embed brush over a hand-rolled parser. (Checked at reubeno/brush @ 6bada55; re-verify.) Builtins implement clap::Parser, so a builtin is a typed struct; register_builtin exists; an ErrorFormatter trait controls error text. brush-coreutils-builtins bundles uutils and re-enters the binary per utility, so pipeline stages stay real processes and execve tracing works. No pre-dispatch interception hook: restriction comes from PATH plus Landlock. brush uses nix plus some libc, not rustix.
• Job control is the sub-agent interface: &, wait, jobs, kill must behave as bash's do.
• Gaps: grep, sed, awk, xargs are not coreutils. find/xargs are in uutils/findutils (check -P). For any port, GNU test-suite pass rate is what matters: flag and error-text fidelity is the reason to use them.
• Docs as state, three tiers, all in distribution: a pinned prompt line per call and per rule; --help; man page. man 7 cead for the world ($CTX, /work, truncation, ending a turn). Generated from the call table with clap_mangen (verify fit). Pre-rendered text behind a tiny man; pages pass through the bound, so keep them short. Descriptors drop their own page on mount (SQLite schema note first).
• Leaning, unvalidated: nothing about cead should need teaching; an unknown command returns a hint toward the sanctioned equivalent.

What this PR does not do

• agent (Run one job end to end as a recursive language model #13).
• Let task tools shadow core on PATH.

Merge requirements

• agent and the ending rule have their prompt lines, --help and man page, rendered from the call table.
• Measurement: invalid-command rate and doc opens per job.
• Open: how much of brush's surface to disable; whether real git is core or task.

[1zeroone0]

tools seam: core disk plus task image

Spec: none; below Begin, which assumes the view init assembles.

What this PR does

• Take two of Docker's three parts: the image format and registry, and the Dockerfile as authoring format. Skip the runtime; the microVM replaces it. cead is already a minimal container runtime: a container is processes whose world was arranged in the fork–exec gap.
• Host, build time: resolve the image by digest, flatten layers into a read-only disk (ext4, squashfs or erofs: open), record digest and derived tool list in the manifest.
• Boot: the core disk plus the task disk as a second block device, both content-addressed. init verifies each against the manifest's hashes before mount (dm-verity or equivalent): devices are untrusted input. Then a mount namespace with the task image as root, a writable overlay (tmpfs or scratch: open), core read-only and first on PATH, descriptors, then Landlock, seccomp, cgroup, exec. Honour ENV, WORKDIR, a sensible USER; ignore ENTRYPOINT/CMD.
• Tool list from the OCI config plus a label (LABEL cead.tools="python pytest"), authority per tool derived at load. nix emits OCI images too: one artifact kind, two producers.
• The bar for core: in distribution, broadly needed, stable. Everything else is a task tool. A container engine, when a task needs one, is a task tool (rootless podman, images preloaded).

What this PR does not do

• Run a container engine by default: a second wall costs size, boot time and a second cgroup manager, and assumes a network the machine lacks.

Merge requirements

• A SWE-bench instance image boots unmodified as a task disk under the core, verified before mount.
• Measurement: core size, rootfs size with a task image, boot with and without the task disk, verification cost.
• Caveats: images assume root and a libc; core-first PATH can collide with an image's own git or grep. Open: cache unpacked images by digest; multiple task images and their order.

[1zeroone0]

trusted-host mode: Firecracker and Virtualization.framework

Spec: none new. The header's assumptions are asserted instead of proved; the report says unattested.

What this PR does

• Runs the same harness where developers are, after the mainline has proved it in a confidential Cloud Hypervisor machine; concurrent with the confidential research. Same machine, same records; only an attested boot's report is signed.
• The invariant is the Linux syscall ABI, not POSIX portability.
• Host code (CLI, relay, log writer, grader glue) stays inside the POSIX line: rustix with its libc backend, std, nothing Linux-specific; the VMM is the only per-OS piece.
• Workspace split that enforces it: cead-core (types only), cead-machine (Linux-only), cead-tracer (Linux-only, aya), cead-host (portable), one crate per VMM. cead stays the only published name.

What this PR does not do

• Machine fork on macOS; whether VZ restore shares pages copy-on-write is unverified.
• Attestation: neither VMM supports a confidential machine (Firecracker closed #2332).

Merge requirements

• The first job's task (Run one job end to end as a recursive language model #13) runs on Firecracker, Virtualization.framework and Cloud Hypervisor with the same records; each report says unattested.
• Measurement: boot and per-call cost against the attested machine, the trusted-host side of the comparison.
• Caveats: the Mac boots arm64 machines; benchmark images are x86_64. Rebuild or Rosetta in the machine. Open: whether any host feature tempts a Linux-only shortcut.

[1zeroone0]

stats: cead stats and the measured table

Spec: none; it measures what the spec commits to.

What this PR does

• Derive numbers from what exists (records, the log, traces, relay records) before building telemetry; a number that cannot be derived is a missing record field.
• Set A, cead itself, absolute: footprint (core, rootfs, snapshot size, memory per idle and active process, log bytes, machines per host); lifecycle (cold boot to first command, job to first token, teardown), p50/p95/p99; per call (model, tool, harness time, vsock round trip, bound-and-spill cost, log round trip, signature and hash); inference (TTFT, tokens/s, prompt-cache hit rate, input tokens per call); memory policy, the thesis (window occupancy, bytes read vs admitted, truncation and spill follow-up rate, re-read rate, evictions before failure, doc opens); cost per job and per resolved task, inference vs compute; overhead (tracer, seccomp and Landlock, ENOSYS); reliability (boot failure, OOM, timeouts, isolation tests, same version vector gives same prompt hash).
• Set B, task performance, comparative: same model, subset, scorer; harness the only variable; several seeds. Bridge: resolve rate per dollar.
• Set C, attested vs trusted host, the same job both ways: boot latency, the report's round trip before the first call, re-keying per fork, boots lost to fencing, unknown boots. How it is safer, and what that costs, in numbers.
• Targets set from first measurements, then treated as ceilings; a CI size ceiling on dependency count and binary size.

What this PR does not do

• RL-interface numbers (fork fan-out, rollouts per GPU-hour) until machine fork exists.

Merge requirements

• README carries a small honest table: size, boot, density, cost per task, attested vs trusted host.
• Open: which numbers are cead stats output vs offline analysis; whether per-job metrics are records in the log.

[1zeroone0]

first release: README return pass

Spec: none.

What this PR does

• Replace the README's placeholders after the first job runs end to end (Run one job end to end as a recursive language model #13): install instructions; an example job with real input and output; a screen recording of the console (the mockup is the intent, the recording is the truth); a demo video; network rules as enforced; the measured table from stats.
• Add a LICENSE file. Cargo.toml already declares Apache-2.0 and the crate is published under it.
• Check domains and trademarks for cead.
• Three readers, in order: a recruiter in seven seconds; a hiring manager looking for taste, a demo and specifics; a power user installing it. Every sentence serves one of them.

What this PR does not do

• Invent Automation or Governance subsections; add them only if something is settled.

Merge requirements

• No README placeholder remains.
• "A SWE-bench instance image works as is" still holds, or the line says exactly what changed and why.

[1zeroone0]

machine fork: snapshot and boot from it

Spec: layer 2 (Snapshot, BootFrom, Arrive's recovery branch and fence; properties 12–13).

What this PR does

• On the host a microVM is a process; its memory is the VMM's memory. Machine fork is snapshot and restore (you cannot fork() a running VMM), and pages are shared copy-on-write when the memory file is mapped private (verify early).
• A snapshot is taken between calls, once the log holds every record so far. A boot from it makes a new key; its report names the snapshot (that boot and its last record). A fork starts a new job; a recovery continues one whose boot is unknown, at most once, and fences it.
• Recovery is the operator's choice, manual by default; automatic resumes from the last snapshot.
• Leaning: a snapshot is a manifest plus state, so a forked machine's manifest is derived from the snapshot, never authored. The CLI has one "boot from" mechanism with two sources: a manifest or a snapshot.
• Use: RL, K continuations from one state (README fan-out table). KV blocks for the shared window are the third tier of fork (Horizon: one memory hierarchy).
• Log roles: the log is training data and audit (exact sampled tokens, logprobs where available, model and weights version); evals need a reproducible initial state, not a reproducible job.
• Trusted-host first (Cloud Hypervisor on KVM, then Firecracker); attested fork is research (Horizon: confidential machine).

What this PR does not do

• Let a machine fork itself from inside. If ever allowed, it is a request over vsock to the host, gated by a descriptor.

Merge requirements

• K machines booted from one snapshot diverge independently, each with its own key and report.
• A recovery's report fences the boot it recovers: a late exit record from that boot is refused.
• Measurement: fork-from-snapshot vs cold boot latency; re-keying; memory shared across K forks.
• Open: whether the console forks with the machine or stays over the original and lists its forks.

[1zeroone0]

scale-out and Kubernetes

Spec: none; the scheduler is trusted for availability only.

What this PR does

• Evals fan out as N machines from one manifest (README fan-out table). nix makes the manifest reproducible; equal manifests are the same experiment.
• Kubernetes schedules jobs, never the inside of one: a pod runs cead with the VMM inside and /dev/kvm from a device plugin; one Job per job; Job parallelism is many jobs. A scheduler is handed either source: a manifest or a snapshot.
• Any host that can boot the boot contract (measured kernel and init, content-addressed disks, a vsock) can schedule a machine; it never sees inside.
• No tracer DaemonSet: the tracer is inside the machine.
• Resource requests come from measured memory per active process and boot latency.

What this PR does not do

• Kata as a VMM: it owns the machine's kernel, rootfs and PID 1.

Merge requirements

• N instances × seeds run from one manifest, graded on the host.

[1zeroone0]

the VM-boundary decision

Spec: none; the spec assumes a machine boundary.

What this PR does

• Settles the one real fork in the design: keep the microVM boundary and engineer toward container efficiency, or work at the container or pod layer (gVisor, Agent Substrate) for RAM efficiency.
• Leaning: keep the VM. Efficiency is closed incrementally and every gain is kept; a hardware boundary, a real kernel to instrument, and attestation cannot be retrofitted. Density wins at the app layer come from agents idle for hours; rollouts and evals are busy then gone, so active memory per process and fork latency matter.
• Three schools, one move: unbundle the image from the runtime, arrange the world in the fork–exec gap, let the kernel enforce. They differ in the unit. Process (sandlock): a shared kernel plus a userspace supervisor, no root, ~5 ms start. Container: the ecosystem. Machine (cead): a kernel per unit to instrument and meter, a record out of the model's reach, and on confidential hardware evidence out of the host's reach, at a kernel's memory and boot per unit. A separate kernel is structural and fails closed; a shared kernel with policy holds while every rule is right and fails quietly. cead is both: the VM boundary, and process policy inside it.

What this PR does not do

• Decide before measurements exist.

Merge requirements

• Reopen only on evidence: active memory per process beyond some multiple of gVisor AND an idle-heavy workload; OR fork-from-snapshot not sharing memory; OR restore latency dominating short rollouts. Thresholds from first measurements.

[1zeroone0]

one memory hierarchy: inference control and evidence

Spec: layer 3's Processors and Dispatch today; inference as evidence is phase two and not yet specified.

What this PR does

• With control of the engine and weights, the window becomes one tier managed end to end: weights (text segment), KV cache (pages and swap), window tokens (address space), files and database (backing store), log (journal).
• The engine is the model's processor; Dynamo is its scheduler, the way Kubernetes is the machine's: KV-aware routing, disaggregated prefill and decode, multi-tier KV (KVBM), autoscaling (v1.5.0, 2026-09-21). It is the tool for the KV tier.
• Leanings: the same eviction is made twice, blind (cead by token, the engine by KV block). With control, separate lossless eviction (offload KV) from lossy (summarise to a file). Fork becomes one primitive at three tiers: VM pages, filesystem layers, KV blocks. The log is truth, so every tier above it is a cache. Weights join the version vector. Scheduling becomes locality.
• Prefix hints from cead to Dynamo: every process in an agent tree shares the pinned prompt; every fork of a snapshot shares its whole window.
• Inference as evidence: the engine signs what it produces, a chain like the machine's; a record of inference kept outside the machine, joined to the log by call id, so the machine's account is checked against one it cannot reach (a relay on a DPU, or attested inference on a confidential GPU).
• Habits from the first job keep this open: deterministic, prefix-stable window assembly; exact tokens and logprobs logged; model and weights version recorded.

What this PR does not do

• Confidential KV: whether KV can be shared across a tree or forks without context leaving the machine's protection is a research question (Horizon: confidential machine).
• Anything that needs engine control while inference is a hosted API.

Merge requirements

• Open: the unit of scheduling when a job is a tree; co-location of rollouts and inference; job-scoped tokens the engine verifies.

[1zeroone0]

Postgres as a task tool

Spec: none.

What this PR does

• SQLite stays native: a file plus sqlite3 in core; a snapshot captures it; one writer per file; copy-on-write across forks.
• Postgres enters when a task needs extensions (pgvector), real concurrency, or arrives with a data directory: a service-class task tool with its own uid, cgroup and unix socket, inside the machine so snapshots capture it. The schema note names the dialect.
• pgrust (checked 2026-09-20): Rust rewrite, wire- and dialect-compatible, passes the regression suite, disk-compatible with a Postgres 18.3 data dir; AGPL-3.0; no existing extensions; thread-per-connection.
• Ordering is a judgment call: stock Postgres first so a strange result has one suspect, or pgrust first with stock for extensions.

What this PR does not do

• Start before a task demands it.

Merge requirements

• A task needing Postgres runs with it inside the machine and a snapshot captures it.
• Open: a .sqlite file vs schema plus seed dump as the tracked form; the log as SQLite once it needs querying in place.

[1zeroone0]

confidential machine: attestation, snapshot and fork

Spec: the header's KeySecret, KeyBound and SnapshotSealed; the report; layer 2.

What this PR does

• The mainline's hardware half: the same machine under AMD SEV-SNP, its memory encrypted and integrity-protected against the host, its report signed by the processor over the manifest's measurement (kernel, init, command line, core disk). The key that signs the boot's records is made in the machine and bound to the report, so the host cannot read the job or forge its log; it can still stop it.
• VMM: Cloud Hypervisor. v52.0 (2026-05-14) runs SEV-SNP guests on KVM with measured boot (IGVM firmware, e.g. Oak stage0) and a signed SNP ID block; v53.0 adds nothing for SNP snapshot. Firecracker supports neither SNP nor TDX (#2332 closed).
• The machine's side from the first commit, on plain KVM: disks verified before mount; the report through Linux's TSM interface (configfs-tsm, v6.7+; 64 bytes of inblob carry the key's hash and, for a fork, the snapshot's last record); a kernel with the confidential-VM hardening options. On hardware, only the report's signature changes.
• A verifier on the host (the virtee/sev crate) checks the report before the log accepts a boot's chain.
• Research questions, each a yes, a no, or a number: 1. attestation end to end; 2. hardware (one SNP host: EPYC Milan or newer, host kernel ≥ 6.11, SNP on in BIOS; rent first); 3. attested cold-boot latency; 4. snapshot: can an attested machine be checkpointed and restored with its chain intact; 5. fork: can a restored machine re-attest as a new boot and continue the job; 6. confidential KV: can KV be shared across a tree or forks without context leaving the machine's protection (KV confined to one job, or attested GPUs and KV transport).
• The honest residual: the TCB moves, it does not vanish: CPU microcode, firmware, the vendor's attestation service, TEE side channels. "Provable" means the boot is attested and the record signed, never that the model behaved.

What this PR does not do

• Run on the Surface, the Mac, or nested in a cloud VM: it needs bare-metal AMD EPYC (or Xeon with TDX). Cloud confidential VMs are a machine, not a host for our VMM.
• Inference as evidence (Horizon: one memory hierarchy).

Merge requirements

• A verifier checks the report before accepting a boot's chain.
• Measurement: attested boot time and memory per machine, against the unattested machine.
• Caveats: Cloud Hypervisor with SEV-SNP has no memory or CPU hotplug, huge pages or virtual IOMMU, and SEV-SNP and TDX cannot share one build.

[1zeroone0]

post-training: an open model trained on cead's logs

Spec: none new; it reads what the log already holds.

What this PR does

• Post-trains an open model as an RLM, as the RLM work does, on cead's own logs.
• Each log replays every window exactly (Run one job end to end as a recursive language model #13, Q29), so every model call is a (state, action) pair taken from signed records, not a scraper's reconstruction.
• Call records name their process, and spawning decisions their child (Run one job end to end as a recursive language model #13, Q25), so each sub-call's part in the outcome is attributable, under its meter.
• Turns and token counts are exact, so returns and costs come straight from the log.
• Rollouts: K boots forked from one snapshot (Horizon: machine fork). Evals: N machines from one manifest (Horizon: scale-out).
• On attested boots, the training data's provenance is attested too.
• Leaning: the log's format is the training format; no second export.

What this PR does not do

• Engine control or KV routing (Horizon: one memory hierarchy), beyond what training needs.
• Claim anything a measurement hasn't shown.

Merge requirements

• A model trained on cead's logs, evaluated against its base on held-out tasks; its lift reported with the harness held fixed.
• Open: which open model; where training runs (prime-rl, as the RLM work used, or another); reward from the grader alone or also from cost; how much of a run's log is training data vs audit only.