Decisions in RiskOS™
Learn how RiskOS™ produces accept, reject, and review outcomes — including automated decisions, manual review overrides, and the decision fields in the API response.
A decision is the final outcome of an evaluation. It represents the platform's determination — based on enrichment data, rules, and scoring logic — of whether to accept, reject, or flag an entity for further review.
Decisions are set by terminal workflow steps: a Decision step for automated outcomes, or a Manual Review step for human review.
Decision values
The Evaluation API returns three standard decision values:
| Value | Meaning | Typical action |
|---|---|---|
ACCEPT | The entity passed all checks | Proceed with onboarding, transaction, or access |
REJECT | The entity failed one or more checks | Deny the request |
REVIEW | The evaluation requires human assessment | Route to Case Management for manual review |
Custom and step-level values: Decision Rules steps can also assign values such as
RESUBMITandCANCEL, or route to Manual Review. You can define additional custom decision values when configuring a Decision step or Decision Rules step. These values appear in the API response and Case Management alongside the standard values.
Two types of decisions
Automated decisions
Set by a Decision step or Decision Rules step in the workflow. These are returned in the evaluation API response without human involvement.
Manual review decisions
When a workflow routes to a Manual Review step, the evaluation enters Case Management. A human reviewer examines the case and makes a final decision — typically Accept or Reject. The reviewer's decision is communicated back to your system via webhook (decision_update event) or API polling.
Where decisions appear
| Location | Field / event | Description |
|---|---|---|
| Evaluation API response | decision | The automated decision from the workflow |
Webhook: evaluation_completed | data.decision | Final decision after an async workflow completes |
Webhook: decision_update | data.decision | Updated decision after manual review |
| Case Management UI | Decision column | Visible in case queues and case detail views |
Decision vs status vs evaluation state
Decisions, statuses, and evaluation states are three distinct runtime concepts:
| Concept | Question it answers | Values | Set by |
|---|---|---|---|
| Decision | "What action should we take?" | ACCEPT, REJECT, REVIEW, custom | Workflow step or human reviewer |
| Case status | "Where is this case in the review process?" | Open, On Hold, Closed (with customizable sub-statuses) | Case Management system or reviewer |
| Evaluation state | "Where is this evaluation in execution?" | evaluation_in_progress, evaluation_paused, evaluation_completed | Runtime engine |
A case can have a REVIEW decision, an Open status with an "In Review" sub-status, and an evaluation_completed evaluation state simultaneously — each tracks a different dimension.
For the full lifecycle model with state diagrams, see Statuses & Lifecycle.
Related concepts
- Evaluations — The process that produces a decision
- Workflows — The logic that determines which decision to return
- Statuses & Lifecycle — How decisions differ from statuses and evaluation states
- Cases & Manual Review — How
REVIEWdecisions are handled - Rules & Conditions — The logic that influences the decision
- Signals & Attributes — The data that rules evaluate to reach a decision
- Enrichments — The data services that provide signals for decision-making
- Terminology Governance — Use
ACCEPT(uppercase code) for API values, "accepted" in prose - Webhook Events Reference — Events that communicate decisions asynchronously
Updated 5 days ago