Policies
A policy is a reusable definition of what must be true before something goes live. It is an ordered list of stages. Each stage can:
- collect form fields from the team (required fields become requirements),
- require one gate: an acknowledgment, a reviewer approval, a metric threshold, evidence files, a free-form input, or a guardrail confirmation,
- gate resource types: block those types from going live until the requirements are met.
A policy takes effect only when it is published (Active and not a draft) and applied to a solution.
Creating a policy
- Go to Governance > Policies and click Create Policy. The Policy Builder opens with a Policy Details card, a Stages card, and Status and Summary cards on the right.
- Fill in Policy Details, add stages, set the status, and click Save Policy.
The platform validates the whole policy when you save and shows what to fix, for example a stage without a name, an approval gate without a reviewer, a choice field without options, or a stage that gates a type the policy does not apply to.
Policy Details
| Setting | Description |
|---|---|
| Name | Required. A clear name, for example "Production Release Checks". |
| Description | What the policy enforces and why. Shown when people pick policies for a solution. |
| Category | Security, Compliance, Quality, or Operational. Used for filtering. |
| Severity | Critical, High, Medium, Low, or Info. Used for filtering and shown on solutions. |
| Applicable Resource Types | The resource types this policy is about. A stage can only gate types ticked here. |
| Tags | Comma-separated tags, for example soc2, hipaa. |
Stages
Click Add Stage. Each stage opens in its own panel; use the arrows to reorder stages and the trash button to remove one.
| Setting | Description |
|---|---|
| Stage Name | Required, for example "Security Review". |
| Description | What this stage covers. Shown to people completing a gate that has no description of its own. |
| Gated Resource Types | Which of the policy's applicable types this stage blocks from going live. Leave empty for a stage that only collects information. |
Gating carries forward. A stage applies to a resource type once that stage or any earlier stage gates the type. So if stage 2 gates app, an app go-live needs the requirements of stages 2, 3, 4, and so on, but not stage 1. Put information-only stages first and the stages that must block after them.
Form fields
In a stage, click Add Field and set:
| Setting | Description |
|---|---|
| Name | Machine name, unique within the stage (for example risk_level). |
| Label | What people see. |
| Type | Text, Textarea, Rich Text, Radio, Checkbox, Dropdown, Multi-Select, File, Number, Date, Date/Time, URL, or Email. |
| Placeholder / Help Text | Hints shown with the input. |
| Required | Only required fields become requirements. Optional fields are not tracked. |
| Options | For Radio, Dropdown, Checkbox, and Multi-Select: the value / label pairs people choose from. At least one is required. |
| Validation (click Show Validation) | Min / Max (Number fields), Min Length / Max Length and Pattern (regex) (text fields), and an Error Message shown when a value fails. |
How each type is answered and checked:
| Type | Answered with | Checked |
|---|---|---|
| Text, Textarea, Rich Text | Free text | Min / Max Length, Pattern |
| Text | Must be an email address, plus the text rules | |
| URL | Text | Must be an http or https URL, plus the text rules |
| File | A text reference to a file (use an Evidence gate to collect uploaded files) | Text rules |
| Number | A number | Min / Max |
| Date, Date/Time | A date | Must be a valid date |
| Radio, Dropdown | One option | Must be one of the options |
| Checkbox, Multi-Select | One or more options | Every choice must be one of the options |
A value that breaks a rule records the requirement as Failed with the reason (your Error Message when you set one), and the person can correct it and submit again.
Gates
Each stage can have one gate. Turn on Optional Gate, pick the Gate Kind, and set Gate Name, Gate Label, and Gate Description (the label and description are what people see on the requirement).
| Gate kind | Configuration | Satisfied when |
|---|---|---|
| Input (free-form field) | Field Type (Text, Textarea, Rich Text, File, Number, Date, Date/Time, URL, Email), Placeholder, Help Text, Min Length, Max Length | A valid value is submitted |
| Acknowledgment (checkbox) | None. The gate label is the checkbox text; put the statement being acknowledged in the gate description. | The box is ticked and submitted |
| Approval (human reviewer) | Approval Logic (Any, All, Majority), SLA Hours, Reviewers (each a User, Role, or Group, picked by name) | The reviewers approve. See Stages & Reviews. |
| Threshold (metric) | Metric Name, Operator (>=, <=, >, <, =), Value, Unit | The submitted metric passes the comparison. A value that does not pass records the gate as Failed until a passing value is submitted. |
| Evidence (file upload) | Allowed File Types (for example pdf, csv), Max File Size (MB) (up to 50), Min Files Required, Labels describing the expected documents | At least the minimum number of files is uploaded |
| Guardrail (AI safety) | Required Guardrail IDs, Minimum Filter Level | Someone confirms, with Verify guardrails, that the listed guardrails are configured on their AI Gateway model. It is a recorded confirmation, not an automatic check. See Guardrails. |
Status
The Status card has two switches:
- Active / Inactive and Draft / Published. A policy is published when it is Active and Published. Only published policies are enforced, show requirements on solutions, and can be added to solutions.
- Drafts are visible only to you and administrators. Published policies are visible to everyone in your organization so they can be applied.
Version is read-only. It starts at 1 and goes up by one each time you change the stages, the severity, or the applicable resource types. Every change is also recorded in the audit log.
The Summary card counts stages, fields, and gates, lists every gated resource type, and warns when the policy has no stages or no required fields.
Managing policies
Governance > Policies lists the policies you can see, newest first, with a search box and All Categories / All Severities filters. Each row shows the category, severity, number of stages, number of requirements (required fields plus gates), and status: Draft, Active, or Inactive.
- Click a row, or the edit button, to open it in the Policy Builder. Only the policy's creator or an administrator can save changes.
- Click the delete button to delete it. A policy that is applied to any solution cannot be deleted; remove it from those solutions first.
What changes do to solutions
- Deactivating a policy or turning it back into a draft removes its requirements from every solution that applies it (they reappear, with their earlier submissions, if you publish it again). Solution statuses update immediately.
- Editing stages changes the requirements of every solution that applies the policy. Submissions for requirements that still exist are kept. If an edit removes a reviewer who had already voted on an approval, an audit entry records the orphaned vote.
- To retire a policy but keep its history, deactivate it instead of deleting it.
Policy examples
Production release checks
Category: Operational · Severity: High · Applicable: App, Workflow
| Stage | Contents | Gates |
|---|---|---|
| 1. Release details | Required fields: change ticket (Text, Pattern ^CHG-[0-9]+$), risk level (Dropdown: Low / High) | nothing |
| 2. Security review | Approval gate: Role admin, logic Any, SLA 48 hours | App, Workflow |
| 3. Sign-off | Acknowledgment gate: "Rollback plan is documented and tested" | (carried forward) |
Apps and workflows in the solution cannot be deployed until the security review is approved and the sign-off is acknowledged. The release details are collected but do not block.
Model quality bar
Category: Quality · Severity: High · Applicable: ML Model
| Stage | Contents | Gates |
|---|---|---|
| 1. Evaluation | Threshold gate: accuracy >= 0.9 | ML Model |
| 2. Bias assessment | Evidence gate: PDF, min 1 file, label "Bias report"; required Textarea field "Findings" | (carried forward) |
| 3. Approval | Approval gate: Users (data science lead, risk officer), logic All | (carried forward) |
Data handling
Category: Compliance · Severity: Critical · Applicable: Data Source, Volume
| Stage | Contents | Gates |
|---|---|---|
| 1. Classification | Required Dropdown field: Public / Internal / Confidential / Restricted | Data Source, Volume |
| 2. Privacy assessment | Evidence gate: privacy impact assessment (PDF, label "PIA") | (carried forward) |
| 3. Privacy review | Approval gate: Group org:<orgId>:role:admin, logic Any | (carried forward) |
Each stage holds at most one gate, so a review that needs both a document and an approval uses two stages.
A stage blocks only the resource types it gates (or that an earlier stage gates). A policy whose stages gate nothing tracks compliance on solutions but never blocks a go-live.