> ## Documentation Index > Fetch the complete documentation index at: https://docs.zenable.io/llms.txt > Use this file to discover all available pages before exploring further. # Policy-Based Auto-Approvals > Turn analyzer quality scores into automated approvals with policies you define ## Overview **Policies you define** decide which analyzer proposals move forward without waiting for a person. Zenable's analyzers already score every proposal against a rubric; a policy turns that score into an automated decision — accept proposals at or above a threshold, optionally decline proposals below a floor, and leave everything in between for human triage on [Proposals](/proposals). Nothing is auto-approved unless a policy you created says so. Policies never bypass [approval workflows](/approval-workflows). If an approval flow gates the change, an automated approval files the same request a human would — governance stays the intentional last stop. A policy only replaces the *triage click*, not the approval. Configure policies under **Approvals → Approval Policies**. ## What can be policy-accepted Each policy selects one or more proposal kinds: | Proposal kind | Produced by | What accepting does | | - | - | - | | New requirement proposals | Repository analysis of merged PRs | Promotes the proposed requirement to an active (beta) requirement and queues guardrail generation | | Requirement refinements | Requirement refinement | Promotes the proposed new version to the family's live version | | Requirement merges | Requirement evolution analysis | Promotes the merged requirement, records lineage, and deprecates the source requirements | | Requirement splits | Requirement evolution analysis | Promotes every split result, records lineage, and deprecates the source requirement | Merges and splits apply atomically: nothing changes until the whole operation (and any approval gating it) completes. ## Policies A policy is the unit of configuration — create as many as you need: * **Accept threshold (0–10)** — proposals scoring at or above this are accepted automatically. * **Decline floor (0–10, optional)** — proposals scoring below this are declined automatically and move out of the triage queue. Zenable defaults to 6 and allows customization on the Agent Policies page. * **Target selector (optional)** — narrow the policy to matching proposals using a reusable [target selector](/approval-workflows#target-types), e.g. only proposals for certain scopes or from a specific analysis source. * **Daily cap (optional)** — a per-policy limit on automated accepts per day, on top of the tenant-wide daily budget. Proposals over budget simply wait for the next day (or a person). * **Enabled** — disabled policies keep their configuration but never act. Zenable provisions each tenant with a **Zenable default** policy as a starting point. It's yours to tune or delete — but editing turns it into your own policy, so you'll be asked to give it a new name (the "Zenable default" name is reserved for the policy as Zenable shipped it). ### When policies overlap If several enabled policies match the same proposal, the **strictest threshold wins** — the proposal must satisfy every matching policy's bar to be accepted. A decline only happens when every floor-bearing policy would decline it **and** no matching policy would individually accept it; conflicting policies land the proposal on a human instead. ### Policies are governed changes Approval policies decide what moves forward without a person, so changing one is itself gateable: approval flows can target `approval_policy_create`, `approval_policy_update`, and `approval_policy_delete`. A tenant can require a human sign-off on any change to what a policy accepts. ## Scoring rubrics Every proposal kind is scored against a rubric of up to six weighted dimensions. Zenable ships built-in rubrics per kind; each dimension's description is the verbatim instruction the scoring model follows. * **Customize** a rubric under **Approvals → Policy evaluation → Scoring Rubrics** — the editor seeds from the built-in defaults so you tune rather than start blank. * **Tenant default** — mark one rubric per kind as the default; analyzers use it whenever no configuration profile picks a different one. * **Configuration profiles** can link specific rubrics, so different repos can be scored against different bars. Scores are computed when the proposal is created and stored with it — editing a rubric affects future proposals, not the existing queue. ## How runs work The policy evaluation engine runs on Zenable's analysis scheduler (roughly daily) and compares each open proposal's stored score against your policies. You can also trigger a run on demand with **Run now**. Automated accepts show a **Policy-accepted** badge on Proposals, and every accept records which policies set the binding bar. A tenant-wide daily budget bounds total automated accepts per day, independent of per-policy caps, so a runaway analyzer can never flood your requirement set. ## Reviewing evaluation runs **Agent Evaluations** (under **Approvals → Agent Evaluations**) lets you browse the last 30 days of policy evaluation runs and inspect every proposal each run considered. See how your agent policys are working with a sankey chart, and adjust your thresholds while seeing how it would affect your current proposals. ## Required Permissions | Permission | Grants | | - | - | | `approvals:read` | View approval policies and Agent Evaluations | | `approvals:manage` | Create, edit, and delete approval policies; trigger a run; apply threshold changes | | `settings:read` | View scoring rubrics | | `settings:manage` | Create, edit, and delete scoring rubrics | See [Roles and Permissions](/permissions) for which roles include these permissions. ## API Reference ### Approval Policies | Method | Endpoint | Description | Permission | | - | - | - | - | | GET | `/api/data/approval-policies` | List policies (pass `?include_disabled=true` to include disabled) | `approvals:read` | | POST | `/api/data/approval-policies` | Create a policy | `approvals:manage` | | PUT | `/api/data/approval-policies/{id}` | Update a policy | `approvals:manage` | | DELETE | `/api/data/approval-policies/{id}` | Delete a policy | `approvals:manage` | | POST | `/api/data/approval-policies/run` | Schedule a run now | `approvals:manage` | ### Scoring Rubrics | Method | Endpoint | Description | Permission | | - | - | - | - | | GET | `/api/data/approval-policy-rubrics` | List rubrics (filter with `?assessment_kind=`) | `settings:read` | | GET | `/api/data/approval-policy-rubrics/defaults` | Built-in default rubric per proposal kind | `settings:read` | | POST | `/api/data/approval-policy-rubrics` | Create a rubric | `settings:manage` | | PUT | `/api/data/approval-policy-rubrics/{id}` | Update a rubric (new version) | `settings:manage` | | DELETE | `/api/data/approval-policy-rubrics/{id}` | Delete a rubric | `settings:manage` | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.