Docs / Concepts

Norms & patterns

Norms are your organization’s technical standards, conventions, and proven patterns. They are captured once and injected into every analysis and canvas the AI generates, so each plan reflects the way you actually work.

They are how you turn the unwritten rules a team carries in its head (naming conventions, the patterns you reach for, the things you’ve learned not to do) into something explicit the AI can plan against. A norm guides: it shapes how work should be done without being a hard wall. (For the lines that must never be crossed, see safeguards.)

What a norm contains

Each norm has four parts. The short description is what you see in the library list; the full body is the detailed text that gets injected into plans, so it is worth spelling out examples and exceptions there.

Category: A grouping so the library stays organized: Architecture, Software Design, Naming, Testing, Security, Observability, Error Handling, Data & Persistence, Tooling, Dependencies, Documentation, or Other. Norms are listed grouped by category.
Name: A short, memorable label for the rule, for example “Entities are PascalCase singular.”
Short description: A one-line summary shown in the library list: the gist of the rule.
Full body: The detailed explanation, with examples and exceptions. This is the text the AI reads when generating plans, so the more concrete it is, the better the result.

For example: a norm named “Repository pattern,” categorized under Naming, described as “No direct ORM calls from controllers,” with a body that explains why and shows the wrapper to use instead.

Who manages them

Norms live in the Norms library, alongside safeguards. Only org admins can add, edit, or delete them; everyone else sees them reflected in the plans they read and review. Keeping authorship with admins means the library stays a deliberate, curated statement of how your org works rather than a free-for-all.

Org-wide or project-scoped

A norm can apply across the whole organization, or be scoped to a single project, so a rule that only makes sense for one domain doesn’t leak into others. Org-wide norms set the baseline every project inherits; project-scoped norms layer on the specifics that domain needs. Together they form a living library the whole team keeps current.

Extracting norms from your code

Writing every norm by hand is a fine place to start, but plenty of conventions already exist in a codebase, just never written down. Point REEZN at a service’s connected repo and it reads what’s there, a README, CONTRIBUTING guide, lint and formatter configs, and proposes the norms it finds already at work.

Open the Norms library, or a project’s Norms page, and click “Extract from code.”
Select one or more services that have a repo connected. Services without one are shown but can’t be selected.
Run the extraction and watch it work through each service, one at a time.
Review what it proposed, and approve or reject each one.

Extracted norms come in as proposals, carrying the project of the service they came from and a badge naming their source. A proposal is never fed into AI generation until an admin approves it, at which point it becomes a normal, live norm. Reject one instead and it’s permanently removed, no harm done, since re-running the extraction is cheap.

Extraction uses your organization’s AI key and works on every plan.

Your codebase isn’t the only source of proposals. A production incident is a second one: point REEZN at an incident report or postmortem and it proposes norms the same way, plus safeguards, the hard limits that would have caught the failure. See from incident to safeguard for the full flow.

How they shape your plans

Norms aren’t a checklist run after the fact. They are part of the context the AI generates from, so they show up in both artifacts:

In the analysis document, the project’s norms are part of the picture from the start, and any conflict or gap with them surfaces in the Risk & Gap Analysis. Where a requirement runs against the way you work, the tension is named rather than quietly designed around.
In the REASONS canvas, the Norms section must address each relevant norm by name, explaining how it constrains this specific feature in this service, so the plan is judged against your real standards rather than generic best practice.

A norm’s body is what REEZN reasons with, so its wording carries real weight. Vague norms produce vague guidance; specific ones, with examples and the “why,” produce plans that follow your conventions.

Why this exists

Norms turn tribal knowledge into something explicit and reusable. Instead of hoping each plan happens to follow your conventions, or relitigating them in every review, you state them once and every plan reflects them. And because they guide rather than forbid, the AI can flag a conflict for a human to weigh instead of treating every standard as an immovable wall.