Docs / Workflow

The feature lifecycle

Every feature moves through the same core states, from a one-line idea to an approved blueprint. AI does the drafting; humans approve at every gate. Nothing advances on the AI’s say-so alone. Most organizations finish at an approved blueprint; those on the Business plan can carry a feature further, into implementation and verification.

The path is a straight line with two automated stretches and two human checkpoints, in alternating order: you describe the feature, AI drafts the analysis, a human approves it, AI drafts the canvases, a human approves those, and the feature is done. Each state below names what’s happening, who’s acting, and what moves the feature on.

Describing the feature

A feature begins life as a draft, and a draft is a structured definition: the author’s thinking, captured in plain language. Every field except the title and acceptance criteria is optional, but the richer the definition, the sharper the analysis that follows, because this is the only human-written input the AI plans from.

Title: A short name for the feature. Along with at least one acceptance criterion, it is the only required field.
Services: The services this feature touches. Each one gets its own REASONS canvas later, so a feature spanning two services produces two canvases.
Goal: What the feature should accomplish, in a sentence or two. This is the heart of the ask.
Business value: Why it matters. Kept brief; it anchors the plan to the outcome, not just the mechanics.
Scope in: What this feature explicitly includes, the work that is on the table.
Scope out: What it explicitly does not include, drawing the boundary so the AI doesn’t over-reach and reviewers know what was deliberately left out.
Acceptance criteria: At least one, each written as Given / When / Then so pass-or-fail is unambiguous. The analysis maps every criterion to whether and how it can be met.
Constraints: Known technical or business limits to plan within. Optional.

A draft is fully editable. The author saves it as a draft and keeps refining, or submits it for analysis when it is ready. Submitting is what kicks the workflow into motion. Starting from a template pre-fills these fields with a sensible structure.

Before submitting, you can ask REEZN to poke holes in the draft: it reads the definition and posts the gaps it finds as questions, so you fix them while it is still cheap. See poke holes in a draft.

The core states

A feature occupies exactly one state at a time. The two “In …” states are automated, with REEZN generating in the background and no human action needed, and each is followed by a review state where a person decides whether to advance. (Business-plan orgs get three further states past Approved, covered below.)

Draft: The author writes and edits the definition. Fully editable. Submitting it for analysis moves the feature to In analysis.
In analysis: Automated. AI generates the analysis document from the definition, plus your project’s norms, safeguards, and any connected code. It usually takes a minute or two, and the feature advances to Analysis review on its own when it is done. (If generation fails, the feature falls back to Draft.)
Analysis review: Gate 1. The analysis is done and awaiting human approval. Anyone with project access can read it and comment; a tech reviewer or admin approves it. Approving advances the feature to In canvas.
In canvas: Automated. AI generates one REASONS canvas per service, all in parallel, each grounded in the just-approved analysis. When every canvas is drafted, the feature advances to Canvas review on its own. (If generation fails, it falls back to Analysis review.)
Canvas review: Gate 2. The canvases are done and awaiting human approval. Each canvas is reviewed and approved independently by a tech reviewer or admin.
Partially approved: Some, but not all, of a multi-service feature’s canvases have been approved. A feature lands here after the first canvas is signed off and stays here until the last one is.
Approved: Every canvas is approved. For most organizations this is the finished state: the generation preview unlocks, and the feature counts as complete (including in per-persona delivery tracking). On the Business plan, an approved feature can go further, into implementation and verification.
Rejected: A reviewer decided the feature shouldn’t proceed at all, at either gate. Terminal and read-only: the reason is shown on the feature page and this version stays frozen. A rejected feature can be revived later by starting a new version.
Archived: The feature is retired from active work. Its full history, every version, artifact, and approval, stays intact and viewable.

Rejected sits outside the main line, not between it: a reviewer chooses it instead of advancing, at either review gate. Both rejected and archived features leave the active board but stay fully visible, one “Show” click away.

Automated steps vs. human gates

The two automated transitions run in the background, not because anyone clicks a button:

Submitting a draft sends it to In analysis, where REEZN reads the definition (plus norms, safeguards, and connected code) and writes the analysis document, then advances the feature to Analysis review automatically.
Approving the analysis sends the feature to In canvas, where REEZN generates a canvas for each service in parallel from the approved analysis, then advances to Canvas review automatically.

Between and after those automated stretches sit the two human gates. They ask different questions of different people:

Gate 1: Analysis review: “Did we understand the ask?” Best answered by whoever owns the requirements, usually product. Approving it is what triggers canvas generation.
Gate 2: Canvas review: “Is this the right way to build it?” Best answered by a technical reviewer, per service. Approving the last canvas is what completes the feature.

Each automated step is followed by a human review. The two gates are where people, not the AI, decide whether to advance, and an author can’t approve their own feature, which is what keeps the gates meaningful.

Why multi-service features pass through “Partially approved”

A feature can touch several services, and each service gets its own canvas that is reviewed on its own. Because the canvases are approved one at a time, a feature with more than one canvas moves from Canvas review to Partially approved as soon as the first is signed off, and only reaches Approved once the last canvas is approved. A single-service feature has just one canvas, so it jumps straight from Canvas review to Approved without ever passing through Partially approved.

Going further: implementation & verification (Business plan)

On the Business plan, an approved feature doesn’t have to stop at the blueprint. REEZN can implement it and open pull requests, adding three more states past Approved: one automated step and one more human gate, in the same rhythm as the rest of the lifecycle:

Implementing: Automated. For each service, an agent clones the repo, builds the change from the approved canvas, runs the service’s tests, and opens a pull request. When the PRs are open it advances to Verification review. (If every service fails, it falls back to Approved.)
Verification review: Gate 3. Each service’s AI verification report is awaiting human approval. A tech reviewer or admin approves it much like a canvas. Approving the last one completes the feature.
Delivered: Every verification report is approved. The pull requests are ready for your team to review and merge in GitHub; REEZN never merges them itself.

This tail is Business-plan only and re-checked server-side. Organizations on other plans finish at Approved and build from the exported blueprint themselves.

Why this exists

Alternating AI drafting with human approval front-loads the catching of misunderstandings into small, focused reviews, cheap to do and done before code is trusted. Separating “did we understand it?” from “is this the right build?”, and, on the Business plan, from “is the built code acceptable?”, lets each person sign off only on what they’re best placed to judge, and approving the analysis per feature but canvases and verification per service means the parts of a cross-service feature can advance at their own pace without holding each other up.