# What a policy is, and how it is applied

Canonical: https://www.meshqu.com/knowledge/policy-application

What is a policy in MeshQu, and how is it applied to a decision?

A policy is a named, versioned configuration applied to a decision context. The rules come from the approved policy, and a recorded assessment is tied to the policy version that governed it. Ordinary evaluation uses the active version; a frozen form can use its eligible, ratified pinned version. The verdict is advisory: your systems control the action. Human ratification governs policy changes; maker-checker separation depends on the tenant setting.

## In more detail

Use the approved policy to identify the rules a decision is checked against; the recorded assessment is tied to the governing policy version, which is not a claim that the receipt records the outcome for each individual rule. Ordinary evaluation resolves the active version. A frozen form instead evaluates against the exact policy version pinned on it, which must be eligible and ratified; a superseded but ratified version can therefore continue to govern that form while a newer version is active. Reading a draft or historical version never changes evaluation. Ratifying a policy change makes it active. Tenants can enable maker-checker enforcement so that the ratifier cannot be the draft author; when it is disabled, self-ratification is possible. Shadow mode turns a deny verdict into an alert for observation. Your application continues to own enforcement in every case.

## Limits

- MeshQu does not block, allow or modify an operation. It returns a verdict, and the calling application acts on it.
- Submit and reject are documented as available in a future release; the action matrix emits approve (ratify), discard, compare and restore today.
- Maker-checker is a tenant setting. When it is disabled, the draft's author can ratify their own draft, so a separate approver is not guaranteed by the product alone.
- Whether maker-checker or shadow mode is enabled in any particular deployment is not publicly confirmed. Confirm it for yours.
- This entry describes the documented behaviour of the policy API. It is not a statement that any customer deployment is running it.
- A receipt is tied to the governing policy version. A rule-by-rule assessment view does not establish the outcome for each individual rule or the evidence for each rule in the receipt.

## Where it applies

- Establish which policy version a recorded decision was evaluated against, and compare it with the version in force now.
- Separate authorship from policy ratification where maker-checker is enabled, rather than assuming that every deployment requires a second person.
- Observe how a proposed policy would behave on real decision traffic before switching it to enforcement.

## Sources

- [MeshQu docs — Concepts overview](https://docs.meshqu.com/concepts/overview): The documentation owner's definition of a policy and of the four decision outcomes, including that the decision is advisory.
- [MeshQu docs — Policy lifecycle](https://docs.meshqu.com/concepts/policy-lifecycle): The governing-version exception for frozen forms, version states and the optional maker-checker requirement.
- [MeshQu docs — Integration patterns](https://docs.meshqu.com/guides/integration-patterns): Who enforces the verdict, and the advisory-rollout pattern that uses shadow mode.

## Related answers

- [What MeshQu does](https://www.meshqu.com/knowledge/what-meshqu-does): What does MeshQu actually do?
- [Decision Receipts: what the record contains](https://www.meshqu.com/knowledge/decision-receipts): What is in a Decision Receipt, and what does it prove?

## Next step

[How policy versions are governed](https://docs.meshqu.com/concepts/policy-lifecycle)

Read more on [docs.meshqu.com/concepts/policy-lifecycle](https://docs.meshqu.com/concepts/policy-lifecycle)

Updated 9 October 2026
Machine-readable: https://www.meshqu.com/knowledge/policy-application.json
All reviewed answers: https://www.meshqu.com/knowledge