The better Zenable gets at proposing requirements, the more good proposals pile up, and rubber-stamping the obviously-good ones is pure friction, a tax on your reviewers' attention. Approval workflows decide when a human must be in the loop; auto-accept policies decide what doesn't need one. Zenable's analyzers propose new requirements, refinements, and merges and splits of overlapping rules, and every proposal is scored at creation against a rubric you own, with a written rationale. An auto-accept policy turns that score into a decision: at or above your threshold it's accepted automatically, below an optional floor it's declined, and everything in between stays in your Insights triage queue for a person.
The engine is deliberately boring, in the best way. The AI scores once; the accept engine itself never calls a model. It's a deterministic comparison of stored scores against your policies, run on a daily cadence within budgets you set. When multiple policies match, strictest wins: a proposal must clear every matching threshold, and no automation can decline something another policy would have accepted. Conflicts route to a human.
Most importantly, auto-accept lives inside your governance, not around it. An automated accept files the exact same approval request a human accept would, so if an approval workflow gates the target, your reviewers are still the last stop. And the policies themselves are governance objects, so changing what auto-accepts can require sign-off too. Set it up under Approvals → Auto-Accept in the console, start with a high threshold on new-requirement proposals, and widen from there.