Two planes, one signed bus

A platform that configures and authorizes active tests against a client’s systems holds two very different kinds of power: the authority to decide a test may happen, and the capability to make it happen. If one component holds both — or if the two share a database or an HTTP API — then compromising either one can forge orders or leak the client directory.

So ROOTVIEL is two planes. The control plane handles identity, authorization, scheduling, human approval, audit, and the cryptographic signing of intent. The execution engine only verifies and executes what the control plane signed; it runs no scanners on the control plane’s behalf and chooses its own time slot. The two share no HTTP API and no database.

The planes communicate exclusively through an event bus whose messages are signed with Ed25519. Each request message is self-sufficient: it carries a signed snapshot of the execution context — the connection, the authorization, their revisions and expiry — so the engine never has to call back to the control plane. There is deliberately no client that reads state across the boundary; the resolvers read from the message.

When an operator requests an assessment, the signed envelope is written to an outbox table in the same database transaction as the state change. A separate relay process publishes it to the bus; the engine’s scheduler verifies and schedules it. Because the write to the outbox and the state change commit together, the database and the bus can never diverge.

Delivery is at-least-once by design — publish, then mark — so duplicates are possible and safe: a per-event identifier is the engine’s anti-replay guard. This is the standard, honest alternative to the myth of exactly-once delivery.

1. 1Operator requests an assessment; the use case validates the catalog and the Rules of Engagement.
2. 2The signed envelope is written to the outbox in the same transaction as DRAFT → REQUESTED.
3. 3A relay process (holding no signing key) publishes it to the bus.
4. 4The engine verifies the signature, the audience and the purpose, then schedules.

Signing uses pure Ed25519 (EdDSA): the whole message is signed, not a digest. The private key lives in a key-management service and is never exported — signing is a remote call. The signer interface has exactly two operations, sign and read-the-public-key, and deliberately no "export private key": the absence of that operation is the invariant. The key identifier is derived from the public key itself, so a new key is simply a new identifier with no coordination.

A signature also does not transfer purpose. Every event carries an audience and a purpose; a signature minted for one channel is rejected on another. A validly signed request replayed at the wrong channel is refused — a signature proves who wrote the bytes and that nobody altered them, not that applying them elsewhere makes sense.

Audit is not logging. Logging is sampled, rotated and for debugging; audit is unsampled security evidence. Each audit record chains to the previous one by hash, computed with a canonical serialization so it is reproducible in any language. The database enforces append-only independently of the application: a trigger rejects updates and deletes even for the table owner. "Who authorized this, and when?" stays answerable, unforgeably, years later.