ProductsReign Factory

AI-enabled engineering work, contributed into the delivery process you already run.

The output is a merge request in your own repository, entering the approval path you already run, in the tooling you already use. It does not merge and it does not release. Your reviewers keep the decision, and the record travels with the change.

Available · Beta Release Bring us meaningful work See the delivery path, and where it stops →

We do not need to operate your tooling for Reign Factory to work inside it. Your checks, your approvals and your release path still decide what ships.

One item, end to end your path

Everything to the right of the seam is the process you already run. Factory stops at the merge request, which is the point.

What changes for you

Three things look different in ninety days.

Each claim below is paired with the figure it was measured on, and every one of those figures is broken open in the section that follows.

Work that has been waiting starts moving.

Designed to progress eligible, well-specified work continuously. Items outside the criteria you set stay with your team, and you see which and why.

326 merged in one month — the volume of ~26 median-velocity engineers →

What reaches your reviewers arrives in the same shape.

Every item follows the same eligibility, implementation, testing and review pattern, carrying its checks and findings.

19 h median open-to-merge, 4.3× the industry median →

Every change can be traced end to end.

Where it came from, what it cleared, what review found and who signed it, in the systems you already audit.

326 of 326 with a named approval →

What we measured on our own engineering

326 merged changes in a month. Two engineers.

Around 99% of implementation on our own codebase runs through Reign Factory. The month below came from a two-person team setting the work up and validating what came back. The Factory has measured numbers on our own engineering; Ops has two decades of operating history and no published operating metric yet, and Gateway has a mechanism you can inspect rather than a count. Each is stated as what it is.

326

Merged merge requests in one month, across eight of our own repositories. Every one with a named approval.

19 h

Median open-to-merge, against an 83 h published industry median. 58% merge inside a day.

~99%

Of implementation run through the Factory. Engineers plan and validate; the Factory builds.

Throughput

Merged merge requests per engineer per month, against a benchmark of 6.1 million pull requests.

Industry median

12.4

Industry elite

~20

Our gateway team

163 — 13× median

All 326 merged merge requests across the two engineers who planned and validated the Factory's work.

Speed

Median hours from merge request open to merge. Shorter is better. Review pickup — the largest delay in the industry data — is near zero here.

Industry median

83 h

Industry elite

<48 h

Our gateway team

19 h — 58% merge in under 24 h

All merged merge requests in the window.

Who directed the 326

Virtually all implementation happens in the Factory. The split is who directed it. Either way, the merge gate is a named person.

228 engineer-directed — planned and validated by our engineers

98 Factory end to end — no human until the merge gate

Read the denominator. Measured on Reign's own engineering, 11 July to 11 August 2026: the GitLab engineering group, being the Reign gateway repository and seven satellites, with CI release commits excluded and automated approvals filtered out of the approval count. Benchmarks are LinearB's 2025 engineering benchmarks (83 h median cycle time, drawn from 6.1 million pull requests) and GitKraken's 2026 cycle-time targets (elite under 48 h). Merge request counts do not capture change size, so cycle time is the more direct comparison. Internal environment only, and not a customer result. Your conversation starts from your own baseline, agreed before anything runs. What we measured →

How the work reaches you

Your backlog in. A merge-ready change out.

Reign Factory works the item it is assigned in an isolated environment, with Reign Gateway on the model path, then hands a merge-ready change to your own path: a merge request, which is a pull request in GitHub terms. Everything after the handover is the process you already run.

Reign Factory · operated for you

Your software project · your controls, unchanged

Eligibility

The rules you set for what it may touch. Tested, and visible to you.

Isolated worker

One item, one bounded environment.

Gateway and checks

Policy at the boundary. Build and test first.

Merge request

Opened in your repository, carrying its findings.

Your checks

Your pipeline, unchanged.

Review and approval

The stages you run. Your policy decides.

Merge and release

Your rules, your process.

Stops and hands over Out of scope · a required check fails · it isn’t making progress

The item goes to a named person and stays with them. It does not push through.

Eligibility before work starts. Repository, delivery path, change type and the boundaries of the population are set in advance. Work outside the agreed scope is not started, and the rule that refused an item is visible to you.

Policy and a record at the model boundary. Every model call passes through Reign Gateway. A reviewer can see what was asked, what was returned and which rules applied.

Evidence a reviewer can follow. The intent, the change, the checks that ran, the findings raised and the approval recorded against a named person — in your own system, not a separate report to be reconciled later.

Boundaries

What it will not do.

The limits matter as much as the capability. They are fixed, not configurable by convenience.

The limits fixed

Four limits, and none of them is a setting. They are the reason the thing on the left of the line is safe to let near your repository.

It does not merge.

A person merges. The gate your policy sets is held on every merge request the Factory opens, without exception and without a private route around it.

It does not release.

Release stays where it already sits in your organization. Adoption is additive; your pipeline keeps its wiring.

It does not decide what ships.

That decision belongs to your reviewers and your change process. Scanners report their findings into the request. Scanners report, they do not block.

It does not run outside the agreed population.

Out of scope means out of scope. Where a check is unmet, where the work sits outside the agreed scope, or where it cannot converge on a change worth reviewing, it stops.

A stop is a reportable outcome, not a failure to be hidden. After three attempts that do not produce a change worth reviewing, it stops and hands over to a person with the state of the work, what was attempted and what remains open. Autonomy is off by default, is turned on per population by you in writing, and the setting survives a restart rather than reverting to whatever the process last held in memory.

The autonomy-off latch and the coding-agent list are published ahead of engineering verification, on a recorded decision (D-024).

Open by design

It runs in the estate you already have.

Adoption is additive. The supported estate today is GitLab, and the rest is in active development rather than on a roadmap slide. Nothing here asks you to move a repository, change a tracker or adopt a new pipeline.

Layer	What it works with	What changes for you
Coding agents	The agent your engineers already chose. The models are portable, and the layer that governs them should be too.	Nothing. The agent your engineers already chose keeps working, with policy applied at the model boundary.
Source control	GitLab today, self-managed or ours to operate. GitHub and Bitbucket are next and in active development.	Nothing on GitLab. Work arrives as a merge request in your own repository.
Work tracking	GitLab issues today. Jira and Plane are next and in active development.	Nothing. Items are assigned from the backlog you already keep.
Pipelines and checks	Your CI, your build, your tests, your scanners.	Nothing. Your pipeline runs unchanged, and scanners report rather than block.
Model access	Reign Gateway on the model path, for the Factory and for agents your own teams wrote.	One boundary where policy is applied and the call is recorded.
Approval and release	The review stages and approval policy you run today.	Nothing. Your policy decides what ships.

We do not need to operate your tooling for the Factory to work inside it. If you would rather we did, that is Reign Ops, and it is a separate decision.

Where it is aimed

Three backlogs that do not clear themselves.

These are populations of work that are understood, agreed and repeatedly deferred. They are the work we ask for.

Remediation that stays open

Findings that have been triaged, accepted and scheduled, then carried forward again. The fix is usually known. The capacity to make it, review it and evidence it is what runs out.

How long has the oldest item on your remediation list been open?

Upgrades and migrations

Framework, runtime and library work spread thinly across many repositories. Each change is small. The volume, the consistency and the review load are the problem.

How many repositories are pinned to a version you no longer want to run?

Delivery the business is waiting on

Committed work that keeps losing to operational load. The scope is settled and the priority is agreed, and the engineering time to start it does not appear.

What did you promise this quarter that has not been started?

Engagement

How an engagement starts.

One repository. One delivery path. Rules and measures agreed in writing before anything runs.

1

One repository, one delivery path

A narrow start makes the result readable. A wide start makes it arguable.

2

Rules and measures agreed first

Eligibility, the approval gate, the evidence expected and the measures we will both look at. Your baseline is recorded before the first merge request is opened.

3

A named engineer embedded

Accountable for what is opened, what is stopped and what is handed back. Approvals during the engagement are recorded against named people.

4

A written recommendation

To continue, to narrow or to stop. Stop is a real option and we will say so where the evidence points that way.

What it asks of your reviewers. Capacity gained in implementation arrives as work for your reviewers. Someone reads every merge request Reign Factory opens, and the first weeks ask more of them while the eligibility rules settle.

What runs where. A dedicated single-tenant instance. Your identity provider, network policy, key management and logging govern the deployment. iTmethods operates the platform and the environment throughout.