Verified enforcement segments, then paths
Enforcement that emits its own evidence.
A firewall enforces, and then a second system has to prove that it did. A segment counts every packet that executed it — so with the path carried in the packet, enforce and verify collapse into one mechanism, and “no undeclared segment ever ran” becomes a number that reads zero.
This is the second product, and it is earned: it opens on evidence assurance already produced. It starts at endpoints you control, over any IPv6 transit, without touching a router — and it is reversible in one route change.
SRv6 / uSID earned, not sold entry is always the read-only audit
The data path is verified on stock Linux 6.8 — seventeen checks green, four documented limits, none failed, reproducible in three minutes. It has never run on an operator estate, or on router silicon. Every number on this page is a lab number and says so.
0100 why the fabric
Three things you cannot get by writing more policy.
Self-verifying enforcement
The segment that enforces the boundary is the segment that counts what crossed it. There is no second system to reconcile against the first, and the evidence is a by-product of forwarding rather than a report about it.
Assurance that stops sampling
Flow records are sampled, so evidence built on them describes the traffic it happened to catch. A segment counter increments on every packet. “No undeclared segment ran” stops being an absence of alerts and becomes a provable negative: the counter is zero, and zero is a measurement.
One control plane, and no per-flow state
One reachability decision stops being written five times. The core holds a block as a single prefix and forwards; the path lives at the ingress edge. State that used to scale with pairs of endpoints stops existing.
sampled→every packet
5→1
39,800→0
The first is the difference between a sampled flow record and a counter. The second and third are arithmetic about full-mesh topologies, presented as arithmetic. None of them is a measurement of your network.
The honest description is that the destination address has become a program counter.
0200 segments — where it starts
At the endpoints you control. Never as a core project.
Verified segmentation begins on a scoped perimeter — a set of critical applications, an IT/OT boundary, one data-centre domain — terminated in the Linux kernel on gateways, cluster nodes or VMs, over whatever IPv6 transit is already there, including one you do not own. No router is upgraded to begin.
End to end, once the path is declared
0300 paths — where it leads
Prove the traffic took the path you prescribed.
Once segments prove themselves, the question grows. Not can A reach B, but A must reach B through this authorised path — this service chain, this geography, this jurisdiction. Encryption proves who the two ends were. It never proves where the packet went between them.
Classic routing is emergent: the path is observed after the fact, never declared, with no artifact to check against. The segment list is the declared path, written into the packet — explicit, diffable, machine-readable.
Themis compiles the path policies; your controller applies them; per-segment counters say whether each one was executed — including the negative. In the lab: 100 packets sent, 100 counted at each declared segment, zero at the undeclared one.
With a segment list, comparison stops being interpretation and becomes a set operation.
23%
of impactful outages now come from IT and networking issues Uptime Institute · Annual Outage Analysis 2025 (2024 data)change management and misconfiguration
85%
of human-error outages trace to procedures not followed, or flawed Same report · nearly 40% of organisations had one in the last three years241 days
mean time to identify and contain a breach IBM · Cost of a Data Breach 2025the window a rewritten path stays invisible
Who it is for: carriers and interconnects, sovereign and regulated workloads, service chains through inspection, slices. Path control needs assurance underneath it — the estate map, the groups and the approvers are what make a path verdict mean anything. A carrier already running SRv6 traffic engineering walks from assurance to path control directly, without segmenting first.
0400 the boundaries
What we publish rather than discover in production.
The useful output of the lab work was not the passes. It was the boundaries, and they belong in the plan before they belong in an incident.
0500 the bridge
The plan carves instructions, not labels.
Between assurance and a first perimeter sits a plan, not a change window: the fabric simplification and migration plan, delivered as a project with your network integrator. It is the bridge, never the gate — and the audit is what tells you whether it is worth crossing.
Plan against the live routing table
The locator block, the per-node locators and the per-function segments are a solved allocation, derived from the estate the audit already mapped and proposed against the routes you actually have.
Routes and segments as code
The plan is an artifact under version control, reviewed like code, with one approved write path to the network — and that path is yours. Every change is a proposal that passes the same gate.
The strands-nothing check
A reachability proof run before anything is applied. If the plan would isolate a prefix, a tenant or a management path, it fails here rather than at 03:00 on a change night.
The transition case is simplification, not renumbering. Reversible at every step, and each step independently useful.
e000 End.DT6 deliver
Start where it is already provable.
The entry is the read-only audit on what runs today — 30–60 minutes, on your own kit, and you keep the gap list either way. The fabric is a later decision, taken on your own numbers.