Guardrails

Guardrails are the primary governance mechanism in Cesteral Intelligence. Every action the AI proposes — whether from a conversation, an automation, or a scheduled job — is evaluated against your active guardrails before it can execute.

In the product, guardrails are configured under Policies > Blocking rules.

How Guardrails Work

When the AI proposes an action, the platform builds a structured evaluation input describing the action and its context, and an action manifest — a structured record of exactly what will change, the safeguards that ran, and the resulting confidence. Guardrails evaluate the input using JSONLogic expressions before the action is allowed to execute.

The evaluation input exposes several namespaces that your conditions can reference:

• input.* — the raw action parameters
• context.* — temporal and preflight signals (time of day, whether the action is destructive or unattended, budget preflight, data freshness, platform, recent action count, and more)
• dryRun.* — dry-run preview signals, populated only when a dry-run ran
• preview.* — a structured write-preview, populated only when one was computed

Each guardrail carries a severity that determines what happens when its condition fails:

• Pass — the action meets every guardrail and continues
• Advisory — informational only; the result is recorded but the action is unaffected
• Warning — the action continues and the violation is recorded for review
• Error — the action is blocked and held in the Queue for human review

Every evaluation result — pass or violation, at any severity — is recorded in the Audit log.

Action Manifests

The action manifest is the structured record of a proposed action. It groups the proposed change together with everything the platform learned while evaluating it:

• identity — the tool, action type, and risk class
• impact — record count, estimated cost, external systems touched, blast radius, and reversibility
• safeguards — which guardrails ran, which passed, the blocking and warning violations, pause state, and trust level
• confidence — the computed confidence score, the reason codes behind it, and its supporting dimensions
• preview — a human-readable summary and a diff of what will change
• provenance — the policy decision, input hash, approving user, and owner

The manifest is shown in the Queue when an action is held for review, alongside the guardrail evaluation results.

Confidence Scores

Every action manifest includes a confidence score representing how safe the platform judges the action to be. The score is bounded (it never reaches 0 or 1) and breaks down into four dimensions:

• Policy — guardrail compliance for this action
• Familiarity — novelty, historical success rate, and tool reliability
• Impact — blast radius, external reach, and financial impact
• Data trust — how fresh the underlying data is

Each score carries reason codes (for example, DESTRUCTIVE_ACTION, STALE_DATA_SOURCES, HIGH_SUCCESS_RATE, CONFIDENCE_WARMUP) that explain why it landed where it did.

Confidence thresholds are configured under Policies > Execution controls, in its Decision thresholds section. An action whose confidence falls below the threshold is held for review, regardless of whether its guardrails passed.

Creating a Guardrail

1. Navigate to Policies > Blocking rules
2. Click Create policy rule
3. Configure:
   • Name — descriptive label (e.g., "Daily budget cap")
   • Condition — JSONLogic expression evaluated against the action's evaluation input, built in the condition builder
   • When violated — the severity: Block the action (Error), Require approval (Warning), or Show a warning (Advisory)
   • Applies to — all actions, campaign launch (a go-live gate), a type of action, or a specific tool
4. Click Create
5. The rule is enabled as soon as it is created; use the switch on its row to turn it off or back on

Severity Levels

Use Error severity when a mutation must not proceed until a human approves it. On the AI/MCP execution rail, both warning and error severities gate the action before it runs. On the in-app server-action path, only error severity (and mandatory compliance reviews) hard-blocks — warning-severity violations let the change apply and file a change set for review afterward.

Enrollment Health

Cesteral ships a set of system guardrails alongside the ones you author. For these, enrollment controls whether the rule is active for your organization — you can toggle a system guardrail on or off, and the list records who changed it.

Related Policies

Blocking rules is one of several pages under Policies. The other policy types are covered in the Policies overview:

• Naming — structural standards for campaign names
• Launch QA — launch readiness checklists

Where Guardrail Results Appear

• Queue — actions blocked or held for human review
• Audit log — full history of every policy evaluation with rule, result, and manifest
• Home and reporting surfaces — aggregate governance KPIs after the fact