Documentation embedded in this build.
Move labeled data only to the services cleared for it
In short
Send a feed of labeled records down one long-lived connection to two services cleared to different levels. The front door decides each record on its label alone, never buffering, parsing, storing or opening one, and signs a receipt for each batch it delivers.
What it is for
You have a feed — readings, events, records coming off a collector — and two places it has to go that are cleared to different levels. Point the producer at the front door and let it write records down one long-lived connection. Each record carries a small label, and the door decides on the label alone: it never buffers the record, never parses it, never stores it and never opens it.

Each destination is an identity of its own with its own certificate, and the level it is cleared to comes from the same directory everything else here comes from — so a record labeled above a destination's level is not sent there, the refusal is written down naming the destination, and the record still reaches the destinations that may have it. You do not have to run a flow engine to get that, and you do not have to trust one.
How the door proves it
The door signs a receipt for each batch it delivers to each destination, and every record is chained to the one before it, so a destination can prove exactly what it was given, in order, with nothing missing — from one signature rather than one per record. If the contents should be hidden from the door as well, the producer can seal each record to exactly the destinations its label will reach, and the door never holds a key that opens one. And when the producer's certificate is revoked or its standing changes, the connection is closed and the reason is recorded: this is not a permission granted once and honored for a year.
This is not a message broker or a data pipeline. Nothing is stored, replayed or transformed.
The topology
One producer, one connection, and a door that reads labels and never bodies.
+--> INGEST, cleared higher
PRODUCER ==one long-lived connection==> | gets the record labelled higher
labels each FRONT DOOR | + a signed batch receipt
record reads the |
label, never +--> INGEST, cleared lower
the body | does NOT get that record
| the refusal is written down
One producer, one connection, two destinations, one receipt per batch per destination.
Stand it up
$ docker run --rm authboxus/authbox-eval -evaluate -scenario door -print docker | sh
A front door in front of it: the door that compares the labels is that evaluation's, on its own image, deciding from the bundle the box publishes; a stream route is a route of that door with a stream setting on it. What no evaluation carries yet is a feed: the producer and the two ingest services cleared at different levels are the worked composition's demonstration applications, which are not published, so the stream itself is proved from the source and described here. The evaluation runbook says what that evaluation stands up.
What the smoke proves
The composed run stands both destinations up as real containers with real certificates, at two different levels, behind the real front door, and streams records through them. What only a running composition can show is that the label the producing library writes is the label the door reads — two implementations of one grammar — that the levels being compared are the staged deployment's own, and that the door's own entity is a link in the chain rather than a bystander. Each mechanism's own behavior is proved in Go beside it.
A rehearsal drives that composition for a couple of minutes under load and renders its report, so the property is exercised at a cadence rather than once. And the distribution half of the same story — what the door compares against had to get there somehow — is two instances, each its own authority, with a signed bundle adopted live by the second and a write relayed as the caller and decided where the record lives.
Read on
- The operator runbook is authorized stream operations, in the operator guide: a stream route inherits the door's bundle, its revocation lists, its receipt key and its reserved paths, and that page adds only what a stream does on top of them.
- The sealed records scenario is the shape to read when the contents must be hidden from the door as well.