Policy

A Policy is a rule enforced at design time to prevent unsafe operations from reaching production. Unlike runtime validation, Policies are checked by the Risk Engine before a Tool is deployed. If a Tool violates a Policy, it is either flagged with a warning or blocked from deployment entirely.

Design-Time Enforcement

Fascia follows a "Policy-First" principle: unsafe patterns are caught during the design and review phase, not at runtime. This means that by the time a Tool is deployed and executing in your GCP environment, it has already passed all safety checks.

The Risk Engine analyzes every Tool spec and its Flow graph to classify risk. Policies define the specific rules that the Risk Engine evaluates.

Policy Spec Structure

A Policy spec includes:

Field	Description
name	Unique identifier in camelCase (e.g., maxRowLimit, budgetCheck)
type	Category of the policy
condition	Value DSL boolean expression that defines the rule
action	What happens when the condition is violated

Policy Types

Type	Purpose	Example
rowLimit	Prevent operations that affect too many rows	Block updates touching more than 1000 rows
budgetCheck	Ensure financial operations stay within bounds	Warn if payment exceeds configured threshold
rateLimit	Limit how frequently a Tool can be invoked	Block more than 100 calls per minute
custom	User-defined business rules	Require manager approval for discounts over 50%

Policy Actions

When a Policy condition is violated, one of three actions is taken:

Action	Behavior
block	The Tool cannot be deployed until the violation is resolved
warn	The Tool can be deployed, but the user must acknowledge the warning (logged in audit)
escalate	The violation is flagged for manual review by an admin

Invariants

While Policies operate at design time, Invariants operate at runtime as part of the Execution Contract. An Invariant is a business rule that must always hold true for an Entity.

Invariants are defined in the Entity spec as Value DSL boolean expressions. They are enforced at step 6 of the Execution Contract -- after the flow graph executes but before the transaction commits. If any invariant evaluates to false, the entire transaction rolls back.

Examples of invariants:

• reservation.endDate > reservation.startDate -- End date must be after start date
• order.totalPrice > 0 -- Order total must be positive
• account.balance >= 0 -- Account balance cannot go negative

Risk Engine

The Risk Engine is the automated system that evaluates Policies against Tool specs. It assigns one of three risk levels:

Level	Meaning	Deployable?
Green	All safety patterns satisfied	Yes
Yellow	Warning-level concerns detected	Yes, with user acknowledgment
Red	Critical safety violations found	No -- must be resolved

Red-level Tools are blocked from deployment with no exceptions and no overrides. The violations must be fixed in the Tool spec before resubmitting.

The Risk Engine also provides auto-fix suggestions for common violations, such as wrapping writes in a Transaction boundary, adding Retry nodes to external calls, or converting hard deletes to soft deletes.

For the full list of risk classification criteria, signals, and auto-fix suggestions, see the risk rules reference.