Four jobs on your desk, and they keep competing for the same people.
The estate, the boundary, the backlog and the record are usually four separate fights, staffed from one pool of senior engineers, with governance arriving on top as a control somebody else designed. Reign is the four of them operated as one thing.
A single-tenant dedicated instance, in your own AWS or Azure account or in infrastructure iTmethods operates. Both available today; Google Cloud is planned for 2027. Air-gapped and sovereign are in development.
Governance arrives as a control somebody else designed.
It lands as a requirement, and it is implemented by the teams who were already behind. Where it is implemented decides what it costs you — and that is a decision you make once, at the start, rather than a thousand times afterwards.
The cost is not the first implementation. It is that there is no single place to look to know whether the control is still there.
Guard rails, budgets and routing change without restarting anything or shipping an application. The operator configures governance; the engineer does not carry it.
Upgrades do not slip because they are hard. They slip because they are never next, and the calendar belongs to whoever is holding the pager.
Where that record is written as work happens, the requests that arrive from risk and audit stop being projects for your team. That is the part of this that shows up in your roadmap rather than someone else’s.
The estate, the boundary, the work that is never next, and the record.
The same four jobs sit on every technology leader’s desk. Each is bought on its own; nothing here requires the other three.
The estate
Source control, build capacity, the open source estate and the AI substrate underneath them, operated as one estate rather than a collection of products nobody scheduled an upgrade for. Your teams keep the tools they chose.
The backlog
Upgrades, migrations, deprecations and small remediations are not hard. They are simply never next. That work is contributed into your own delivery path as merge requests carrying their checks and findings. It does not merge and it does not release.
The boundary
Applications and agents point at one endpoint. Policy, identity and the record sit there, so a control is one implementation rather than a thousand. Your client libraries do not change.
The record
The evidence a reviewer needs, organised into a form they can work through, so the requests that arrive from risk and audit stop being projects for your team.
One traffic path, or one estate. Not both.
Reign Ops and Reign Gateway are available today and each stands alone. Reign Factory is in beta, on real work, with access agreed in writing before anything runs.
Reign Factory runs Reign Gateway on its own model path, so the boundary is the piece the others are built on. That is the reason to start there if you are only starting once.
What we do not do, stated in the same place.
Four limits that are fixed rather than configurable, and two statuses that are stated rather than implied.
The output is a merge request in your repository entering the approval path you already run. Your reviewers keep the decision, and nothing merges that you did not approve. That limit does not change in beta.
What iTmethods operates is the envelope both of them need: the runtime, the boundary, the tool layer and the substrate beneath. Most of this market is selling the other thing.
When a model does not answer, the call is recorded as failed. It does not fall back to a model your policy has not permitted, because it does not fall back at all.
It does not certify, does not attest, does not issue an audit opinion and does not provide independent assurance, in any tense. Reign prepares the evidence; the people who own the risk decide.
Reign Factory is in beta and being productized. It is not generally available; beta access is agreed with us and scoped in writing before anything runs. Reign Assurance is in co-design development, which means it is not available, not sold and not shipping. The status register carries the dated version of both, and it is the page to check rather than this one.
The questions that arrive before the scoping call.
Do you have to operate our tooling for any of this to work?
What does adoption actually cost an application team?
Where does it run?
What can we actually start with today?
The same estate, three other questions.
Whoever else is in the room is reading a different page about the same infrastructure. These are theirs.
Bring us one traffic path and the estate nobody owns.
We will look at what pointing that path at a boundary would take, what operating the estate underneath would involve, and what your teams would stop being asked to reconstruct. One repository, one delivery path, and the rules agreed in writing before anything runs.