Policy Engine

Nine deny-by-default rules

Every Decision Receipt evaluation runs all nine rules in sequence. A receipt is ALLOWED only if every required rule passes. Failure routes to BLOCKED or ESCALATED depending on the rule. There is no default-permit posture — evidence must be affirmatively sufficient.

Deny-by-default means the absence of evidence is a policy failure, not a pass. An autonomous action that cannot produce sufficient evidence does not proceed.

Verdict types

What happens on failure

ALLOWED

All required rules passed

Every mandatory policy rule evaluated to pass. Evidence was sufficient, provenance verified, replay deterministic. The receipt is signed and the action is authorized to proceed.

BLOCKED

A required rule failed

One or more mandatory rules evaluated to fail and the rule failure mode is BLOCK. The action does not proceed. The receipt records exactly which rules failed and why.

ESCALATED

Human review required

A rule failed with escalation semantics — typically decision rights, required evidence, or human approval. The action is paused for human review rather than hard-blocked.

The nine rules

Policy rule reference

Each rule is evaluated in order. Rules 4 and 5 escalate on failure rather than hard-blocking. Rule 8 is off by default and escalates when enabled. All others block on failure.

Rule 01 BLOCKS on fail

minimum_source_count

A decision with only one evidence source cannot be independently corroborated. This rule requires at least two sources to establish the minimum evidentiary floor.

Pass condition

claim.sources.length >= 2

Fail example

sources: [ci_result]
// only 1 source → BLOCKED

Rule 02 BLOCKS on fail

source_type_diversity

Multiple sources of the same type (e.g. two CI runs) provide redundancy, not diversity. This rule requires at least two distinct evidence categories to establish that the decision was evaluated from multiple angles.

Pass condition

unique source types >= 2
// e.g. ci_result + code_review

Fail example

sources: [ci_result, ci_result]
// 2 sources, 1 type → BLOCKED

Rule 03 BLOCKS on fail

provenance_required

Evidence without provenance metadata cannot be authenticated. Every source must carry a captured_at timestamp and a snapshot_id that ties it to a verifiable state of the world at decision time.

Pass condition

every source has:
  captured_at: ISO timestamp
  snapshot_id: non-empty string

Fail example

{ type: "ci_result",
  captured_at: null }
// missing provenance → BLOCKED

Rule 04 ESCALATES on fail

required_evidence_admitted

When a decision schema designates specific evidence as required, that evidence must be present and carry a state of accepted. Missing required evidence does not hard-block — it escalates for human review, because the gap may be intentional and reviewable.

Pass condition

all required evidence:
  state === "accepted"

Fail example

required: [security_scan]
security_scan: state "pending"
// → ESCALATED

Rule 05 ESCALATES on fail

decision_rights_satisfied

Decision rights define who or what must have approved a specific class of action. This rule checks that all declared decision rights carry a satisfied state. Unsatisfied rights escalate rather than hard-block, enabling delegation workflows.

Pass condition

all decision_rights:
  state === "satisfied"

Fail example

right: "tech-lead-approval"
  state: "pending"
// → ESCALATED

Rule 06 BLOCKS on fail

minimum_confidence

Evidence confidence scores reflect the system's assessment of each source's reliability. This rule requires the average confidence across all sources to meet the 0.6 threshold. Low-confidence evidence aggregates push the decision below the admission floor.

Pass condition

avg(source.confidence)
  >= 0.6

Fail example

confidences: [0.5, 0.4]
avg: 0.45 → BLOCKED

Rule 07 BLOCKS on fail

deterministic_replay

The sealed evidence must produce the same verdict when replayed. The policy engine runs a replay pass against the sealed evidence hashes and compares the result to the original evaluation. A non-deterministic replay invalidates the receipt.

Pass condition

replay(sealed_evidence)
  === original_verdict

Fail example

original: ALLOWED
replay:   BLOCKED
// drift detected → BLOCKED

Rule 08 Off by default — ESCALATES when required

human_approval

When enabled, this rule requires a source of type human_approval to be present in the evidence set. Disabled by default for fully autonomous pipelines; enable for high-consequence actions where a human-in-the-loop checkpoint is required by policy or regulation.

Pass condition (when enabled)

sources includes:
  { type: "human_approval" }

Fail example (when enabled)

no human_approval source
// → ESCALATED (not BLOCKED)
// awaiting human review

Rule 09 BLOCKS on fail

risk_scope_bounded

A decision with unbounded risk scope signals under-specified governance. This rule caps the number of discrete risk scope items at five. Actions affecting more than five risk domains must be decomposed into separate receipts, each evaluated independently.

Pass condition

risk_scope.items.length <= 5

Fail example

risk_scope: [auth, data, infra,
  billing, logging, network]
// 6 items → BLOCKED

Quick reference

#	Rule	Threshold	On Fail
01	minimum_source_count	sources ≥ 2	BLOCKED
02	source_type_diversity	unique types ≥ 2	BLOCKED
03	provenance_required	captured_at + snapshot_id	BLOCKED
04	required_evidence_admitted	state === "accepted"	ESCALATED
05	decision_rights_satisfied	state === "satisfied"	ESCALATED
06	minimum_confidence	avg confidence ≥ 0.6	BLOCKED
07	deterministic_replay	replay === original	BLOCKED
08	human_approval	human_approval source present	ESCALATED (off by default)
09	risk_scope_bounded	items ≤ 5	BLOCKED

Get started

Try the policy engine live

Submit an evidence payload in the playground and see exactly which rules pass, fail, or escalate — with the full policy trace.

Open Playground Get API Key