What a policy is, and how it is applied
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 (opens in a new tab)
The documentation owner's definition of a policy and of the four decision outcomes, including that the decision is advisory.
MeshQu docs — Policy lifecycle (opens in a new tab)
The governing-version exception for frozen forms, version states and the optional maker-checker requirement.
MeshQu docs — Integration patterns (opens in a new tab)
Who enforces the verdict, and the advisory-rollout pattern that uses shadow mode.
Related answers
What MeshQu does
What does MeshQu actually do?
Decision Receipts: what the record contains
What is in a Decision Receipt, and what does it prove?