/docs/roadmap

Roadmap: what is built and what comes next

nd7 is staged so that each phase produces something useful on its own and each later phase is generated from the data of the earlier ones. This page sets out the four phases, says which parts of Phase 1 are finished and which are not, lists the things that are deliberately not being built right now, and states the limits plainly. It follows VISION.md, PHASE-1.md and the README.

The four phases#

Phase 1 — audit, intent. Record what the agent said it was going to do, from the agent runtime's own event stream. For Claude Code that is hooks: prompts, tool calls with full inputs, tool results, session boundaries. Each entry is stamped, sequenced and hash-chained with BLAKE3 into an append-only per-session log. This is deliberately the weakest form of evidence, and every entry says so through its source field. It was chosen to go first because it needs no privileges, works anywhere Claude Code runs, ships in days, and forces the schema and storage decisions that everything else depends on.

Phase 2 — audit, effects. Observe what actually happened, attributed to the agent's process tree, from the kernel: Endpoint Security on macOS for process, file and network operations; fanotify for file events on Linux — its manual page describes an API that "provides notification and interception of filesystem events" — with seccomp-notify or eBPF for exec and network, chosen per kernel version. Effect entries land in the same session log with source: effect:*. The details stored since Phase 1 for matching the two — timestamp, working directory, command arguments, paths, process identifiers — let a reader line up "the agent said rm -rf build/" with "process 4812, a child of the agent, unlinked 213 files under that path". Where the two disagree, the log shows it. Planned.

Phase 2b — cross-machine continuity. Agents connect to other hosts. When they do, a remote nd7 records into the same session and streams or ships entries back, so the session remains one timeline under one session_id. Planned. This is why session_id is the top-level key and why host is in the envelope from the first entry.

Phase 3 — enforcement. Derive confinement from recorded sessions instead of writing it by hand: which paths a workflow touched, which hosts it connected to, which programs it ran, turned into Seatbelt profiles on macOS and Landlock rulesets on Linux, plus credential proxying and network filtering. Rules generated from observed behaviour are tighter and less wrong than hand-written ones, and the log says exactly why each rule exists. Partly built, in its hand-written form — see below.

Phase 4 — undo. Revert what an agent did. File contents first, from a copy of each file taken at the moment an effect entry shows it is about to be written (its pre-image), rather than a whole-tree snapshot at session start. Later, service and system state: restore the configuration and reload the daemon. The log must report honestly what cannot be reversed — a sent email, a pushed commit, a deleted remote branch. Planned.

The order is observe, then enforce, then undo. Enforcement without observation means hand-written allow-lists that are either too loose or break the agent. Undo without observation means whole-session snapshots that cannot tell an agent's change from a person's.

Where things stand#

Built and working:

  • The recorder. nd7 record as a Claude Code hook, one entry per hook invocation, all 33 documented events parsed, six with typed bodies and the rest kept whole.
  • The chain. BLAKE3 prev and hash per entry, the genesis bound to the session id, a head sidecar, an advisory lock per session, stale-head repair, and nd7 verify.
  • The sandbox. nd7 run claude applies one kernel-enforced profile to Claude Code and everything it spawns; nd7 allow and nd7 deny widen and narrow it while the session runs. macOS only. This is the first piece of Phase 3, arriving early and hand-written rather than derived.
  • Shipping. nd7 enroll and nd7 ship push encrypted sessions to a vault. The machine side is implemented here; the server and browser viewer live in a separate repository, where the admin command line was being written at the time the document was last updated, and the end-to-end acceptance run had not yet happened.

Not finished, with the remainder noted in PHASE-1.md:

  • Real-payload fixtures for Write, Edit and Read are still to be captured. The Bash response shape and the parent-pid behaviour were verified against real payloads; those three are still from the documentation's examples.
  • Release hygiene is partly done: continuous integration runs formatting, lint and tests on macOS and Linux, and the licence is MIT.
  • The reader was dropped, on purpose. nd7 sessions and nd7 show were planned and then cut: the consumers of the log are programs — the later phases' rule derivation, and the vault's viewer — not a terminal timeline. jq and tail -f cover development.

Explicit non-goals right now#

From the README, in its own words: Endpoint Security, undo, remote hosts, a server, a user interface, a daemon.

Deferred to Phase 2 and not on the Phase 1 list: signing, compression, dictionary interning (replacing repeated strings with short references), a binary container, a Codex adapter, and a long-running writer daemon.

Deliberately out of scope for the vault's first version: search, dashboards, alerting, secret detection, role hierarchies beyond admin, multi-region, and any change to the entry format.

Honest limits today#

  • The log records intent, not proof. An entry says what Claude Code reported it was about to do and what it reported back. It is not evidence of what ran on the machine. Kernel-observed effects are Phase 2.
  • A clean nd7 verify proves less than it looks like. It proves the file is unchanged since its last entry was written, if you trust the head. Anyone with write access to the directory can rewrite the whole chain. Shipping a copy to a vault the agent cannot reach is the answer that exists today; a signature field is reserved and not implemented.
  • The schema is a draft. Entries carry v: 0 and fields may change until the schema is marked v1.
  • The sandbox is new and macOS-only, tested on macOS 26 with Claude Code 2.1.x. Linux is Tier 2 and not built; it is planned to use Landlock.
  • nd7 allow reaches Bash commands, not the Write and Edit tools, which run inside the claude process and see only the rules the session started with.
  • Network filtering is by port, not hostname. HTTPS on 443 and DNS are open; nothing else is. Claude Code's own hostname filtering is lost under nd7 until nd7 has a proxy.
  • The sandbox rules are hand-written and permissive in one place: any program may be executed inside the boundary. An exec allowlist derived from recorded sessions is the stated next step, and the README says the policy will tighten as recorded sessions show what is actually needed.
  • ps and pgrep are denied, and git over SSH does not work under the sandbox while git over HTTPS does.
  • Codex and other agents are planned, not built. The architecture describes where they attach — the same entries with a different source — and nothing for them exists today.
  • The whole thing is pre-alpha.

Open core#

The engine — the recorder, the format, the reader, the verifier, and later the kernel collectors and rule generators — is open source, under MIT. A future paid product is per-organisation secure storage, access control and search over these logs.

Three consequences that already shape the code: the log format is the contract and must stay stable, versioned, streamable and self-describing, with every entry saying what schema it is; nothing in the open engine may assume a server exists, so local files are the first-class store and upload is a separate component; and signing, compression and interning are designed for in the format through reserved fields, without being implemented.

Updated . This page as Markdown · Source on GitHub.