Docs / Workflow

Reviewing & approving

REEZN puts two human sign-offs in the path of every feature: one on the analysis, one on the canvases. AI does the drafting, but nothing advances on the AI’s say-so alone. The two gates aren’t the same review twice: each asks a different question, and each is best answered by a different person.

The two gates

A feature reaches a review gate when the AI finishes drafting and the work lands in an “In review” state, awaiting a human. The two gates sit at different points in the lifecycle and judge different things:

Gate 1: Analysis review: “Did we understand the ask?” The analysis document is done and waiting. The question is whether it captures what was actually meant: the right concepts, approach, risks, and acceptance-criteria coverage. Best answered by whoever owns the requirements, usually product. Approving it triggers canvas generation.
Gate 2: Canvas review: “Is this the right way to build it?” One REASONS canvas per service is done and waiting. The question is whether the plan (the structure, the tasks, the application of your norms and safeguards) is sound for that service. Best answered by a technical reviewer. Approving the last canvas completes the feature.

The two questions are deliberately separate. Confirming you understood the ask is a different judgement from confirming the build plan is right, and the people best placed to make each call are often different too. Splitting them gives you two small, focused reviews instead of one overwhelming one.

Who can comment, who can approve

Reviewing has two distinct actions, and they’re gated differently:

Commenting is open to every member with access to the project, observers and authors included. The comment box is always there in the collaboration sidebar, so anyone can raise a question, flag a concern, or suggest a change on the artifact under review.
Approving is limited to tech reviewers and org admins. The Approve button only appears for them; everyone else sees a note that approval requires a tech reviewer or org admin. Authors can create, edit, submit, and version their own features and comment freely, but they cannot approve.

Comments & edits

Review isn’t all-or-nothing; you don’t have to either approve as-is or send the whole thing back. There are two ways to refine an artifact before it is signed off:

Comment: Leave a comment in the sidebar for the author or another reviewer to address. Comments are grouped into unresolved and resolved, so an open thread is a visible signal that something still needs attention before approval.
Edit a section in place: While an artifact awaits approval, a reviewer can fix or sharpen one section without disturbing the others. In the analysis, click any section to edit its markdown with a live preview; in a canvas, expand a section and choose Edit section. Saving updates just that section.

Both are only possible while the artifact is in review. Approving an artifact locks it: from then on it is read-only, and so is every older version of a feature. So comment and edit freely up to the moment you approve, because once a gate closes, the plan is fixed.

Approving

When the artifact is right, a reviewer clicks Approve in the collaboration sidebar and confirms. An optional note can be attached to record the reasoning behind the sign-off. Approving the analysis advances the feature into canvas generation; approving a canvas advances or completes the feature depending on whether other canvases are still outstanding.

Four ways out of a gate

Approve isn’t the only decision available at a gate. A tech reviewer or admin choosing not to approve has three further options, and each sends the feature down a different path:

Approve: The plan is right as it stands. Moves the feature forward to the next stage.
Request changes: The idea itself needs a rethink. Sends the feature all the way back to the author as a new draft, for a human to reconsider and resubmit: the heaviest option, since it hands control back to a person.
Reject & rework: The AI output is salvageable but needs a steer. Rejects the current version and immediately sends it back to the AI for another attempt, as the next version, at the same gate: faster than Request changes because no one has to return to the draft.
Reject: The feature shouldn’t proceed at all: it conflicts with product direction, or isn’t worth doing. Ends the feature outright rather than sending it anywhere.

Request changes is human rework: the author reconsiders the ask. Reject & rework is AI rework: the same ask, regenerated with a steer. Reach for whichever matches what actually needs to change: the requirement, or just the draft of it.

Reject & rework

Reject & rework rejects the version currently in review and immediately regenerates it as the next version, at the same gate: from analysis review, the analysis is regenerated; from canvas review, the canvases are regenerated, with the already-approved analysis carried forward unchanged. The rejected version stays frozen in the feature’s version history.

Choosing it opens a form with two things to provide:

Reason: A short, required explanation of what needs to change, for example “the scope creeps into the billing service, narrow it back to notifications only.” The AI reads this alongside the previous output when it regenerates.
Comments to include: Every comment left on the current version, pre-selected. Deselect any that aren’t relevant to this rework; the rest are passed to the AI as extra context, together with the reason and the previous version’s output.

The new version lands back at the same review stage it came from, ready for the same sign-off. Because it’s a new version, the earlier one is never lost: it stays visible, frozen, in version history.

Reject

Reject is the terminal option, for when a feature shouldn’t proceed at all rather than needing another pass. It requires a short, written reason, then moves the feature to Rejected: read-only, with that reason shown on the feature page, and the version and its artifacts frozen for reference. The author is notified, in their Inbox and by email if they’ve opted in.

A rejected feature leaves the active board, but it isn’t deleted or hidden away for good: “Show rejected” brings rejected features back into view, the same way “Show archived” does for archived ones. If the idea is worth another look later, a new version can be started from a rejected feature, reviving it and starting the workflow over.

Both Reject and Reject & rework ask for confirmation and require a written reason before they take effect, and both are restricted to tech reviewers and admins, the same people who can approve: an author or observer can comment, but can’t reject.

Multi-service canvases & “partially approved”

A feature can touch several services, and each service gets its own canvas reviewed and approved on its own, by whoever owns that service and in terms of that service’s real stack. Because the canvases are signed off one at a time, a feature with more than one canvas moves into Partially approved as soon as the first is approved, and only reaches Approved once the last one is. A single-service feature has just one canvas, so it goes straight from Canvas review to Approved. Once every canvas is approved, the generation preview unlocks.

No self-approval

A project’s review policy governs who signs off and whether self-approval is allowed. The standard policy bars an author from approving their own work, and at minimum, approval is always restricted to tech reviewers and admins, enforced by REEZN’s server-side permission checks rather than just hidden in the interface. Even a request that slipped past the UI would be refused.

Why this exists

Splitting the review in two means each person approves only what they’re best placed to judge, and a misread requirement gets caught here, while it is a cheap comment, instead of after it is baked into a build plan and code. Letting everyone comment but only reviewers approve keeps the conversation open without diluting accountability for the decision. And barring self-approval is what keeps a gate a gate: a second set of eyes, every time, is the reason the sign-off means something. Giving a reviewer four distinct exits, not just approve-or-not, means the response matches the problem: a wrong idea gets rejected outright, a fixable one gets a quick AI steer instead of a full trip back to the author, and only a real rethink of the ask goes all the way back to draft.