Evaluation and History

DMN evaluations are synchronous: you POST an input context, the engine runs the decision graph, and you get back the per-decision results in the response. Every evaluation is recorded so you can inspect what happened later.

The evaluate API

There are two equivalent endpoints. The body is the same, only the way you address the definition differs.

Evaluate by platform UUID

POST /projects/{projectID}/dmn/definitions/{definitionID}/evaluate

definitionID here is the platform UUID of a specific stored version. Use this when you've pinned to a version on purpose.

Evaluate by DMN definitions id

POST /projects/{projectID}/dmn/definitions/by-definitions-id/{definitionsID}/evaluate

definitionsID is the value of the <definitions id="…"> attribute in your DMN XML. Resolves to the latest version of that definition by default, pass an explicit version in the body to pin.

This is the right endpoint for callers that know decisions by their model-level identifier — for example, a frontend that hard-codes the definitions id and always wants the latest deployed logic.

Request body

{
  "context": { "customerAge": 42, "annualIncome": 85000 },
  "decisions": ["Eligibility"],
  "version": 3
}

Field	Required	Notes
context	yes	The input scope. A FEEL context — keys are variable names, values are FEEL-typed (number, string, boolean, list, nested context)
decisions	no	Names of decisions to evaluate. If empty, all decisions in the definition are evaluated
decisionServices	no	Names of decision services to evaluate. If empty, no decision services are evaluated
version	no	Pin to a specific version. Defaults to the latest

The interaction between decisions and decisionServices is intentional: leaving both empty runs every decision but no services. If you want to invoke a decision service, name it explicitly.

Response shape

The response is a map keyed by decision name. Each value is an EvaluationResult:

{
  "Eligibility": {
    "decisionID": "decision_eligibility",
    "name": "Eligibility",
    "type": "DECISION",
    "value": { "eligible": true, "tier": "gold" },
    "hitRules": [
      { "ruleID": "rule_3", "outputs": { "eligible": true, "tier": "gold" } }
    ],
    "dependencies": [
      {
        "decisionID": "decision_score",
        "name": "Score",
        "type": "DECISION",
        "value": 720
      }
    ],
    "error": null
  }
}

Field	Notes
decisionID	The decision's XML id
name	Human-readable name
type	DECISION, DECISION_SERVICE, BKM, or INPUT_DATA
value	The FEEL value the decision produced. Shape depends on the decision's output type
hitRules	For decision tables: which rules matched, and what each rule output. Empty for other expression types
dependencies	The upstream decisions that this evaluation pulled in — the dependency tree of the result. Useful for tracing why a decision came out the way it did
error	Error message if this decision failed to evaluate. null on success

When a single decision in the graph errors, the engine still returns a response — the failed decision carries error, and decisions that depended on it propagate the failure. The HTTP status itself is 200 unless the request body was malformed.

Example

curl -X POST "$API/projects/$PROJECT/dmn/definitions/by-definitions-id/$DEFINITIONS_ID/evaluate" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "context": {
      "applicant": { "age": 42, "income": 85000 },
      "loanAmount": 25000
    },
    "decisions": ["Eligibility", "Pricing"]
  }'

For authentication, see Authentication.

Calling decisions from a BPMN process

A BPMN business-rule task invokes a stored decision directly — no HTTP round-trip. The quantum:calledDecision decisionId="…" extension expects a decision XML id from the DMN Decisions list.

The runtime is the same engine, the only difference is that the BPMN side reads the input context from the process variables (after I/O input mapping) and writes the result into a process variable named by resultVariable.

Execution history

Every evaluation — whether it came in via the API or from a BPMN business-rule task — is recorded.

What's stored per execution

Field	Description
Execution ID	Unique identifier of this evaluation
Definition ID	Platform UUID of the version that ran
Definitions ID	The <definitions id>, useful for grouping across versions
Inputs	The full input context
Outputs	The result FEEL value
Executed by	User or service account that issued the call
Executed at	Timestamp

Retention depends on subscription tier. See Subscriptions for the limits that apply to your plan.

The Executions view

Open DMN Executions from the navigation. The view is a chronological list across all definitions in the project, with columns:

Column	Description
Executed by	User or service account
Definitions ID	The <definitions id> of the model that ran
Executed at	Timestamp

A filter input at the top narrows the list to a single definitionsID. The list paginates, default 20 per page.

API access

Endpoint	Use
GET /projects/{projectID}/dmn/executions	Project-wide execution list. Filter by definitionsID, paginate
GET /projects/{projectID}/dmn/definitions/{definitionID}/executions	Executions for one specific definition version (by platform UUID)
GET /projects/{projectID}/dmn/executions/{executionID}	Single execution detail — the inputs, outputs, and per-decision results

The single-execution detail endpoint returns the full EvaluationResult tree as it was at evaluation time, so you can reproduce why a decision came out the way it did.

Where it fits

• Building an integration that calls decisions from outside? Use the evaluate API with authentication.
• Wiring a decision into a BPMN process? See the business-rule task.
• Investigating a past decision? Open the Executions view, or fetch the execution by ID.