Skip to main content
Every policy in MeshQu has a version history. At most one version governs ordinary evaluations at a time. Drafting, review, ratification, and activation are separate steps, with optional maker-checker enforcement.

​
Version states

Each stored version has a lifecycle status. The main statuses are: Clients select the state they want to look at through a URL parameter on the policy detail endpoint:
The response always resolves selectedVersion to the numeric version and reports the corresponding versionState.
Viewing a draft or a historical version never changes what MeshQu decides — reading a version has no effect on evaluation.Which version governs is a separate question, and the answer is not always “the active one”. Ordinary evaluation resolves the active version. A frozen form evaluates against the eligible, ratified policy_version pinned to that form, which can be a formerly active version.A draft cannot be used as a frozen-form pin. An ineligible pin returns FROZEN_PIN_NOT_ELIGIBLE.

​
Maker-checker

MeshQu tenants can enable maker-checker enforcement to require that a different person approves a draft than the one who created it.
  • The maker authored the draft.
  • The checker approves or rejects it.
  • The same user cannot be both on the same draft when maker-checker is enabled.
The check is enforced server-side on the ratify endpoint. When maker-checker is on, a ratify request from the draft’s author returns 403 MAKER_CHECKER_VIOLATION regardless of what the UI shows. When maker-checker is disabled, the author can ratify their own draft.

​
Lifecycle transitions

  • Start editing — creates a draft from the current version. Only one pending version is allowed per policy.
  • Submit — moves a draft to submitted for review. The author may recall it; an eligible checker may reject it with a reason, returning it to draft.
  • Ratify — records approval of a draft or submitted version and moves it to ratified. Ratification does not put the version in force.
  • Activate version — puts a ratified version in force. The previously active version becomes superseded.
  • Discard, reopen, set aside, or replace — close a pending version under different conditions while retaining its history. See the API Reference for each operation’s requirements.

​
How permissions are returned

Rather than ask the client to re-derive what a user can do, the policy detail response carries two fields that answer this directly. permissions — a boolean record:
Flags reflect the authenticated actor’s effective rights against the selected version under the current tenant settings. Use them to gate fine-grained UI (for example, showing a confirm dialog on canDiscard). actions — an ordered array of lifecycle actions the UI should surface:
Clients can use this array to render the available controls. The API omits unavailable actions, and each write endpoint enforces its own requirements.

​
Action kinds

Action availability depends on the version’s state, the caller’s permissions, whether the caller authored the version, and maker-checker settings. The actions and permissions fields on the response show the current result.

​
Errors

  • 404 NOT_FOUND — the policy, the requested ?version= number, or the requested ?version=draft does not exist. The response message distinguishes the case ("Policy not found", "Draft version not found", etc.) but the code is always NOT_FOUND for client convenience.
  • 403 MAKER_CHECKER_VIOLATION — returned by the ratify endpoint when maker-checker is enabled and the actor is the draft author.

​
Why the server owns this

Policy governance is a compliance surface. Emitting permissions and actions[] from the server means:
  1. The UI cannot accidentally show a button whose action the server would refuse.
  2. Clients do not need to re-implement role resolution, tenant-settings lookup, or the action matrix.
  3. Clients can respond to the actions returned for the selected version.
See the API Reference for the full policy detail response shape.