Last updated: September 25, 2026

Capabilities and Their Evidence

Transcribed from the production blueprint in the Go repository. A label changes only when new evidence changes it — never because code exists.

How are capabilities labelled?

Decentralized.Host files each capability under one label: VERIFIED (exercised by an automated test with real processes and failures), LIMITED (works with a stated limitation), NOT IMPLEMENTED, or NOT RUN. All VERIFIED results so far come from one macOS machine over loopback.

Source: docs/BLUEPRINT.md
VERIFIED15

Implemented and exercised by an automated test or chaos scenario with real processes, sockets and failures (single-machine scope unless stated).

LIMITED6

Works, but with a stated limitation or narrower evidence than production needs.

NOT IMPLEMENTED3

Absent. Where the system can detect the gap, it reports it.

NOT RUN1

The tooling exists, but the run that would establish the claim has not happened.

Every automated run so far is multi-process on one macOS machine over loopback. No test has crossed physical machines, a real WAN or NAT, or run on a Linux host. Linux validation (PV1-S1-A03) is pending.

M1

Hosts admit work under their own policy

VERIFIED

Every assignment passes 18 ordered checks on the host before anything runs: signatures, audience, generation, clock, capability chain, revocation, freeze, freshness, tier, runtime, digest, attestation, federation and resource caps. The control plane proposes; the host decides.

evidence: pkg/node/sovereignty_test.go — a host refuses a control plane that holds a genuine member key
$ dh describe app web

Signed observations, replay and rollback refused

VERIFIED

Hosts report what they actually measured in Ed25519-signed observations with monotonic sequence numbers. Replayed, forged or stale-generation messages are rejected, and signed bundles carry a state index so the control plane cannot be rolled back.

evidence: tests/integration/m1_test.go; chaos replay-forgery, stale-generation

Control-plane outage is not a workload outage

VERIFIED

If the control plane is frozen, unreachable or stale, admitted work keeps running (hold, not stop), new admissions are refused, and observations queue in an outbox that flushes on recovery.

Limitation: One M1 subtest ("host-mode offline-hold" ledger entry) failed intermittently in 2 of 3 full-suite runs on 2026-09-24 and has not reproduced since. The cause is not established; it stays open until explained.

evidence: chaos cp-total-outage (854/854 requests OK); m1_test.go

Hash-chained audit you verify yourself

VERIFIED

The control plane keeps a hash-chained ledger with signed checkpoints, and every host keeps its own fsynced journal. `dh audit verify` fetches the ledger and verifies the chain locally; backups and exports verify offline.

evidence: pkg/audit tests; 14 conformance vectors; chaos journal-corruption
$ dh audit verify

M2

Content-addressed volumes with committed snapshots

VERIFIED

BLAKE3 content addressing with FastCDC chunking, verified on every read. Snapshots commit only when 2 replicas return signed evidence; an interrupted write rolls back to the last committed snapshot, and a lost host is restored from peers byte for byte.

evidence: tests/integration/m2_test.go; chaos interrupted-storage-write, storage-replica-loss, disk-full

Merkle anti-entropy and repair

VERIFIED

Replicas compare 256-bucket Merkle roots and repair divergent or corrupt objects from peers, recording repair evidence per object. Corrupt objects are quarantined, not served.

evidence: chaos storage-replica-loss

Erasure-coded volumes

NOT IMPLEMENTED

Volumes are replicated. `durability.erasure` accepts only `none`.

evidence: pkg/manifest (validation rejects other values)

`dh volume snapshot` / `dh volume restore`

NOT IMPLEMENTED

Snapshots are automatic and restore happens through rescheduling; `dh volume export` downloads and verifies a committed snapshot. Explicit snapshot and restore commands do not exist yet.

evidence: docs/BLUEPRINT.md §4 M2

M3

Attenuable capability chains

VERIFIED

Authority flows as chains of Ed25519 blocks anchored in the cluster root: root → member, member → per-assignment capability bound to host, generation, digest and resource ceilings, expiring operator sessions, and single-use join tokens.

evidence: m3_test.go; 29 conformance vectors
$ dh token --read-only --ttl 1h

Host and root key rotation, emergency revocation

VERIFIED

Host keys rotate with dual signatures and a grace window; a single key can be revoked in an emergency; the root key rotates with the old root signing the rotation and assignments re-signed.

Limitation: Root key custody (offline signer or HSM) is a hardening item, not implemented.

evidence: tests/integration/m3_test.go

Userspace WireGuard mesh with gossip

LIMITED

wireguard-go on a gVisor netstack (no root, no kernel interface) with signed key bindings, and SWIM gossip inside the tunnel. Workloads are reached through per-assignment forwarders, not routed per-workload IPs.

Limitation: Many real host processes, each with its own identity and WireGuard device, but all on one machine. No cross-machine, NAT or WAN run yet (PV1-S2 and PV1-S4).

evidence: m3_test.go; chaos network-partition
$ dh mesh peers

M4

Health-gated L7 edge

VERIFIED

Edge hosts probe replicas over the mesh and route only to healthy ones, with routing / draining / ejected / pending states. Hung replicas are ejected; rolling updates are make-before-break for stateless replicas.

evidence: m4_test.go, m5_test.go; tests/integration/rollout_test.go (0 of 139 requests failed)

Automatic TLS via ACME or the cluster CA

LIMITED

HTTP-01, DNS-01 and wildcard issuance, with certificate state (REQUESTED … ISSUED … UNKNOWN) reported in observations.

Limitation: Verified only against Pebble, locally. Never exercised against a public CA or public DNS (P0-3).

evidence: pebble_test.go

HTTP/3

NOT IMPLEMENTED

Not implemented; the edge reports `UDP 443: NOT LISTENING`.

evidence: docs/BLUEPRINT.md §4 M4

M5

Replicated control plane (Raft, mutual TLS)

VERIFIED

Three or five members, a deterministic state machine, a leader-only bundle issuer, membership changes and leadership transfer. Leader loss does not interrupt workloads.

evidence: m5_test.go; chaos leader-crash — 1.2–2.2 s to a new leader, 0 failed requests (single machine, loopback)
$ dh cp status

Signed backups and total-loss restore

VERIFIED

Control-plane backups are signed, verify offline, and restore into a freshly bootstrapped cluster after losing every member.

evidence: m5_test.go
$ dh cp backup --out cp.json && dh verify backup cp.json

Cross-cutting

TLS from the first start

VERIFIED

Members serve TLS before they have credentials; bootstrap pins the throwaway certificate by fingerprint, then members serve root-issued certificates. Hosts join over HTTPS with a token that pins the root, and Raft uses mutual TLS.

evidence: tls_test.go; validation/pv1/tls-install.sh (the install runbook, scripted)

Process and Docker runtimes

LIMITED

Run a signed executable from the cluster CAS (`process`) or a digest-pinned container image (`docker`, with enforced --memory/--cpus and OOM detection).

Limitation: The process runtime does not enforce CPU or memory limits and says so in admission details (P0-6). containerd, gVisor and Firecracker are not implemented.

evidence: pkg/runtime; chaos oom (Docker)

Operator console served by the cluster

LIMITED

14 screens served by every control-plane member with no third-party requests. Desired, admitted and observed state are separate everywhere; every value carries a truth basis (OBSERVED, DERIVED, CONFIGURED, PLANNED, UNKNOWN); a stalled view turns into LAST KNOWN STATE — NOT CURRENT.

Limitation: No automated browser test suite or accessibility audit yet (P0-7).

evidence: web/dist; checked manually in a live browser
$ dh console --read-only

Signed, secret-free export

LIMITED

`dh export` writes manifests, rosters, trust configuration, host records and policies, volume metadata, artifact references, audit and federation state; `dh import` verifies and re-applies it.

Limitation: No automated export → import → equivalence test yet (P0-5).

evidence: cmd/dh

No SaaS dependency, no telemetry

VERIFIED

No outbound calls except those the operator configures (ACME, optional Postgres mirror). The console CSP is default-src 'self'.

evidence: by construction and header tests; no traffic audit yet

M6

17 chaos scenarios on real disposable clusters

VERIFIED

Leader crash, total control-plane outage, host crash, agent restart, journal corruption, network partition, packet chaos, clock skew, stale generation, replay/forgery, revoked host, storage replica loss, disk full, OOM, interrupted deployment, interrupted storage write and Postgres outage — each under traffic with invariants checked and a signed report.

evidence: dh chaos run --scenario all (17/17 in REF-MAC-A03)
$ dh chaos run --scenario leader-crash

Long-duration soak

NOT RUN

`dh chaos soak` exists but has not been run on the final build. The target is 24 hours under traffic on a multi-machine cluster (P0-2).

evidence: docs/BLUEPRINT.md §4 M6

M7

Federation between independent clusters

VERIFIED

Root-signed agreements let one cluster grant another bounded capacity. Placements are re-signed by the grantor, hosts still apply their own policy (quotas, allowFederated), and revocation stops the work.

evidence: tests/integration/m7_test.go (two clusters with separate roots, one machine)
$ dh federation grant --to peer --to-root KEY --out grant.json

M8

Published protocol with conformance vectors

LIMITED

The dh/v1 specification, 136 test vectors, an adapter-protocol runner, and an independent Python implementation that passes canonical JSON, identity, envelopes, audit, capabilities, chunking and Merkle roots.

Limitation: Manifests, admission decisions, bundle verification and mesh bindings are specified but not yet pinned by vectors (P1-4).

evidence: dh-conformance; go test ./pkg/conformance; conformance/python
$ dh-conformance run -self

The 17 chaos scenarios

From dh chaos list. Topology is control-plane members / hosts / edges; every scenario runs on its own disposable cluster, under traffic. All 17 passed in REF-MAC-A03 — on one machine.

ScenarioTopologyInjectionInvariant checked
leader-crash3cp/3h/1eSIGKILL the raft leader while traffic flows through the edgea new leader is elected, committed writes survive, new writes succeed, and no workload request fails
cp-total-outage1cp/2h/1eSIGKILL every control-plane member for 15s, then restarthosts enter offline-hold, admitted workloads keep running with the same PIDs, no request fails, buffered observations are delivered after recovery
host-crash1cp/4h/1eSIGKILL a host agent and all of its workloads (machine loss)the edge stops routing to the dead replica without failed requests, the host is marked lost, and the replica is rescheduled and observed running elsewhere
agent-restart1cp/2h/0eSIGKILL dh-noded only (workloads keep running) and restart itthe restarted agent re-adopts every workload by PID and kernel start time without restarting it
journal-corruption1cp/2h/0estop a host agent, flip bytes inside one entry of its hash-chained journal, restart itthe host detects the named break, enters ledger-corrupt mode, keeps admitted work, refuses new work, and never appends to the broken chain; after the local operator seals the journal (kept byte-for-byte) the host admits work again and its new chain records the break
network-partition1cp/4h/1edrop every WireGuard packet to and from one host at the fault proxies and cut its control-plane channel for 25s, then healthe isolated host keeps its admitted workload, gossip suspects it, the control plane marks it lost and reschedules, no request fails, and after healing the cluster converges to exactly the desired replicas
packet-chaos1cp/3h/1eon every WireGuard path: 5% loss, 10% duplication, 10% reordering, +40ms delay for 20sWireGuard and TCP absorb the faults: no request fails, the measured mesh RTT reflects the injected delay, and it returns to baseline when faults are cleared
clock-skew1cp/2h/0eshift one host's clock +120s, then −120s, then restorea skewed host detects it from signed bundle timestamps, holds admitted work, refuses new work (CLOCK_SKEW / stale plane), and returns to normal when the clock is corrected
stale-generation1cp/3h/1ecut one host from the control plane, roll the app to a new generation, healthe cut-off host keeps the generation it admitted (never runs an unsigned one), the console shows it as stale, other hosts roll within maxUnavailable, and after healing every replica runs the new generation
replay-forgery1cp/2h/0eresend a committed host observation; send one signed by a foreign key; send one with a flipped fieldeach is rejected with a specific reason and recorded; the host's real state is unchanged
revoked-host1cp/4h/1erevoke a host that serves a replica while traffic flowsthe revoked host keeps its admitted workload but is removed from the mesh and the edge routing table, the replica is rescheduled, and no request fails
storage-replica-loss1cp/4h/1edelete every stored object on one replica host while it runsanti-entropy detects the missing objects by Merkle comparison, repairs them from peers with signed evidence, and the volume returns to HEALTHY with identical data
disk-full1cp/4h/1emake every new write on one replica host fail with ENOSPC (storage-layer injection), write new data, then clear itthe volume is reported DEGRADED — never falsely HEALTHY — while the replica cannot store data; writes still commit on the other replicas; after the disk frees, anti-entropy restores HEALTHY
oom1cp/1h/0erun a container limited to 32 MiB that allocates without boundthe container runtime kills it (OOMKilled=true), the host reports oom-killed from runtime evidence, audits it, and restarts it with backoff
interrupted-deployment3cp/3h/1eapply a new generation and SIGKILL the raft leader as soon as the first replica has rolledthe new leader resumes the rollout, it completes, and requests keep succeeding (maxUnavailable respected)
interrupted-storage-write1cp/4h/1ewrite 24 MiB, then SIGKILL the primary host (agent and workload) while the new snapshot is still pendingcommitted data is intact after recovery, and the interrupted write is either fully committed or absent — never partial
postgres-outage1cp/1h/0estop the Postgres evidence mirror, keep operating, restart itwhile Postgres is down the console reports JOURNAL ONLY (never DB COMMITTED), writes still commit through raft, and the mirror catches up to DB COMMITTED after recovery

Source of truth: docs/BLUEPRINT.md. If this page and the blueprint disagree, the blueprint wins.