Docs / Concepts

The analysis document

The analysis document is the first artifact AI produces. It maps out the details, risks, and edge cases implied by your description, so the team can confirm it captures what you actually meant before any build plan exists.

It answers a single question: “did we understand the ask?” It deliberately stays at a strategic, conceptual level, naming the concepts, the approach, and the risks, without dropping into queries, data shapes, method signatures, or step-by-step logic. That implementation detail is the canvas’s job, once this document is approved.

How it’s generated

When the author submits a draft for analysis, REEZN reads the feature’s definition (goal, business value, scope in and out, constraints, and the acceptance criteria written as Given / When / Then) and drafts the document from it. The richer the definition, the sharper the analysis. It usually takes a minute or two, and the feature moves to analysis review on its own when it is done.

The draft is also grounded in your project’s norms and safeguards, your personas, and, if a service has a GitHub repo connected, in your actual code, so it can name concepts that already exist rather than reasoning in the abstract.

What it contains

Every analysis has the same four sections, so no two skip the same thing:

Original Business Requirement: Your request, restated verbatim, never paraphrased or truncated, so the source of truth never drifts as the document builds on it.
Domain Concept Identification: The concepts already in your codebase that this work touches, the new concepts it introduces, and the key business rules that govern them. This is the vocabulary the canvas will later model.
Strategic Approach: The proposed solution direction, the key design decisions and their trade-offs, and, importantly, the alternatives that were considered and why they were rejected.
Risk & Gap Analysis: Ambiguities in the requirement, edge cases, technical risks, and a coverage table mapping every acceptance criterion to whether and how it can be addressed (with any gaps flagged).

Grounded in your code and standards

The analysis is generated with your project’s norms and safeguards in context. It actively surfaces where a requirement conflicts with a norm, or collides with a hard safeguard, in the Risk & Gap Analysis, so those tensions are visible and discussed before anyone designs around them.

Norms guide and safeguards constrain. The analysis flags a clash with either rather than quietly working around it, leaving a human to decide what to do.

Reviewing & approving (gate 1)

A finished analysis lands in “In review,” the first of REEZN’s two human gates. Whoever owns the requirements (usually product) reads it to confirm it captures what was actually meant. Anyone with project access can read it and leave comments; only a tech reviewer or admin can approve it.

Review isn’t all-or-nothing. While the analysis awaits approval, a reviewer can click any section to edit it in place, in markdown with a live preview, to fix or sharpen wording without disturbing the others. Comments in the sidebar capture anything the author should revisit. Approving the analysis advances the feature and locks the document; from then on it is read-only.

Why this exists

Separating “did we understand the ask?” from “how should we build it?” gives you two small, focused reviews instead of one overwhelming one. Once approved, the analysis becomes the grounding context every service’s canvas is built from, and a canvas draws its content from this document rather than inventing its own. That is why a misread requirement caught here saves a wrong blueprint later: everything downstream inherits whatever this document gets right or wrong.