Policies

Policies are the foundation of the governance framework. Each policy defines an ordered list of stages. A stage collects form fields from the team, can require a gate (such as a human approval or an evidence upload), and can block selected resource types from deploying until its requirements are satisfied.

Policies do nothing on their own. They take effect when they are added to a Solution that contains the workloads you want to govern.

Policy Structure

A policy definition includes:

Field	Type	Description
name	String	Descriptive name (e.g., "Production Deployment Approval")
description	String	Purpose and scope of the policy
version	Number	Starts at 1 and increments automatically on significant changes (stages, severity, or applicable resource types)
category	Enum	Security, Compliance, Quality, or Operational
severity	Enum	Critical, High, Medium, Low, or Info
applicableResourceTypes	String[]	Resource types this policy applies to
stages	Array	Ordered list of stages with fields, an optional gate, and gated resource types
isActive	Boolean	Whether the policy is currently enforced
isDraft	Boolean	Whether the policy is still in draft mode
tags	String[]	Free-form tags (e.g., gdpr, hipaa, soc2)
versionHistory	Array	Prior versions with who changed them and when

Creating a Policy

Step 1: Open the Policy Builder

1. Navigate to Governance > Policies in the sidebar
2. Click Create Policy (or navigate to /governance/policies/new)
3. The Policy Builder opens as a single page with a Policy Details card, a Stages card, and Status/Summary cards on the right

Step 2: Define Policy Details

Configure the core policy metadata in the Policy Details card:

• Name (required), a descriptive name that clearly identifies the policy's purpose (e.g., "Data Privacy Compliance")
• Description, what the policy enforces and why it exists
• Category, the policy's domain:
  • Security, access control, encryption, vulnerability management
  • Compliance, regulatory requirements, data handling, privacy
  • Quality, review, testing, performance standards
  • Operational, deployment procedures, monitoring, incident response
• Severity: Critical, High, Medium, Low, or Info
• Applicable Resource Types, which resources this policy applies to: Workflow, App, Addon, Data Source, Volume, ML Model, AI Gateway Model, Workspace, Project
• Tags, a comma-separated list (e.g., gdpr, hipaa, soc2)

Step 3: Configure Stages

Policies consist of ordered stages. Click Add Stage in the Stages card; each stage expands in an accordion and is configured with:

Setting	Description
Stage Name	Descriptive name (e.g., "Security Review")
Description	What this stage covers
Order	Position in the workflow; use the up/down arrows to reorder
Gated Resource Types	Which resource types this stage blocks from deploying until its requirements are satisfied. Empty means the stage collects information but blocks nothing. Gating is cumulative: once a resource type is gated by a stage, it stays gated in all later stages.
Required Stage	Toggle between Required and Optional

Stage Form Fields

Each stage can define form fields that the team completes. Click Add Field and configure the name, label, and type:

Field Type	Description	Use Case
text	Single-line text input	Short answers, identifiers, names
textarea	Multi-line text input	Descriptions, justifications
richtext	Long-form text	Documentation, analysis reports
radio	Single selection from options	Yes/no, severity level
checkbox	Multiple selection checkboxes	Compliance checklist items
dropdown	Single selection dropdown	Category selection, environment
multiselect	Multiple selection dropdown	Select tags or frameworks
file	File reference	Evidence documents, test reports
number	Numeric input	Metrics, scores, counts
date	Date picker	Target dates, review dates
datetime	Date and time picker	Scheduled events, deadlines
url	URL input	External documentation, dashboards
email	Email input	Contact for responsible parties

Each field supports these properties:

• Label, human-readable display label
• Required, whether the field must be completed (only required fields count toward compliance)
• Placeholder, placeholder text in empty fields
• Help Text, guidance shown with the field to explain what is expected
• Options, value/label pairs for radio, checkbox, dropdown, and multiselect fields
• Validation, min/max values, min/max length, a regex pattern, and a custom error message

Stage Gates

Each stage can optionally include one gate. Toggle Optional Gate on and pick the gate kind:

Gate Kind	What Satisfies It
Input (free-form field)	A value is submitted for the configured field type; length validation applies
Acknowledgment (checkbox)	The developer ticks a checkbox confirming they have read and accept the gate description
Approval (human reviewer)	The configured reviewers approve; see below
Threshold (metric)	A submitted metric value passes the configured operator (>=, <=, >, <, =) against the target value
Evidence (file upload)	The minimum number of files is uploaded; allowed file types and a max file size can be configured, plus labels describing what to upload
Guardrail (AI safety)	The developer verifies that the listed guardrails are configured on their AI Gateway model; see Guardrails

Approval gate configuration:

• Reviewers, one or more reviewers, each assigned by type:
  • User, a specific user ID; only that user can approve
  • Role, any user holding the role (e.g., admin) can approve
  • Group, organization membership; use org:<orgId> for any active member or org:<orgId>:role:<memberRole> to require a specific membership role
• Approval Logic, how many reviewers must approve:
  • Any, a single approval is sufficient
  • All, every reviewer must approve
  • Majority, more than half must approve
• SLA Hours, the expected review turnaround; the elapsed time is shown alongside pending approvals

A single denial fails the gate. Administrators can always approve or deny any approval gate, and can overturn an already-decided gate (the override is marked distinctly in the audit trail).

Step 4: Set Status and Save

The Status card on the right controls:

• Active / Inactive, only active policies are enforced
• Draft / Published, draft policies are not enforced and are only visible to you, users you share with, and administrators
• Version, read-only; increments automatically when stages, severity, or applicable resource types change

The Summary card shows stage, field, and gate counts plus every resource type the policy gates, and warns when a policy has no stages or no required fields.

Click Save Policy. To take effect, the policy must be Active, Published, and added to a solution that contains the target workloads.

Managing Policies

The Governance > Policies page lists your policies with search and category/severity filters. Each row shows the stage count, gate count, and status (Active, Draft, or Inactive). Click a row to edit it in the Policy Builder, or use the delete button to remove it.

A policy that is used by one or more solutions cannot be deleted; remove it from those solutions first. Deleting a policy also deletes its gate submissions.

Policy visibility follows a simple model: you always see policies you created and policies shared with you; active, published policies are visible to other users in your organization so they can be applied to solutions.

Gate Submission Lifecycle

When a policy is applied to a solution, every required field and gate becomes a requirement with a status:

Status	Description
pending	Not yet submitted, or an approval is still awaiting reviewers
satisfied	The submission met the gate's requirements
failed	The submission did not pass (a denial, a missed threshold, or failed validation)
waived	An administrator waived the requirement with a documented reason

The solution's overall status is computed from its requirements: Compliant when everything is satisfied or waived, Non-Compliant when anything has failed, and In Progress otherwise.

Every submission, approval, denial, and waiver is recorded in the audit trail.

Policy Examples

Production Deployment Approval

Category: Operational | Severity: High | Resources: App, Workflow

Stage	Gate	Purpose
1. Security Review	Approval (role: security team)	Validate security requirements and scans
2. Technical Approval	Approval (user: lead engineer)	Approve technical implementation
3. Business Sign-off	Approval (user: product owner)	Confirm business requirements met

Gate the app and workflow resource types on stage 1 so deploys are blocked until all three stages complete.

Data Privacy Compliance

Category: Compliance | Severity: Critical | Resources: Data Source, App

Stage	Requirements	Purpose
1. Data Classification	Required dropdown field (Public / Internal / Confidential / Restricted)	Classify data sensitivity level
2. Privacy Impact Assessment	Evidence gate (PDF upload)	Document privacy implications
3. Legal Review	Approval (group: legal team)	Approve data handling procedures

AI Model Safety Validation

Category: Quality | Severity: High | Resources: AI Gateway Model, ML Model

Stage	Requirements	Purpose
1. Performance Metrics	Threshold gate (accuracy >= 90)	Document model accuracy
2. Bias Analysis	Evidence gate + textarea field	Assess model for bias across protected groups
3. Guardrail Verification	Guardrail gate (e.g., pii-filter, toxicity-filter)	Verify required guardrails are enabled
4. Model Approval	Approval (user: data science lead)	Final deployment approval

Infrastructure Security

Category: Security | Severity: Critical | Resources: Addon, Data Source

Stage	Requirements	Purpose
1. Encryption Verification	Acknowledgment gate	Confirm encryption at rest and in transit
2. Access Control Review	Approval (role: security)	Review access policies
3. Network Isolation	Approval (user: infrastructure lead)	Confirm network segmentation

Important

A stage only blocks deployment for the resource types listed in its Gated Resource Types. A policy whose stages gate no resource types still tracks compliance, but never blocks a deploy. See Enforcement for how blocking works.