Policy Engine

The Policy Engine is the surface in the Mesh Dashboard where administrators author and manage policies. Authoring happens here; evaluation happens at the Policy Decision Plane as described in Core Concepts → Policies and ABAC.

What you can do

Author a policy as a structured expression over principal, data, and context attributes. The editor provides auto-complete against the tenant's tag schema and known principal attributes, so policies reference values that actually exist.

Test a policy against sample principals and sample data objects before publishing. The test runner shows the decision (allow, deny, or error), the obligations attached, and the specific clause that produced the outcome.

Publish a tested policy into production. Published policies are versioned — every publish creates a new immutable version, and the ledger records the act of publishing.

Review incoming policy changes. Tenants can configure required-reviewer workflows so that a policy change must be approved by a second authorized principal before it goes live.

Retire a policy. A retired policy no longer produces allow decisions. Historical evaluations under the retired policy remain reconstructable from the ledger.

Policy categories

Policies in a tenant fall into three broad categories:

• Allow policies grant access under specified conditions. The default is deny — a request that no allow policy matches is denied.
• Deny policies override allow decisions. They are the mechanism for carve-outs: a specific principal excluded, a specific classification that may not leave a region, a litigation hold that freezes a set of objects.
• Obligation policies attach requirements to an allow. Access is permitted, but the enforcing layer must apply an obligation — watermarking, view-only display, mandatory logging of the session, a time limit.

A request's final disposition is: deny wins, then obligations attach to a surviving allow.

Staging and review workflows

For sensitive policies, a tenant can require a staged review before production publication:

1. An author drafts a policy and runs tests.
2. The draft moves to a review queue.
3. A reviewer in an authorized role inspects the policy, its tests, and the proposed effect on sample evaluations.
4. On approval, the policy publishes. On rejection, it returns to the author with comments.

Both the proposed change and the approval are recorded on the ledger. The sequence is reconstructable forever.

Versioning

Every published policy carries a version. When a decision is recorded on the ledger, it references the version of the policy that was in force at the time. Historical audit requires being able to replay a decision against the exact policy set that applied — versioning is what makes that replay correct.

Retired policy versions are retained according to the tenant's configured retention baseline. For regulated industries where audit reconstruction is required for years, the retention is long; for short-lived commercial workloads, it can be shorter.

Testing philosophy

The policy test runner is intended to be used routinely — before every publish, not only when something looks wrong. A policy that has not been tested against a realistic set of principals and data classifications is a policy whose behavior is uncertain.

The tenant's sample set should include:

• Typical principals — a standard employee, a senior manager, an external contractor.
• Edge-case principals — a user with lapsed clearance, a service account, a cross-tenant coalition partner.
• Typical data — objects at each classification tier and each business domain.
• Edge-case data — freshly classified objects, objects with deprecated tags, legal-hold objects.

Maintaining this set is part of the ongoing hygiene of running a Policy Engine.

Relationship to concepts

• The Policy Engine is the authoring surface for Policies and ABAC.
• Published policies are versioned; historical versions are needed to interpret the Immutable Ledger.
• Staging and review workflows are configured under Configuration → Policy Workflow.