Build

Policy & Decision Engines

Use this path when the real governed surface is Cedar, Drools, IBM ODM, or OPA rather than a generic application runtime.

These are first-class setup docs for deterministic policy and decision engines, not a footnote under generic runtime instrumentation.

Playbook Goal

If your consequential logic lives in a rules or policy engine, this is the setup path. Instrument the engine directly, bind it to the governance chain, and verify the emitted artifact locally.

Use This Page When...

Cedar authorization is the real decision surface
Drools is firing the consequential rules
IBM ODM is the live business-rules execution layer
OPA policy evaluation is the thing you actually need to prove

Quick Package Map

Package	Ecosystem	Use it for
`primust-cedar`	JVM / Maven	Cedar authorization evaluation
`primust-drools`	JVM / Maven	Drools KIE rule evaluation
`primust-odm`	JVM / Maven	IBM ODM ruleset execution
`primust-opa`	Go	OPA Rego policy evaluation

The Setup Flow

Complete governance setup in the app: programs, applicability, obligations, controls, approval.
Pin the policy or rule version you are actually evaluating.
Wrap the real engine evaluation call with the matching adapter.
Record the evaluation after the engine returns its real result.
Emit the VPEC and verify it locally with primust-verify.

The core rule is simple: do not instrument around the engine if the engine itself is where the consequential decision happens.

What You Usually Get Back

proof_level_floor: mathematical stage_type: deterministic_rule surface_type: policy_engine approval_id control_plan_hash obligation_plan_hash

These adapters are strong because the policy engines are deterministic. Same input plus same pinned policy or rule base should produce the same result.

Cedar

Use primust-cedar when Cedar authorization is the live decision surface.

<dependency>
  <groupId>com.primust</groupId>
  <artifactId>primust-cedar</artifactId>
  <version>0.1.0</version>
</dependency>

Setup pattern: keep your existing isAuthorized() call, then record the evaluation with the adapter and the pinned policy-set hash.

Pin: SHA-256(policy_set)
Record after: Cedar decision returns
Why it is strong: deterministic authz evaluation with local commitments

Drools

Use primust-drools when Drools KIE is firing the real consequential rules.

<dependency>
  <groupId>com.primust</groupId>
  <artifactId>primust-drools</artifactId>
  <version>0.1.0</version>
</dependency>

Setup pattern: keep your existing KieSession.fireAllRules() flow, then record the evaluation or per-rule details after execution.

Pin: the active rule base
Record after: fireAllRules()
Why it is strong: same facts plus same rules equals same outcome

IBM ODM

Use primust-odm when IBM ODM is the business-rules execution layer you actually rely on.

<dependency>
  <groupId>com.primust</groupId>
  <artifactId>primust-odm</artifactId>
  <version>0.1.0</version>
</dependency>

Setup pattern: keep your existing IlrStatelessSession.execute() flow, then record the ruleset parameters, rules fired, and decision output.

Pin: rule app and rule set
Record after: ODM execution returns
Special note: ODM runtime JARs come from IBM Passport Advantage, not Maven Central

OPA

Use primust-opa when OPA Rego policy evaluation is the real policy boundary.

go get github.com/primust-dev/primust-opa

Setup pattern: keep your existing rego.PreparedEvalQuery, then run it through the adapter’s Eval() with a pinned policy hash.

Pin: SHA-256(rego)
Record during: adapter-managed Eval()
Why it is strong: deterministic policy evaluation with local input and output commitments

Verify The Result

pip install primust-verify
primust verify vpec.json --trust-root primust-pubkey.pem

The local verifier is still the preferred review path for production or audit use.

Policy Engines vs Connectors

If the consequential logic lives in...	Use...
Cedar, Drools, IBM ODM, or OPA that you directly control	This page and the matching engine adapter
A vendor platform boundary you can call but not instrument internally	Connectors

Need the broader package map? Go back to SDKs & Adapters. Need exact fields and routes? Use the Technical Reference. Need the full app-side setup flow first? Read the User Guide.