Docs / Concepts

The blueprint (REASONS canvas)

The REASONS canvas is the blueprint for a feature in a single service: a structured, implementation-ready plan that a developer (or an AI coding tool) can build from directly.

It is the second artifact AI produces, after the analysis. Where the analysis answers “did we understand the ask?”, the canvas answers “how do we build it?”. It turns the agreed understanding into a concrete plan a reviewer can sign off on and an engineer can pick up.

One canvas per service

A separate canvas is generated for every service a feature touches. Each service carries its own slice of the work and its own technology stack, so a single shared plan would either gloss over those differences or grow unwieldy. Splitting the plan per service keeps each one focused, lets the right reviewer sign off on the part they own, and means a service’s canvas speaks in terms of that service’s real stack rather than a generic one.

When the analysis is approved, REEZN generates all of a feature’s canvases at once, in parallel, one for each service listed on the feature. They are then reviewed and approved independently, which is why a feature can sit in “partially approved” while some canvases are signed off and others are still under review.

Grounded in the analysis

Every canvas is derived directly from the approved analysis document. It draws its content from that analysis (the entities, the approach, the risks, the acceptance criteria) rather than inventing new material, reaching for generic placeholders, or importing assumptions from outside it. Concepts the analysis identified appear in the canvas by their actual names, refined into implementation detail rather than replaced.

Because the canvas builds on the analysis, anything misread upstream flows downstream. That is why the analysis gets its own human sign-off first: catching a wrong assumption there saves a wrong blueprint here.

The seven sections

REASONS is an acronym for the seven sections every canvas contains. Each section answers a specific question, so no two plans skip the same thing:

Requirements: The core problem and the value it delivers, distilled from the analysis to a few sentences. It states the “what” and “why” in plain terms, so the plan stays anchored to the ask.
Entities: The domain model: the concepts involved, their attributes, and how they relate, rendered as a diagram using the actual names from the analysis’s domain-concept work, so the data model is easy to see.
Approach: The chosen solution direction and key design decisions, taken from the analysis’s strategic approach and adapted to the service’s real technology stack rather than a generic framework or pattern.
Structure: The architecture: which components exist, how they relate to one another, and the call and dependency relationships between them, shaped to the service’s actual stack rather than a one-size-fits-all layered model.
Operations: The concrete, executable implementation tasks. Each task spells out what to build, why (which acceptance criterion or business rule from the analysis it satisfies), how (steps appropriate to the stack), and under what constraints, so the plan reads as work rather than abstraction.
Norms: Your organization’s standards, applied to this specific feature, with each relevant norm named and explained in terms of how it constrains this implementation in this service.
Safeguards: The hard limits, stated concretely for this implementation, with each safeguard named and what it means in practice for the work at hand.

The Entities section is a diagram (REEZN renders it as a class diagram right in the canvas), while the rest are written sections. Norms and Safeguards reflect the standards and limits set for the project (org-wide or scoped), so the plan is judged against your real rules rather than a default.

Reviewing, editing & exporting

A canvas opens with every section collapsed. Expand any section to read it; while it is awaiting approval, a tech reviewer can edit a section in place to fix or sharpen it without disturbing the other six. When the plan is right, the reviewer approves that service’s canvas.

Once every canvas on a feature is approved, the generation preview unlocks: each approved canvas can be copied to the clipboard or downloaded as a markdown file to hand to your engineers or feed to an AI coding tool as grounded context.

Why this exists

A blueprint is the shared reference everyone, including your AI tools, works from. Because it is structured and grounded in the analysis, disagreements surface during review, when they are cheap to fix, instead of after the code is written. The acronym keeps every plan answering the same seven questions, so nothing important gets skipped, and splitting it per service keeps each plan honest about the stack it actually runs on.