Themis verified SRv6 networking

The packet carries
its own itinerary.
Nothing on the path checks it.

Audit what runs today. Simplify the fabric under it. Prove the path was taken.

Book 30 minutes read-only · on your own kit
Declared intent sits above the path, unconnected to it An amber band of declared intent runs across the top. Dotted lines reach down from it toward the network path below, but each one ends in a red cross before it arrives. On the path, a packet carrying its own segment list runs left to right straight through three hops. Nothing on the path compares the packet to what was declared. declared intent the segments you approved · versioned nothing compares the path as it runs pe p pe 0100:0200:e000 the itinerary rides in the address · no hop holds it against what you declared

0100 audit

Three things that should agree — and don't.

Intent, configuration and traffic are written down in different places, by different people, at different times. They drift quietly, and nothing in the estate is holding them against each other.

Too permissive

A rule outlives the reason it was written.

The service moved, the project ended, the exception became permanent. Nothing was watching the reason — only the rule.

Too brittle

A rule blocks the flow it never saw.

The failover, the nightly job, the rare third-party call. Learned from observed traffic — and observed traffic is never the whole story.

Every audit is an attempt to reconstruct that gap by hand, months late.

69%

of firewall rules are unused FireMon Insights 2.0 · Jun 2026

23%

of impactful outages come from an IT or networking change Uptime Institute Annual Outage Analysis 2025

241

days to identify and contain a breach, on average IBM Cost of a Data Breach 2025

Industry baselines shown, not our results. The first read-only pass measures yours.

0200 engine

Audit first. Then identity. Then proof.

One engine, five steps. It sits above whatever already enforces in your estate and starts by reading, not writing.

01

Audit

Flow against intent, read-only, on what you already run.

02

Locator

The addressing plan and the routes to reach it. Strands nothing.

03

Segment

Least-privilege policy by role — and the path it must take.

04

Verify

Against traffic it never saw. Against the path actually taken.

05

Approve

Enforce only what survived. A person decides the sensitive cases.

Every step is independently useful. You keep the output even if you stop after the first one.

0300 verify

A policy is trusted only once it survives traffic it never saw.

Learning a policy from observed traffic looks perfect on the traffic it watched. Then the failover runs. The nightly batch runs. Someone breaks glass at 3am — and the flow that was never in the window gets dropped.

So the policy is scored against a held-back set and an adversarial set before it goes anywhere near enforcement. The separation is mechanical, not procedural: the drafting stage has no path to the held-back data. That is what makes a pass mean anything.

A policy is scored against traffic the drafting stage never had access to Observed traffic feeds a drafted policy along the top. A dashed line below it marks a boundary the drafting stage cannot cross. Beneath that boundary sit a held-back set and an adversarial set. Both the draft and the held-back traffic feed a scorer on the right, which yields either a pass that enforces on one slice, or a fail that returns a gap list rather than an outage. observed window draft policy the drafting stage has no path across this line held back + adversarial traffic it never saw score PASS enforces on one slice, then widens by declaration FAIL returns a gap list, never an outage a new flow never silently becomes allowed · only a declared change may widen · a denied probe is a security event, not a candidate rule

Every gate is shown going red on a seeded defect before anyone is asked to trust it.

0400 evidence

The page you hand the auditor.

Not a dashboard nobody logs into. A dated artifact, generated continuously from the platform's own history, per scope and per tenant — the same one your customers' auditors keep asking you for.

Segmentation evidence — scope: payments-prod

window 2026-08-06 → 2026-08-13 · tenant t-4417 · generated on your infrastructure
5 roles · 18 declared paths · 1 escalation

verified
Enforced policy equals declared intent Every rule in force maps to a named, approved declaration. No orphans. pass
Policy scored against traffic it never saw Held-back and adversarial sets, run before enforcement, gate red on seeded defect. pass
Rules retired conservatively 3 unused rules proposed for retirement; each held its full observation window first. pass
Cross-tenant reachability No path observed between t-4417 and any other tenant scope during the window. pass
Sensitive flow awaiting a named human cardholder-db → reporting: proposed, not enforced. Queued for approval since 08-11. escalated
Undeclared segment executed Per-segment counters across the window. A provable negative, not an absence of alerts. none

every decision below carries user · time · event — approve, reject, retire
window digest sha256:9f2c…a41d · raw flows never left the site

Sample artifact, lab topology. Shape and fields are real; the numbers are not yours yet.

What it answers, framework by framework

Where the artifact lands in the regimes operators are actually asked about.
RegimeWhat it asks forWhat the artifact carries
NIS2 / ReCyF Demonstrated network segmentation and control of change Continuous timestamped verification reports, per-rule justification, recorded human decisions
DORA ICT risk evidence, on demand, including from your providers An evidence pack per scope and per tenant, dated, reproducible from the ledger
SecNumCloud · HDS Tenant isolation you can show, not assert Machine-checkable proof that enforced policy equals declared intent, on your infrastructure
ISO 27001 · PCI-DSS A controlled change workflow with an audit trail Proposal → verification → approval → event log, each step stamped user · time · event

The claim is never “we make you compliant.” It is: we generate the segmentation evidence your auditors — and your customers' auditors — keep asking for, continuously, on your infrastructure.

0500 fit

Pick the estate you actually run.

The engine is the same in all four. What changes is which part of it you get paid for.

sovereign cloud · hosting · managed services

You already sell trust. This makes it a feature you can show.

Isolation proof per tenant, generated continuously instead of rebuilt by hand every audit season. The evidence pack becomes something you attach to the offer, not something you scramble for.

  • Per-tenant evidence packs — dated, reproducible, one per scope.
  • 100% on your infrastructure. Open substrate, air-gap capable, no data leaves. A US-SaaS control plane structurally cannot say that to your compliance customers.
  • A container in your tenant, on CPU. No GPU line item, no model in the verdict path — so it deploys in the estates that are not allowed to run one.
  • Provable segmentation as a differentiator on managed offers — and freed public IPv4 back into your inventory as a by-product.

e000 End.DT6 deliver

See it against your own kit.

30–60 minutes. Read-only. We compare your declared intent to what is actually running, and hand back the gap list.

Nothing is installed to have this conversation. Savings are computed from your own estate in the first two read-only weeks — never from our slides.

Why the name

Themis is the titan of divine law and natural order — the layer that holds what was declared against what actually happens. That is the whole product in one word.

Who builds it

Early-stage, based in Marseille, France. Founded by a carrier-backbone engineer — IPv6 and SRv6, firewall and NAT at Bell Canada — later Director of Platform & AI Engineering, growing an org from 10 to 60 in a year, with two startups founded and acquired.

Happy to meet in person in the south of France. Remote anywhere.

Book 30 minutes — read-only