A record that holds, and a decision that stays with the people who own the risk.
Reign Assurance is being built with the control functions that will have to rely on it: which checks, which exceptions, in whose format. The concept is Continuous Agentic Assurance. This page describes what it is being designed to do, and what it is not.
Every claim on this page is written in the design tense on purpose. Where a thing is not built, we say so.
Scope, requirement, check, evidence, and only then a claim.
Assurance for automated work is usually treated as a reporting problem. It is not one. What a reviewer, a regulator or a board needs is five things answered in a fixed order — and answered out of order, the last one will be wrong, because a check cannot be judged without the requirement it serves, and a requirement cannot be judged without the scope it sits in.
The check decides the ceiling on the claim.
A check has a type and it has an assertion, and they are not the same thing. The type is how it finds out. The assertion is what a pass is capable of establishing. Holding them apart is what stops a result travelling further than the evidence behind it.
What passed. What did not. What needs a person.
This is the third node of the spine, opened up. Checks run against work as it moves rather than being assembled after the fact, and a check ends in one of three states. Most assurance tooling is built to drive the third towards nothing. This is being designed for the opposite, and that is the single design decision everything else follows from.
The useful part is not the pass. It is that the record says which check, against which version, at what time.
A number tells a reviewer that something is wrong. A named condition tells them what to do about it. This is the state that reaches the record as not supported.
The check could not decide, or the decision was never a machine decision to begin with. The exception is routed to a person with the context attached, and their decision is written down next to the check that raised it. Until they decide it stands as inconclusive and not as a pass.
A tool that reports on what it cannot see is not producing evidence.
What a reviewer can follow, without asking us.
Evidence is only useful if a reviewer can walk it without our help, and only honest if the edge of it is stated.
What a reviewer should be able to walk
The change, from the request that started it to the state it left the system in.
Which checks ran against that change, and when.
Which checks did not run, and the reason they did not.
Every exception raised, who it went to, what they decided, and when they decided it.
Who held the access required to make the change at the time it was made.
Where the walk stops
Coverage reaches as far as the systems in scope for a given deployment. Work outside those systems is outside the record, and the record says so rather than implying completeness.
This is the row most likely to be tested in a review, and it is the one most assurance tooling leaves for the reader to discover.
The package leaves with a verifier that runs on its own
An evidence package can be checked outside Reign. The verifier runs on its own, against the package, without access to our systems and without our database — which is the point of it. Origin is established against a key you obtain from us separately, so the strength of the check rests on your key handling rather than on our good behavior.
What exists today, and what does not.
Reign Assurance is not sold and is not shipping. That is the commercial position, and it is not the whole picture, so here is the rest of it.
Nothing here has been run against a live estate, and no customer relies on it today.
What co-design actually means here.
The word is used loosely in this industry. This is what it means when we use it, and what it would look like on your side.
One named population
Each engagement covers one named population of work. Scope is written down at the start. If it grows, that is a new conversation and not an assumption.
A named engineer, embedded
They sit with the team, see the real conditions rather than the described ones, and take the findings back into the design.
Your conditions change the design
This is the part that makes it co-design rather than a pilot. What you push back on is what gets rebuilt.
It ends where you agreed it ends
How long an engagement runs, and what closes it, is written down alongside the scope before anything starts. Nothing here is open-ended and nothing renews by default.
We are working with a small number of organizations, not a waiting list. The number is small because the work is close, and close work does not scale by adding logos to a slide.
Four people, four different questions.
Reign Assurance is being designed against the questions these four ask, in the order they ask them. Each has a page already written for them.
Bring us regulated work under real pressure.
If you have work that has to be defended and you are willing to let us look at it closely, that is the conversation worth having. There is no product to buy, and the scope is agreed before anything starts.