DecisionManager

The platform

Three things a rules engine has to get right

Reproducibility, where it can run, and whether one bad decision can take the service down. These are the three answers legacy suites cannot give — and where DecisionManager is structurally different, not merely cheaper.

A deterministic step budget, not a timer

Every decision is charged in steps and stops at a fixed budget. The verdict — including a refusal — depends only on the input and the version, never on how busy the machine was. A decision cannot pass in test and fail under load, and a replay years later returns the same answer.

IBM ODM

ODM offers ruleset.decisionEngine.maxRunningTime, a wall-clock timer, because an ODM rule action is arbitrary Java through the XOM and its cost cannot be known in advance.

The engine compiles to WebAssembly

A verified 1.5 MB wasm32 build with a six-crate dependency set. Run it in Lambda, Cloudflare Workers, Cloud Run — or ship a 947-byte hash-verified bundle that carries its own content hash and serves decisions with no database, no pool and no outbound network, ready in about 20 ms.

IBM ODM

ODM's Decision Server is a Java EE application needing WebSphere Liberty or Tomcat, a repository database and the XU connector. It cannot occupy any of those runtimes.

One heavy decision cannot take the pod down

Decisions execute on an isolated pool, never on the async workers that answer health checks, so a heavy ruleset can no longer make the liveness probe unreachable and get the pod killed for being busy. Panics are contained to the failing request; saturation sheds load with a retryable SERVICE_BUSY instead of queueing without limit.

IBM ODM

Budget exhaustion returns its own code, ENGINE_BUDGET_EXCEEDED (422) — the rules are not wrong, the artifact asked for more work than one call may do. Different owner, different fix.

Compiled rule engine

Visual business rule & decision table authoring

Author complex decision tables with instant hit-policy evaluation, BAL type validation, and compilation to native multi-key indexes on a Rust engine — the same path banks and insurers use for policy changes without a release train.

Decision engine authoring interface with decision tables

Author

Where business and engineering write the logic.

No-code

Visual ruleflow designer

Compose multi-stage flows with gateways and branches on a canvas your business team actually reads. No code, no redeployment.

Hit policies

Decision tables at million-rule scale

ODM hit policies, compound conditions and compiled multi-key indexes, so a lookup does not go linear as the table grows.

Fallback + cache

Multi-provider AI authoring

Generate rules, tests and whole rule applications from a prompt across Anthropic, OpenAI, Gemini, Bedrock-compatible and self-hosted endpoints — with ordered provider fallback so one vendor's outage does not stop a migration run, and a content-hash cache so a re-run is genuinely a re-run. Always reviewed, never auto-persisted.

Govern

What a regulator and an auditor will ask you for.

SoD enforced

Governance lifecycle & separation of duties

Draft → review → approved → published, with separation of duties enforced and a full audit trail on every change.

Overlaps · gaps

Decision-table analysis

Validation reports overlaps, unreachable rules and gaps in a table before it is published — the checks an ODM author expects, on the same artifact.

Async writer

Decision warehouse & KPIs

Every execution is persisted asynchronously — no latency added to the hot path — with per-environment volume, latency and error-rate KPIs, and champion/challenger experiments to compare versions on real traffic.

Run

The hot path, and everywhere you want to put it.

engine.steps

Every response reports what it cost

engine.steps comes back on every execute, so an expensive artifact is visible in the response rather than inferred from a latency graph. GET /api/health/engine reports live inflight, capacity and saturation.

Fails closed

Edge & embedded deployment

dm-bundle refuses to emit a bundle that does not compile, and the edge binary verifies the content hash and exits before binding the listener if anything is wrong — an orchestrator sees a failed deploy, not a pod serving errors.

Git-friendly

IDE workflow & cloud-agnostic control plane

Pull rule projects to disk as plain JSON, edit in VSCode with any assistant, push back with the dm CLI. The control plane is one PostgreSQL database and stateless containers, with no provider-specific code.

See it decide on your policy, not ours

Start a free trial with no card, or book a 30-minute walkthrough on your underwriting, claims, or eligibility rules.

Three consoles

One platform, three focused modules

Each console is purpose-built for its audience — and they all speak to the same governed rule repository.

Decision Manager

Authoring & governance

Where business and engineering design, test, and govern decision logic.

Built for
Business analysts and rule authors
  • Decision-table grid, action-rules editor, ruleflow canvas
  • Version lifecycle, Git review, rule-aware pipelines
  • AI-assisted authoring and dry-run testing (human review required)
Read more

Decision Server

Runtime & observability

The hot path: deploy, execute, and measure decisions in production.

Built for
Platform and SRE teams
  • Deployment matrix across environments
  • API workbench, probe console, idempotent batch
  • Decision warehouse browser & writer health
Read more

Admin

Platform & compliance

Operate the platform: people, keys, and a paper trail for everything.

Built for
Security, compliance and IT administrators
  • Members, groups, and 4-tier RBAC
  • Hashed workspace-scoped API keys & webhooks
  • Audit log and cross-service status
Read more

Architecture

Governance & deployment lifecycle pipeline

Strict separation of duties, draft-to-published state machine, and automated audit logging — one repository, three consoles.

Governance and deployment lifecycle pipeline across Decision Manager, Decision Server, and Admin

All three consoles are included in every plan. There is no separate authoring, runtime or console license — the thing legacy suites charge for three times.

All three consoles on every plan — start a trial or book a walkthrough.

How it fits together

Architecture at a glance

Authoring, runtime and administration share one repository. Decision logic is compiled for a Rust execution path — published figure ~3.4 ms end-to-end for a 2 MB request against 500 candidates (including parse), not a freestanding sub-2 ms average — and for teams leaving IBM ODM, the same model maps to a browser-side migration assessment.

DecisionManager topology: authoring, governed repository, Rust runtime and admin plane

See sample decisions — then open a workspace

Walk through sample scenarios in the browser demo, or start a trial with all three consoles included in every plan.