Signals & Attributes

RiskOS™ workflows process five distinct types of data during an evaluation. Each has a precise definition, a distinct runtime role, and a specific location in the API response.

Data taxonomy

Attributes

An attribute is an input data point about the entity being evaluated — the information your application sends in the POST /api/evaluation request.

The Input step of a workflow defines which attributes are required and optional. Attributes are available to all downstream steps as operands in conditions and rules.

Signals

A signal is a discrete data point returned by an enrichment during workflow execution. Signals are the primary evidence used by rules and conditions to reach a decision.

Signals appear in data_enrichments[].response.* in the evaluation API response.

Reason codes

A reason code is a human-readable identifier explaining a specific factor in an enrichment result or decision outcome. Reason codes provide explainability — they answer "why did this evaluation receive this decision?"

Reason codes are not decision inputs — they are decision explanations. Rules and conditions evaluate signals, not reason codes (though the has reason code operator enables reason-code-aware routing).

Tags

A tag is a metadata label conditionally attached to an evaluation by a Tag step in the workflow. Tags classify evaluations for operational purposes.

Tags are metadata, not decision inputs. They describe the evaluation after the fact, enabling downstream filtering and reporting.

Derived values

A derived value is a value computed during workflow execution from attributes, signals, or other derived values. Derived values are intermediate computations used by downstream rules and conditions.

Derived values appear in the computed object of the API response (requires feature flag) and are referenced in downstream steps using the $output_field_name syntax.

How data flows through a workflow

flowchart TD
    REQ["API Request"] --> ATTR["Attributes (input)"]
    ATTR --> INPUT["Input Step"]
    INPUT --> ENRICH["Enrichment Steps"]
    ENRICH --> SIG["Signals"]
    ENRICH --> RC["Reason Codes"]
    INPUT --> TRANSFORM["Transformation Steps"]
    TRANSFORM --> DV["Derived Values"]
    SIG --> RULES["Rules & Conditions"]
    DV --> RULES
    RULES --> TAG["Tag Steps"]
    TAG --> TAGS["Tags"]
    RULES --> DECISION["Decision"]
    SIG --> RESP["API Response"]
    RC --> RESP
    TAGS --> RESP
    DV --> RESP
    DECISION --> RESP

Entities and aggregations

RiskOS™ tracks certain attributes as entities — core data elements that represent a real-world actor (email address, phone number, SSN, account UUID). Entities enable:

• Aggregation features: Computations applied across evaluations sharing the same entity (count, average, sum, min, max, first seen, last seen, distinct count).
• Time windows: Aggregations can be scoped to specific periods (minutes, hours, days, or lifetime).
• Cross-journey linkage: The same entity connects evaluations across onboarding, authentication, and fraud review via SocureID.

For entity configuration and aggregation functions, see Entities and Aggregations.

Related concepts

• Enrichments — The data services that produce signals and reason codes
• Rules & Conditions — The logic that evaluates signals and derived values
• Evaluations — The execution context where all data types flow
• Decisions — The outcome that signals, rules, and derived values drive toward
• Statuses & Lifecycle — Lifecycle states vs data objects
• Terminology Governance — Canonical naming for data concepts
• Handling Dynamic Fields — Working with data_enrichments and computed in the API response
• Custom Fields — Passing custom attributes in the evaluation request