Policy Types
Lifecycle Policies
Lifecycle policies track technology lifetime events: end-of-life dates, version currency, certificate expiration, and compatibility windows. These are system policies, configured and maintained by Draftt. System policies available today:| Policy | What It Tracks |
|---|---|
| End of Life | Vendor EOL dates for every technology in your inventory. Assigns statuses based on proximity to EOL. |
| Latest | Whether each component runs the latest stable or LTS version. |
| Certificate Expiration | SSL/TLS certificate validity windows across your infrastructure. |
| Kubernetes Compatibility | Kubernetes version compatibility between clusters, nodes, and workloads. |
System policies are managed by Draftt and cannot be edited. Customizable system policies are on the roadmap.
Governance Policies
Governance policies let you define your own standards. You set the rules, define the statuses, and Draftt evaluates every matching resource on every scan cycle. Use governance policies to enforce standards around configuration, compatibility, alignment with golden configurations, tagging, resource-specific settings, and anything else you can express as a filter condition. Currently supported resource types:| Resource Type | Status |
|---|---|
| Infrastructure | Early Access |
| Certificate | Early Access |
| Kubernetes | Early Access |
How Policies Work
Every policy, whether lifecycle or governance, follows the same evaluation loop:- Scope - A DrafttQL query defines which resources the policy evaluates. If no query is set, the policy evaluates all resources of its type.
- Evaluate - For each resource in scope, Draftt walks through status assignments from highest criticality to lowest, testing each rule block.
- Assign - The first matching status wins. If no rules match (and prerequisites existed but none were met), the resource gets an “Unknown” status. Otherwise it receives the default status.
- Surface - Statuses appear on the Policies page, in dashboard breakdowns, and in inventory sidebar filters.
Anatomy of a Governance Policy
Each governance policy consists of:Status Map
Define the statuses that matter for this policy. Each status has a name, a criticality number (higher = more critical), and an optional color (hex). For example, a tagging compliance policy might define:| Status | Criticality | Meaning |
|---|---|---|
| Compliant | 0 | Resource meets all tagging requirements |
| Non-Compliant | 10 | Resource is missing required tags |
Default Status
The status assigned to any resource that does not match any rule. For governance policies this is typically “Compliant” (the resource passes by default unless a rule explicitly flags it).Status Assignment Rules
For each non-default status, you define one or more rule blocks. Each rule block contains: Prerequisites (optional) - Filter conditions that determine whether the rule block should evaluate a given resource at all. If a resource does not match the prerequisites, that rule block is skipped for that resource. Example: A rule checkingautoMinorUpgrade on RDS instances would set a prerequisite filtering to only RDS resources, so the rule does not evaluate non-RDS infrastructure.
Conditions - Filter conditions (key, operator, value) that determine whether a resource matches this rule block. Conditions within a block use AND logic. Multiple condition blocks under the same status use OR logic: a resource matching any block is assigned that status.
Resource Scope (Query)
An optional DrafttQL query that narrows which resources this policy evaluates. Without a query, the policy runs against all resources of its type.Creating a Custom Policy
Navigate to Policies
Open Policies from the main navigation. You will see system policies and any existing custom policies.
Define Statuses
Add the statuses you need. Set a criticality number for each (higher = more severe). Optionally assign a color. Choose which status is the default.
Build Rules
For each non-default status, add one or more rule blocks:
- Set prerequisites if the rule only applies to a subset of resources (e.g., only RDS instances, only resources in a specific region).
- Add conditions using the field dropdown, an operator, and a value. Conditions within a block are AND-joined. Add multiple blocks under the same status for OR logic.
autoMinorUpgrade for RDS, invocationCount for Lambda).Some fields automatically add implicit prerequisites when selected.Scope (Optional)
Narrow the policy to specific resources using a DrafttQL query. Leave empty to evaluate all resources of the selected type.
Where Policies Appear
Once active, policy data is available across the platform: Policies Page - View all policies, their status breakdowns, configuration, and last evaluation timestamp. Re-evaluate any policy on demand. Dashboard - Select any policy from the dropdown to view its status breakdown over time. Track governance trends alongside lifecycle trends. Inventory - Filter the inventory sidebar by policy. View all resources under a policy with their assigned status. For governance policies, the table shows only relevant columns (no due date or urgency fields).Policy Evaluation Details (Early Access)
A detailed explanation of which specific rule blocks and conditions caused a resource to be assigned its current status. This will be visible per-resource when inspecting policy results.Policy API (Early Access)
Create, edit, and evaluate policies programmatically via the Draftt API. Currently, all policy management is through the UI.Policy Recipes (Early Access)
A library of pre-built governance policy templates for common use cases (tagging standards, configuration baselines, compatibility gates). Select a recipe, customize it, and activate.Notifications (Early Access)
Trigger notifications when a resource enters a specific status under a policy. Route alerts to Slack, email, or ticketing integrations based on status transitions.Next Steps
- Review your Tech Debt Inventory to understand what resources policies will evaluate
- Connect Integrations to route policy violations to your ticketing and collaboration tools