Docs / Concepts

Living blueprints

A living blueprint is REEZN’s always-current description of one of your services: what it does, the concepts it works with, its key operations, rules, and integrations, written from the code as it stands today. Where a feature’s documents describe a change, the living blueprint describes the system the changes land in, and REEZN keeps it true as the system evolves.

Not the same thing as the REASONS canvas, which some teams also call a blueprint: a canvas is the approved plan for one feature in one service, frozen once delivered. The living blueprint is the service’s current state, and it moves forward with every change.

Living blueprints are available on every plan; the Free plan covers up to 2 services. Automatic drift checks are available on the Team plan and higher.

Generating one from your code

From a project’s System page, an admin picks the services to document and REEZN reads each connected repository and drafts its blueprint. Nothing is published automatically: each draft arrives as a proposal for a human to review, edit if needed, and approve. Only an approved blueprint becomes the current one.

This is also the fastest way to put an existing codebase to work in REEZN: on day one, before any feature has run, your services get reviewed, readable documentation, and everything an approved blueprint describes flows into your knowledge base, so new plans are grounded in your real system immediately.

Reading it and reviewing updates

Each service’s blueprint has two views. The reading view shows the current, approved document. When an update is proposed, a notice appears above it and reviewing opens a focused view that highlights exactly what would change against the current version, with the reason the update exists: a repo scan, a feature you delivered, or detected drift. Approve to make it current, or reject it; the previous version stays in the history either way.

How it stays current

Deliver through REEZN, and the blueprint follows: when a feature reaches Delivered, REEZN folds the approved plan into each affected service’s blueprint and proposes the updated version for a one-click review.
Drift checks catch everything else (Team plan and higher): on a cadence you set per service, REEZN compares the repository against the current blueprint. When code has moved on in a way the document doesn’t reflect, it proposes an update with a summary of what drifted; routine churn is filtered out and costs you nothing.

Drift checks run on your own AI key, and only when the code has actually changed in a meaningful way, so keeping documentation honest stays cheap.

Where it pays off

Onboarding: new engineers read an approved, current description of each service instead of tribal knowledge and stale wikis.
Planning: approved blueprints feed your knowledge base, so analyses and canvases speak in your system’s real terms.
Coding agents: over MCP, an agent can pull a service’s current blueprint before touching its code.

Why this exists

Documentation fails because keeping it true is manual. A living blueprint flips that: it is generated from the code, updated as a side effect of shipping, checked against reality on a schedule, and gated by human approval, so your team always has a description of the system it can actually trust.