Governance

Policy engine

Policies are rules the AI must honour regardless of its autonomy level. They are evaluated before reasoning begins and verified after reasoning produces a plan. The policy engine is not an add-on — it is load-bearing for how every situation gets handled.

Three rule types

ALLOW — the AI may take the specified action without human approval.
DENY — the AI must not take the specified action under any circumstances.
REQUIRE_APPROVAL — the action is permitted but requires human approval before execution, regardless of delegation status.

Rule scope

Each rule is scoped along three axes:

Department — which department the rule applies to (or all departments).
Action type — which action the rule governs (e.g. send_email, send_slack_message, create_document).
Conditions — optional predicates on the situation or entities involved (e.g. entity value over X, entity in priority-override list).

Evaluation order

Rules evaluate most-specific-wins. A DENY rule at department scope overrides an ALLOW at operator scope. A REQUIRE_APPROVAL on a specific action type overrides a broader ALLOW for that department. This lets you paint in broad strokes and sharpen with exceptions.

Policy evaluation runs twice. Pre-reasoning — to filter the action space the reasoner considers. Post-reasoning — to verify the produced plan complies. A plan that slips past pre-reasoning evaluation (e.g. reasoner proposes an unanticipated action type) still gets blocked post-reasoning.

Effective autonomy

For each situation, the policy engine computes the effective autonomy — the set of actions the AI is permitted to take without approval, given all applicable rules. If effective autonomy is empty for a proposed action, the situation surfaces for approval even under a delegated type.

Common policy patterns

DENY all external-email write-back from the finance department.
REQUIRE_APPROVAL for any action involving entities with value over €10,000.
ALLOW internal Slack messages on the ops department, ALLOW external email write-back only for customer-success.

Previous← Stripe NextAudit trail →

Rule scope

Each rule is scoped along three axes:

Department — which department the rule applies to (or all departments).

Action type — which action the rule governs (e.g. send_email, send_slack_message, create_document).

Conditions — optional predicates on the situation or entities involved (e.g. entity value over X, entity in priority-override list).

Evaluation order

Policy evaluation runs twice. Pre-reasoning — to filter the action space the reasoner considers. Post-reasoning — to verify the produced plan complies. A plan that slips past pre-reasoning evaluation (e.g. reasoner proposes an unanticipated action type) still gets blocked post-reasoning.