Skip to main content

    How the work reaches you

    Your backlog in. A merge-ready change out.

    This is the whole path, start to finish. Reign Factory completes the work it is assigned in an isolated environment, then hands a merge-ready change to your own path. Everything after the handover is the process you already run and audit. Step through the diagram below, or let it play.

    Bring us meaningful workWhat we measured →

    Nothing merges and nothing releases without the gate your policy sets.

    01

    An item from your backlog, assigned to the Factory.

    Where Reign Factory sits Reign Factory takes an eligible backlog item, works it in an isolated worker with Reign Gateway on the model path, and proposes a merge-ready change into your software project. Your project keeps commit, checks, review, approval, merge and release. Your developers contribute into the same path. Check and review results feed back to the factory. Your backlog work items Reign Factory operated for you Eligibility tested criteria Supervisor assigns work Isolated workers one item at a time Reign Gateway policy · routing Stops and hands over out of scope · check fails · not converging merge-ready change Your software project your controls, unchanged Commit branch Your checks build · test Merge request review Your approval stages you run Merge your rules Release your process Your developers same path check and review results return to the factory
    It works only on what you assign it. Eligibility rules decide what it may touch. It stops rather than pushing through. Out of scope, a check unmet or no convergence hands over to a person. Your policy decides. Review, approval, merge and release stay yours.

    Eligibility, refusal and handover

    The three places it stops.

    A path that cannot stop is not a governed path. These are the points at which the work is handed back to a person, by design.

    Before it starts

    Eligibility is checked against rules agreed in advance. Work outside the agreed population, the agreed repository or the agreed change type is not started. The refusal is recorded with its reason.

    Who would set those rules in your organization?

    While it runs

    Where a required check is unmet, or the work turns out to depend on something outside the agreed scope, it stops rather than working around the obstacle. A person receives the state of the work and what remains open.

    What would you want it to refuse to touch?

    At the boundary

    Where it cannot converge on a change worth reviewing, it hands over rather than opening a merge request to show activity. A stop is a reportable outcome, not a failure to be hidden.

    Would you rather have a poor change or an honest stop?

    After the handover

    Everything downstream is already yours.

    The Factory opens a merge request. From that point on, the process is the one your organization already trusts.

    • Your pipeline runs, on your runners, under your configuration.
    • Your scanners report their findings into the request. Scanners report, they do not block.
    • Your approval gate is held on every merge request the Factory opens, with the approval recorded against a named person.
    • Your reviewer merges, or declines. The decline is part of the record.
    • Your release path decides what ships, and when.

    We do not merge. We do not release. We do not decide what ships.

    Start with one repository

    Walk the path with your own work in it.

    Bring one repository and one population of work, and we will agree the rules and the measures before anything runs. The path above is the path your work would take.

    Bring us meaningful workreign@itmethods.com