PowerDecision Concepts Guide

Overview

PowerDecision is a DMN-based decision automation engine that transforms business rules into executable decision models. It allows business analysts to define rules in a visual wizard or JSON format, which are automatically converted to industry-standard DMN (Decision Model and Notation) and evaluated by the KIE/Kogito engine.

Core capabilities:

• JSON-to-DMN conversion — Automatic generation of DMN XML from wizard JSON
• DMN evaluation — Standards-compliant execution via KIE/Kogito
• Decision templates — 7 pre-built templates across banking, insurance, retail, and IT
• Model management — Upload, register, list, and version decision models
• Async job execution — Submit decisions as jobs, poll for results
• PDP integration — Serves the Decide phase in PowerOrchestrator pipelines

DMN Decision Engine

What Is DMN?

DMN (Decision Model and Notation) is an OMG standard for modeling and executing business decisions. It provides:

• Decision Tables — Matrix of conditions (inputs) and outcomes (outputs)
• FEEL (Friendly Enough Expression Language) — A standardized expression language for conditions and calculations
• Hit Policies — Rules for handling multiple matching rows
• Portability — DMN models can be shared between compliant engines

Kogito & KIE Runtime

PowerDecision uses two evaluation paths:

The DecisionService tries Kogito first, then falls back to the runtime evaluator for uploaded models.

Wizard-to-DMN Pipeline

  ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
  │  Wizard   │     │   JSON   │     │   DMN    │     │   KIE    │
  │  (UI)     │ ──▶ │  Schema  │ ──▶ │  XML     │ ──▶ │  Engine  │
  │           │     │          │     │          │     │          │
  └──────────┘     └──────────┘     └──────────┘     └──────────┘
                    model_id          DmnGenerator     RuntimeDmn
                    inputs_schema                      Evaluator
                    outputs_schema
                    policy + rules

JSON Schema

The wizard JSON defines a complete decision model:

• model_id — Unique identifier (becomes the DMN model name)
• version — Semantic version
• inputs_schema — Input fields with types, constraints, and validation rules
• outputs_schema — Output fields with types
• policy — Hit policy and conflict resolution settings
• rules — Array of when/then rules with conditions and outcomes
• metadata — Owner, description, tags, sector, timestamps

DMN Generation

The DmnGenerator transforms wizard JSON into DMN XML:

1. Creates inputData elements from inputs_schema with FEEL type mapping
2. Creates a decision element with informationRequirement links to inputs
3. Builds a decisionTable with the specified hit policy
4. Converts each rule’s when conditions to FEEL unary tests (e.g., >= 750)
5. Converts then outputs to FEEL values or context expressions
6. Handles multi-output tables using FEEL context syntax: {a: 1, b: "x"}

Runtime Evaluation

The RuntimeDmnEvaluator loads DMN files dynamically:

1. Reads the DMN XML from the model storage directory
2. Creates a KIE container with the model
3. Obtains a DMNRuntime and loads the DMNModel
4. Creates a DMNContext from the input values
5. Calls evaluateAll() to execute the decision table
6. Returns the DMNResult with all decision outputs

Hit Policies

Hit policies determine what happens when multiple rules match the same inputs:

FEEL Expressions

Simple Conditions

The wizard JSON operators map directly to DMN FEEL unary tests:

{"credit_score": {"gte": 750}}  →  >= 750
{"status": {"eq": "EMPLOYED"}}  →  "EMPLOYED"
{"age": {"between": [18, 65]}}  →  [18..65]
{"tier": {"in": ["A", "B"]}}   →  in ("A", "B")
{"default": true}              →  -  (match all)

Compound Conditions

Conditions can be combined with and/or:

{"score": {"and": [{"gte": 600}, {"lt": 750}]}}  →  >= 600 and < 750
{"tier": {"or": [{"eq": "A"}, {"eq": "B"}]}}     →  ("A") or ("B")

Model Lifecycle

Built-in vs Runtime Models

Model Storage

Runtime models are persisted in two places:

• Filesystem — DMN XML files in the models/ directory (Docker volume /app/models)
• Redis — Model registry metadata (model_id, version, name, status, file path, uploaded timestamp)

On startup, the ModelRepository loads from Redis and also scans the filesystem for orphaned .dmn files (e.g., if Redis was flushed but the volume persisted).

Decision Templates

PowerDecision ships with 7 pre-built templates in decision-templates/. Each template is a complete wizard JSON file that can be uploaded directly via the model upload API:

• Loan Approval — Credit score, income, employment, debt-to-income analysis
• Credit Limit Determination — Dynamic credit limits from risk factors
• Customer Risk Classification — Risk tier assignment for underwriting
• Fraud Detection — Transaction scoring and suspicious activity flagging
• Insurance Premium Calculation — Premium pricing from risk profiles
• Product Recommendation — Product suggestions from customer attributes
• Support Ticket Routing — Priority assignment and department routing

Job Execution

Decisions are executed through an asynchronous job model:

1. POST /decisions creates a job with status PENDING and returns a jobId
2. The DecisionService resolves the model (Kogito or runtime)
3. Status moves to PROCESSING during evaluation
4. On success: result is stored with status SUCCESS
5. On failure: error details stored with status ERROR
6. GET /decisions/{jobId} returns the current status and result

The response includes decision (result data), explanation (matched rules, confidence), and metadata (timing information).

PDP Integration

PowerDecision serves the Decide phase in the PDP (Predict-Decide-Plan) pipeline:

  PowerForecast   →   PowerDecision   →   PowerSolver
  (Predict)           (Decide)             (Plan)
                      │
                      ├── Receives forecast context
                      ├── Evaluates business rules
                      └── Returns decision + explanation

When called by PowerOrchestrator, the decision context typically includes forecast outputs from a previous pipeline stage. The decision result flows to PowerSolver for constraint-based planning.