> ## Documentation Index > Fetch the complete documentation index at: https://docs.writerzroom.com/llms.txt > Use this file to discover all available pages before exploring further. # Policies > Build conditional review and compliance rules by vertical, claim type, channel, risk level, and destination. **Policies**, under Intelligence in the sidebar, is where conditional review and compliance rules are authored and evaluated. A policy says: *when* the work matches some combination of vertical, claim type, channel, risk level, and destination, *then* it requires a review, a disclosure, or must not go out at all. Evaluation is a pure function of the policy set and the context. The same context always produces the same requirements, which is what lets the result stand as an audit record rather than an opinion — a decision can be re-derived later from the rules as they stood. ## How conditions match * An **empty** condition list is a wildcard for that dimension. * **Within** a dimension, values are OR-ed; **across** dimensions they are AND-ed. A policy naming two channels and one vertical fires on either channel, but only inside that vertical. * Claim types match on any overlap, since a piece may carry several at once. A policy with every dimension empty matches all work. That is a legitimate blanket rule and also what an accidentally-empty form produces, so such policies are flagged in the list and in every evaluation rather than applying quietly. ## Effects Strongest first: `block`, `require_review`, `require_disclosure`, `advisory`. A context that trips both a blocking rule and an advisory one is blocked — and the advisory still appears in the result, so a reviewer sees everything that fired rather than only the decisive rule. Requirements from every applying policy are merged. Reviewer roles and disclosures are unioned; the strictest evidence floor wins, because a rule asking for three sources is not satisfied by another asking for one. ## Unknown context is not a pass If a policy is conditioned on a dimension the caller did not supply, the rule is neither applied nor discarded. It is reported under **indeterminate**, naming the fields that were missing. Failing open here would drop a required legal review because a channel field was blank, and it would do so silently. Failing closed would demand reviews nobody can explain. Reporting it is the only honest option, and it tells you exactly which field to fill in. Disabled policies contribute nothing — a paused rule cannot supply a requirement or a block. ## Evaluating and simulating The evaluate view runs a publication context against every enabled rule and reports what applied, what did not, what could not be settled, and the merged requirements. A single policy can also be simulated against a context regardless of its enabled state, so a draft rule can be checked before it starts affecting anything. Policies are authored and evaluated here. The pipeline's own approval routing continues to come from the vertical and template configuration — this is the authoring and evaluation surface for those rules, not a second enforcement path. Where a required review is carried out. Disclosures a market variant must carry.