Docs / Concepts

Safeguards

Safeguards are the non-negotiables: privacy boundaries, usage caps, compliance rules, and the things that are simply off the table, no matter what the AI suggests. Every plan REEZN generates must respect them.

Examples: “Never log personally identifiable information,” “No synchronous calls to the payments provider in a request path,” “All data at rest must be encrypted.” Like norms, safeguards are captured once and injected into every analysis and canvas the AI generates, but where a norm guides, a safeguard draws a hard line.

Safeguards vs. norms

Safeguards and norms live side by side in the same library and feed the AI the same way, but they play different roles, and the difference matters:

A norm guides: It captures how work should be done, a convention or proven pattern. When a requirement runs against a norm, the AI surfaces the tension so a human can weigh it; a norm can bend when there is good reason.
A safeguard constrains: It is a hard limit that cannot be overridden at the feature level. REEZN never plans around one: a requirement that collides with a safeguard is flagged as a conflict for a human to resolve, not quietly designed away.

In the library, each safeguard carries a “Hard limit” badge, a clear signal that this is a wall, not a preference.

What a safeguard contains

A safeguard is deliberately spare: just two fields, because a hard limit should be unambiguous. There is no category and no long body to interpret; the rule states itself.

Name: A short, declarative label for the limit, for example “No PII in logs or event payloads.”
Description: A one-line statement of what the limit means in practice, for example “Customer name, email, address never appear outside primary records.” This is the text the AI reads when generating plans.

Who manages them

Safeguards live in the Norms library, under their own Safeguards tab alongside norms. Only org admins can add, edit, or delete them; everyone else sees them reflected in the plans they read and review. Because safeguards are the rules that matter most, keeping authorship with admins makes the list a deliberate, governed statement of the lines your org won’t cross.

Org-wide or project-scoped

A safeguard can apply across the whole organization, or be scoped to a single project, so a limit that only makes sense for one domain (say, a payments-specific rule) doesn’t spread to every plan. Org-wide safeguards set the floor every project inherits; project-scoped ones add the limits a particular domain demands.

How they’re enforced

Safeguards 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 by name:

In the analysis document, the project’s safeguards are in scope from the start, and any requirement that conflicts with a hard limit is flagged. That clash appears in the Risk & Gap Analysis, surfaced rather than silently worked around.
In the REASONS canvas, the Safeguards section must address each safeguard by name, stating what it means concretely for this specific feature in this service, and a relevant safeguard can also appear as a constraint on individual tasks in the Operations section.

A safeguard’s description is what REEZN reasons with, and every plan is judged against it by name. State the limit plainly and concretely so there is no room to interpret around it.

From incident to safeguard

A production incident is often the clearest evidence you’ll ever have for what a safeguard should say. REEZN lets an org admin turn an incident report or postmortem directly into proposed safeguards and norms, so the lesson your team paid for in an outage becomes an enforced rule on every future plan, instead of resting in a document nobody re-reads.

From the Norms library, click “From incident.”
On the incident page, give it a short title and paste the incident report or postmortem.
Submit it. REEZN analyzes the report in the background and proposes safeguards, hard limits that would have blocked or flagged the failure, and norms, durable conventions the incident shows your team needs.
Review the proposals as soon as analysis finishes, right there on the incident page, or come back to them later from the Norms library, and approve or reject each one.

Proposals from an incident carry a “From incident” source badge and go through the same review as norms extracted from code: a proposal is never fed into AI generation until an admin approves it. Approve one and it becomes a normal, live safeguard or norm, applied org-wide; reject one and it’s removed outright, no harm done.

Proposed safeguards land on the Safeguards tab and proposed norms on the Norms tab of the library, alongside anything proposed from code, so reviewing them is the same habit either way.

Once approved, the safeguard is injected into every analysis and canvas from then on, exactly like any other safeguard, and it is also checked again at delivery verification. What the incident taught your organization stops being a lesson people have to remember to apply and becomes a rule REEZN enforces automatically, on every plan and every delivery.

Turning an incident into proposals uses your organization’s AI key and is available on every plan. Only an org admin can submit an incident report or approve what it proposes.

Why this exists

Norms guide; safeguards constrain. Keeping them distinct lets a reviewer tell immediately whether something is a style preference or a hard rule, and means the rules that matter most are never silently traded away. Privacy, compliance, and safety boundaries shouldn’t depend on anyone remembering them in the moment. Stated once as a safeguard, they are enforced on every plan automatically, and any requirement that would breach one is forced into the open where a human decides. Turning an incident into a proposed safeguard closes that loop for the lessons that cost the most to learn: the hardest-won judgment an organization has is what production already taught it, and that judgment should compound as an enforced rule, not fade as a postmortem nobody reopens.