Policy Engine

Take the decision out of the code

Which request goes to which model, what gets masked, what gets refused — all of it is settled by rule sets evaluated in one engine. That engine compiles OPA/Rego to WASM and runs it inside the gateway process.

YAML rule sets, or Rego directly
Observe in shadow mode, then enforce
Constraints intersect, obligations union

Request a demo Compare plans

222µsp99 decision time

One decision point (PDP)

Your application code does not need to know whether a request is regulated, which tier a user is on, or whether a prompt contains PII. Those questions are answered in the gateway, at a single decision point that looks at the request's context. The result is expressed along five axes: deny, constrain, route, redact, govern the cache.

What it does

Five axes, one pool

route, constrain, deny, redact and cache are outputs of the same evaluation. As layers merge, constraints intersect — no layer can widen another's boundary.

Three governance layers

Platform baseline, organization governance and the organization's own custom rules all write into one pool. A boundary drawn by the platform baseline cannot be loosened by a customer rule.

Shadow mode

The rule evaluates, the decision is recorded, nothing is enforced. The divergence report shows the agreement rate and the requests that diverged.

Obligations

Alongside the decision travel masking, audit tags, notifications, cache mode and response headers. Obligations union; none cancels another.

Restricted capability profile

Policy compiles against a narrowed OPA capability profile. A call like http.send simply does not exist under that profile, so it fails at compile time.

Evaluation-cost admission

At publish time the bundle's cost is measured on the same WASM runtime the gateway uses. A bundle over the fuel budget is not distributed; above 70% it publishes with a warning.

Interactive · Policy engine

Make the decision yourself

The switches below are the real inputs of a real rule set. Change them and you see which rule wins, where the request goes and which obligations that creates.

Request context

A national ID was detected in the promptSignal produced by the guardrail scanner

Subscription tier

Prompt tokens1,200

Data class

Streaming requestSending stream: true

Decision

Decision time 201µs

Allow

Winning rule: default-allow-with-cache
Selected model: gpt-4o-mini
Region: tr-west-1
Semantic cache: Read and write
Matched and lost: None
Obligations: A decision digest is added to the response headers

No restrictive rule matched. The request goes to the default model pool and the semantic cache stays on.

The rule set being evaluatedThe winning rule is highlighted

apiVersion: modelion.ai/v1kind: PolicyRuleSetmetadata:  name: production-governance  class: compliancespec:  - name: regulatory-data-deny    when:      - field: request.headers.dataClass        operator: equals        value: regulatory    then:      effect: deny      statusCode: 403  - name: kvkk-pii-route-resident    when:      - field: signals.pii.detected        operator: is        value: true    then:      effect: route      route:        candidates: [gpt-4o-mini]        region: tr-west-1        fallbackToOriginal: false      obligations:        redactTypes: detected        auditTags: [kvkk_pii_detected]        cache: { mode: off }  - name: free-tier-constrain    when:      - field: principal.subscription.tier        operator: equals        value: free    then:      effect: constrain      constraints:        allowedModels: [llama-3.3-70b, gpt-4o-mini]        maxOutputTokens: 500      obligations:        cache: { mode: lookup_only }  - name: long-context-upgrade    when:      - field: request.prompt.tokens        operator: greaterThan        value: 4000    then:      effect: route      route:        candidates: [claude-sonnet-4, gpt-4o]  - name: default-allow-with-cache    then:      effect: allow      obligations:        cache:          mode: read_write          scope: org          threshold: 0.85          ttlSeconds: 3600

This demo runs in your browser and makes no gateway call. The engine itself evaluates the same rule contract on WASM in production.

The demo on this page runs in your browser; no real gateway call is made.

How it works

Four steps from writing a rule to enforcing it in production. Skipping the third is possible but not advised.

1
Write the rule set
Author it as YAML in the console. For advanced needs you can upload a Rego module directly.
PolicyRuleSet · YAML
2
Run it in the test panel
The sample requests you save are used both for correctness and for measuring evaluation cost. Five requests are kept per combo.
5 samples per combo
3
Observe in shadow mode
Decisions are produced and recorded but not enforced. The divergence dashboard lets you read the diverging requests one by one.
shadowEnabled: true
4
Enforce
Add the organization to the enforcement list. Rollout reaches gateway pods as a signed bundle; rollback is one call.
enforce · rollback

Technical summary

Authoring: YAML rule sets (primary) · Rego modules (advanced)
Runtime: Rego → WASM, in-process in the gateway (wasmtime)
Latency: p50 154µs · p99 222µs
Memory: ~512 KB per pooled WASM instance
Decision axes: route · constrain · deny · redact · cache · obligations
Layers: platform.baseline · org.governance · org.custom
Distribution: Signed bundle · rollout p99 < 30 s
Prompt excerpt window: 8192 characters max (the ceiling the measurement is taken at)

Why there are no ready-made compliance templates

Templates were removed deliberately. Each carried an assumption that was right for one tenant and quietly wrong for the next: the KVKK template had Turkish PII baked in, the after-hours rule had UTC baked in, the budget template had 80/100 thresholds baked in. In a multi-jurisdiction product a shipped template is a liability, not a convenience. What replaced them is copy-paste examples in the docs, plus consulting on policy authoring.