Docs / Workflow

Implementation & verification

For organizations on the Business plan, REEZN can go a step beyond the plan: it can implement an approved feature, open a pull request in your repository, and verify its own work, with a third human sign-off before anything is called done.

Implementation and verification are a Business-plan capability, and the whole stretch is re-checked server-side. On other plans a feature finishes at Approved, where you export the blueprint and build from it yourself; the “Generate implementation” action isn’t offered.

This picks up exactly where the two review gates leave off. An approved feature already has a reviewed blueprint per service; here REEZN acts on that blueprint, turning each approved canvas into a real branch and pull request, then reporting back on what it did so a human can judge whether it’s right.

What you need first

Three things have to be in place before a feature can be implemented:

The feature is fully Approved: every canvas signed off. Implementation builds from the approved canvases, so it can’t start earlier.
Your org is on the Business plan. The capability is gated to it and enforced by REEZN’s server-side rules, not just the interface.
Each target service has a write-scoped GitHub token. This is separate from the read-only token used for code context: it needs Contents and Pull requests read/write so REEZN can push a branch and open a PR. It’s set per service in Project settings and stored write-only, even admins can’t read it back.

Set the write token in Project settings → Services, alongside the read-only token. A service’s optional test command (also set there) is what REEZN runs to check its own work; without it, implementation still runs but there’s no test result to report.

Starting it

On an approved feature, an admin or tech reviewer clicks Generate implementation. REEZN then works one service at a time, in parallel, and for each service an agent:

Clones the service’s repository using its write-scoped token.
Runs the service’s setup command to install dependencies and get the project ready (and stops there if setup fails, rather than pushing broken work).
Implements the change, working from that service’s approved canvas together with the analysis, your norms and safeguards, and, on the Business plan, the knowledge base.
Runs the service’s test command and records the result, which is carried into the verification report.
Pushes a branch and opens a pull request against the repository’s default branch, then writes an AI verification report describing what it did and how the tests fared.

The three states it moves through

Implementation adds a short tail to the lifecycle, past Approved, with one more automated step and one more human gate:

Implementing: Automated. The agent is running for each service: cloning, building, implementing, testing, and opening a PR. If every service fails, the feature falls back to Approved so you can adjust and try again.
Verification review: Gate 3. The PRs are open and each service’s verification report is awaiting human approval. A tech reviewer or admin reads the report (and the PR it points to) and approves it, exactly as they approve a canvas.
Delivered: Every verification report is approved. The feature is done and its pull requests are ready for your team to review and merge in GitHub.

Merging the pull requests stays in your hands, in GitHub. REEZN opens and verifies them and marks the feature Delivered; it never merges to your default branch itself.

A third gate, same principle

Verification review is the same idea as the analysis and canvas gates, applied to code: AI does the work and reports on it, but a human decides whether it’s acceptable. The verification report exists so that decision is informed: it summarizes what changed and surfaces the test result rather than asking a reviewer to judge a raw diff cold. And as with the other gates, approving is limited to tech reviewers and admins.

Why this exists

An approved blueprint is already valuable on its own, which is why every plan can be exported and built by hand. But for teams that want it, closing the last gap, from reviewed plan to open, verified pull request, removes the most error-prone hand-off of all. Keeping a human gate on the result, and leaving the merge to you, means automating the work never means automating away the judgement: REEZN writes the code and checks it, but a person still signs off before it’s called delivered, and still decides when it lands.