The Sovereign Interface

§1 The Boot Problem

Most operating systems and application frameworks treat startup as an opaque event. A user clicks an icon; some time passes; a window appears. The interval between intent and interface is a black box — filled with dynamic linking, configuration parsing, service discovery, and dependency resolution, none of which is visible to the user or instrumentable by external tooling.

The problem compounds in distributed architectures. A microservice mesh may have dozens of health checks, but no single command that answers: is the whole system alive, and how long did that take to determine?

We propose a boot protocol — s_wake — that makes every phase explicit, measurable, and fail-visible. The protocol has four phases:

Each phase has a clear success/failure signal. No phase is hidden behind a package manager or build system. The binaries are pre-compiled; the heartbeats are nanosecond operations wrapping millisecond I/O.

§2 The Heartbeat Sweep

The core insight is that health verification should be cheaper than the thing being verified. A cargo invocation (even with cached builds) costs 300–800ms of overhead per call. A direct binary execution costs 3–10ms. For 14 nodes, that is the difference between 10 seconds and 600 milliseconds.

Each hub binary accepts --heartbeat, which boots its stage registry, runs a zero-input pulse through every declared path, and reports alive/dead counts. The pipeline DAG is the test harness: if a stage can instantiate and accept a null pulse, it is alive.

The fourteen hubs span five workspace roots (core, rings, storage, devtools, ui), each with its own Cargo workspace. The heartbeat binary lives inside each workspace's target directory — built once, executed many times.

§3 The Mesh

Once heartbeats confirm liveness, the system activates the PulseMesh — a shared-memory transport layer for typed envelopes. Each hub enters its tick loop, reading and writing PulseEnvelope structs through memory-mapped ring buffers.

Envelope Anatomy

The mesh operates on a broadcast/listen model. Hubs declare their listen filters — type-name prefixes like chamber/* or canon/* — and the hub's tick loop delivers matching envelopes without serialization. The memory is shared; the types are zero-copy.

This is not TCP. There are no sockets, no serialization, no buffering. The ring buffer is a mmap'd region with atomic read/write cursors. Latency is bounded by cache-line transfer time, not kernel syscall overhead.

§4 From Shadow to Glass

The traditional path from storage to screen is: filesystem → web server → HTTP → browser → DOM. Each layer adds latency, attack surface, and opacity.

The sovereign path is: Shadow (redb) → Library → sov:// protocol → wry WebView → native window.

The Shadow Store

Documents are stored in library.redb — an embedded key-value store backed by redb. Each document carries:

• Body — the raw HTML content
• Metadata — sov:id, domain, section, tags, date, status
• Content hash — SHA-256 for integrity and change detection
• Kronos event — audit trail entry with timestamp and actor
• Embedding — 768-dimensional vector (nomic-embed-text, i8-quantized)

There is no filesystem path. The document's identity is its sov:id, and its body is retrieved by key, not by path traversal.

The Sovereign Protocol

The native window registers a custom protocol handler — sov://localhost/* — that intercepts all navigation requests. Instead of hitting a web server, the handler:

1. Checks Shadow for a matching document (by path reverse index)
2. Falls back to disk if not in Shadow
3. Serves the content with correct MIME type directly into the WebView

No HTTP. No TCP. No port binding. The WebView renders the document as if it came from a server, but the data never leaves the process.

§5 The Control Plane

The final layer inverts the typical relationship between an AI agent and the system it operates on. Instead of the agent reading files and running commands — treating the system as a bag of text — the agent connects through a typed control plane.

Architecture

The MCP bridge exposes three mirror-specific tools:

The protocol is newline-delimited JSON over a Unix domain socket. One MirrorAction per line in, one MirrorMessage per line out. The socket listener runs on a dedicated thread; the action processing shares the same SharedState and MirrorBackend as the webview IPC handler.

§6 Empirical Evaluation

The claims above are architectural, not empirical. To validate them, we propose five benchmark suites:

6.1 Boot Latency

Measure end-to-end time from app icon click to first UI paint, broken down by phase (heartbeat, mesh start, mirror launch). Compare against Electron app cold start (VS Code, Slack) and native app start (Finder, Terminal).

Methodology: instrument sovos-boot with per-phase timestamps. Use hyperfine for repeated trials. Measure Electron baselines with time open -a "Visual Studio Code".

6.2 Heartbeat Scalability

Plot heartbeat sweep time against node count: 2, 4, 8, 14, 28, 56. Establish whether growth is linear or shows cache/scheduling artifacts. Compare direct binary execution against cargo run at each scale.

Hypothesis: linear up to ~28 nodes (fits in OS process cache), then sub-linear due to process spawn batching by the kernel.

6.3 Document Integrity Round-Trip

Store 100 HTML documents in Library/Shadow. Mutate 10 on disk. Verify that: (a) Shadow detects staleness via content hash, (b) Kronos audit trail captures all mutations, (c) Merkle root changes are detectable. Measure false-positive and false-negative rates.

This tests the integrity guarantee of the Shadow store — not just that it stores documents, but that it detects tampering.

6.4 MCP Action Latency

Measure round-trip time for MirrorAction through the UDS bridge: agent → sov-mcp → UDS → mirror-native → response. Compare against direct wry IPC latency (in-process callback). Establish the overhead of the bridge layer.

6.5 Mesh Envelope Throughput

Saturate PulseMesh with typed envelopes from N producers to 1 consumer (mirror). Measure messages/sec and latency percentiles (p50, p99). Compare against TCP loopback and WebSocket equivalent payloads.

This validates Proposition 3.1. If shared-memory throughput is not significantly higher than TCP loopback, the architectural complexity is not justified.

§7 Synthesis

The table below maps each architectural claim to its implementation in the sovOS codebase.

Every row in this table is a running system component, not a proposal. The boot protocol has been timed. The heartbeats have been counted. The documents are in Shadow. The socket is open. What remains is the empirical validation proposed in §6 — and the continued development of the system itself.