A policy is an authored set of rules that turns facts into a decision: which size band a company falls into, whether an applicant is eligible, how risky a counterparty scores. The policy rule engine lets you write that rule-set down once, version it, and then evaluate it against a real subject deterministically - no model in the loop, the same inputs always reaching the same verdict. It exists so a regulated decision has a home: a rule you can read, a version you can pin, and a verdict you can defend long after it was made.
What it does
A policy is an authored, versioned, jurisdiction-scoped rule-set. Each policy carries a kind that decides how it evaluates: a CLASSIFICATION or ELIGIBILITY policy is an ordered set of rules, a RISK_SCORE policy is a weighted score. You give it a key, a title, and a jurisdiction (defaulting to global), and its body is a single disciplined shape: the inputs it needs, the rules that decide the outcome, and the typed output it produces. The body is validated the moment you save it, so a malformed rule-set is refused at authoring time rather than discovered at evaluation time.
Publishing mints an immutable version. A policy starts as a draft you can edit freely. When you publish it, the engine forward-mints an immutable version that snapshots the rule body, the kind, and the jurisdiction. Every evaluation pins the exact version it ran against. Editing a published policy means editing the draft and re-publishing, which mints a higher version - and a verdict recorded against the old version never drifts. The rule that decided a matter last year stays exactly as it was the day it ran.
Evaluation is deterministic, with no model in the loop. policy.evaluate takes a subject (a matter, a party, anything addressable) and runs the pinned rule-set against the facts. There is no language model and no guesswork: the same inputs produce the same verdict, every time. Inputs come either inline (the testable path) or from the matter’s own facts, resolved by field. The engine handles ordered ranges with a bump-up rule (exceeding any one bound promotes the subject to the stricter category), an override layer (a condition that forces fields onto the verdict, such as a regulatory carve-out overriding a size exemption), a group roll-up (sum a parent and its subsidiaries before classifying the group), and a country-weighted score with optional bands.
A missing required input blocks - it never defaults. If a rule needs a fact the subject does not have, the evaluation fails closed with a structured error naming the missing input. The engine never quietly substitutes a default, and a classification that matches no rule and has no declared fallback is refused rather than guessed. A regulated decision either resolves to a named branch on real inputs, or it stops and tells you why.
Every verdict is recorded as a citation. An evaluation writes three things: a result fact carrying the verdict, a citation row pinning the policy version, the matched rule or override branch, and a hash of the exact inputs, and a single audit event over the whole outcome. The verdict is materialised so you can read it back at a glance, yet it stays re-derivable from the pinned version and the input facts - so months later you can prove not just what the decision was, but which rule produced it and on what facts.
Sensitive verdicts hand off to a human gate. An evaluation can flag that its outcome needs human confirmation - either because the caller asked for it, or because the verdict itself carries a requirement (an audit-required result, say). The engine surfaces that need so the work routes into an approval gate rather than acting on its own.
The AI can run a policy, but it cannot write one. Authoring is closed to agents. An agent actor calling policy.create, policy.edit, policy.publish, or policy.set is denied fail-closed; a change to a regulated rule-set lands through a gate a person approves. Agents can evaluate published policies all day - they just cannot rewrite the rules they are judged against.
Workspace governance config is set separately. Distinct from authored rule-sets, policy.set carries two workspace-wide governance knobs: the active gate categories and the default sensitivity an object inherits when none is set. Gate categories are tighten-only: the substrate mandates a floor (regulated, money, external) that a tenant may add to but may never drop. An attempt to publish a category set that omits a floor category is refused. These are owner-only settings, because they govern every future gate decision and every new object’s classification floor.
How you use it
Author a rule-set. Create a policy with its key, title, kind, and jurisdiction, then write its body: declare the inputs it needs (marking which are required), the rules that map those inputs to a category and an output, and any overrides or roll-up. While it is a draft you can edit and re-edit freely.
Check it before you publish. Validate the body to confirm the rule-set is well-formed - every input has a key, a classification has a non-empty rules array, a score has its weight map - without persisting anything. The same validation runs again at publish time, so an invalid policy can never go live.
Publish a version. Publish the draft to mint an immutable version and make it evaluable. Re-edit and re-publish later to mint the next version; earlier verdicts stay pinned to the version that produced them.
Evaluate a subject. Point an evaluation at a matter or party. The engine pulls the required facts (or takes them inline), runs the pinned rules, and returns the verdict, the matched branch, the inputs hash, and whether a human gate is needed. If a required fact is missing, it tells you exactly which one.
Read it back later. Look up a policy to see its current body, version, and status; list policies filtered by kind or status. Because each verdict pins its policy version and input hash, you can always reconstruct why a past decision came out the way it did.
The kernel verbs behind it
Every one of these goes through the one front door - permission-checked and audited before it runs (see Security and permissions). These are the verbs most specific to the policy rule engine.
policy.create- author a new draft rule-set with its kind, jurisdiction, and body (agent-non-writable).policy.edit- re-author a draft body before it is published; the body is re-validated on every change.policy.validate- check that an authored rule-set is well-formed, without persisting it.policy.publish- forward-mint an immutable version and flip the policy live; earlier verdicts never drift.policy.evaluate- run the pinned rule-set against a subject deterministically, returning a versioned, citable verdict.policy.get- read one policy: its body, kind, status, jurisdiction, and current version.policy.list- list policies in the workspace, filtered by kind or status.policy.set- set the workspace governance config (gate categories and sensitivity defaults); owner-only and tighten-only on the substrate floor.
See the full set in the policy verb reference.