We build our own product through the Factory.
Reign is built the way we ask customers to let us build for them. The work enters our own repositories as merge requests, passes our own approval gate and is reviewed by named people. That gives us a small, honest dataset about our own engineering. It is the first dataset we will show you, and it is the one we are most careful about describing.
Read the denominatorHow that month ranWhat we do not measure
Three numbers, and what sits under them.
These are the only figures we publish. The denominator is inside this box with them, because separating a number from the population it was drawn on is how a measurement becomes a claim. It is part of the figures, not a footnote to them.
Two people directed. The Factory built. A named person approved.
Of the 326 merged requests, 228 were planned and validated by engineers and built through the Factory. 98 were carried by the Factory as far as the merge gate. Every one of the 326 still needed a recorded approval from a named iTmethods engineer.
Two routes in. One gate out.
Where each of the 326 came from, and the one thing all 326 had in common.
Agents and models build
Implementation ran through the Factory: agents and models doing the writing, inside an isolated worker, with Reign Gateway on the model path.
A human stays in the loop
Nothing merged without a named approval. The Factory does not hold the gate. Your reviewers would not either, if this were your estate.
The path is operated, and it changes
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. What follows here is our own engineering rather than a customer result. What the Factory may pick up, and how it hands over, moves with customer feedback. It is not a static benchmark.
This is not a benchmark.
We are not claiming an industry position. We are describing one month of our own work.
What we do not yet measure.
These three measures are not instrumented today and we publish no figures for them. We intend to measure them, and we would rather state the gap than let the silence read as a result.
Refusal and handover rate
How often the work stops and hands over to a person, and why. We report stops inside an engagement. We do not yet publish a rate across a population, and we will not until the definition is stable.
Would you trust a system that never reported a stop?
Rework
How much merged change is amended or reverted afterwards. This is the measure that separates volume from value. It is not measured yet, and any volume figure should be read as incomplete until it is.
How would you know today whether merged work stayed merged?
Size of change
The distribution of change size behind a count of merge requests. A count treats a one-line edit and a substantial refactor as equal. We do not publish that distribution yet.
What would a count of changes hide in your own repositories?
Stated as intent, not as fact. None of the three is measured today. Where each motion actually stands is on the product status register.
Start from your baseline, not from ours.
Bring one repository and one population of work, and we will agree the measures before anything runs. What we report back will be your numbers, described with the same qualifiers we apply to our own.