Skip to content

Governance & Policy Settings

What this screen is for

Governance & Policy is the last of the eight purpose groups of Platform Settings, and the smallest of them. It holds nine configuration values in two subgroups. Policy Engine holds four, and between them they decide what the platform does when it cannot reach its own policy store. Scheduling holds five: the background jobs that expire cryptographic exchanges and repair authorization projections.

A third card sits beside those two and holds no configuration value at all. Counterparty Types administers records rather than values, and it has a page of its own.

Both value subgroups open as one plain list each, with no sections and no tabs, narrowed by the text filter at the top of the leaf.

What must exist first

Governance & Policy is reached inside Platform Settings, which is a platform screen and is served only to the platform tenant. Beyond that:

  • The permission to read platform configuration. It is what lists these nine values at all. The platform super administrator, auditor and viewer roles hold it.
  • The permission to write platform configuration, for any change. Without it every value is readable and none carries an edit control.
  • A third permission for the one value classified dangerous — the policy fail mode. It is required in addition to the write permission, and the platform refuses the write without it whatever the screen allowed you to type.
  • A separate permission to list counterparty types, for the third card. Without it that card is never added, so the group shows two cards rather than three. The two value subgroups are unaffected either way.

Decisions you make here

Reading the group

The two value cards carry a plain count badge — 5 under Scheduling and 4 under Policy Engine while the Posture filter is All. The count narrows with the filter, so a badge reading 0 is a filtered count and not an empty subgroup. The Counterparty Types card carries no badge at all: it is neither a connector, which would give it a status chip, nor a list of values, which would give it a count.

Five of the nine values are writable and four are not. None of them is a secret, and none of the writable five binds at start-up — so nothing you change in this group leaves a Restart required banner behind.

Policy Engine

Four values, and between them they are the platform's posture during a control-plane outage.

  • Policy fail mode — CLOSED, and CLOSED is the only value the control accepts. A cached policy that has outlived its maximum age while the policy store is unreachable is honoured inside the grace period below, and denied once that has also elapsed. This is the group's one dangerous value and it cannot be widened: a value reaching the table by any other route is coerced back when it is read, with a security warning. Live, no restart.
  • Grace period — PT2H by default, bounded between one second and 24 hours. It is the extra window past the local cache's maximum age in which an expired policy is still honoured, and it is in play only while the policy store is unreachable. It applies forward only.
  • Check the deployment policy in health — on by default. It affects the health signal and never enforcement: off, health can report healthy while the deployment policy is missing entirely, and the outage then surfaces as denied operations instead of a failing probe. Live.
  • Critical tenants — empty by default, otherwise a comma-separated list of tenant UUIDs whose policy availability is polled. Empty means no tenant policy is monitored at all, so a tenant losing its cached policy is invisible until its operations start failing. Live.

Scheduling

Five values, of which exactly one is yours to change on this screen.

  • Exchange scheduler cron — 0 5 * * * *, and the only entry in this group that reschedules its job the moment you save. The tick moves cryptographic exchanges whose window has ended to EXPIRED and records the transition. It does not decide when an exchange stops working: the window is enforced on every request, so a coarse schedule only delays when an ended exchange is shown as EXPIRED. An expression the scheduler cannot parse means the job is never registered and that transition stops altogether.
  • Capability-grant reconciliation — three entries, all owned by the deployment: whether the sweep runs at all, the delay between passes (15 minutes) and the delay before the first pass after start-up (one minute). Each is shown with a lock and the name of the environment variable that sets it, and you change it by editing the deployment environment and redeploying.
  • Policy cleanup cron — shown read-only, and labelled a diagnostic rather than a deployment parameter. It records an expression that is not wired to a live scheduler in this release, so there is nothing here to reschedule and no variable to go and set.

Why the reconciliation sweep is worth leaving on

It is the repair path for capability-grant projections that drifted from the database. A grant revoked while its projection failed to update keeps authorizing operations until something notices, and this sweep is what notices. Switching it off removes that safety net entirely, and because the decision is taken at start-up, switching it back on takes a restart.

How it relates to other screens

This group sits inside Platform Settings, where the permissions, the posture filter, the edit rules and the propagation wording used above are set out in full:

What a policy actually says is decided elsewhere. This group decides what happens to a policy the platform cannot read, never its content:

Where to read more