A model name cannot answer "why did this request reach this model?" It identifies the outcome. The real question concerns the information and rules that selected it when other candidates were available.
A decision trace ties an investigation to one evaluated request. Whether you are investigating a user-visible failure or reviewing a policy change, the sequence is useful: identify the request, understand the observed input, read the decision, and check enforcement.
Start with the request identifier
Establish the request identifier and time window first. Two calls made seconds apart can encounter different signals, prompt versions or provider health conditions.
Modelion returns Modelion-Request-Id for correlation. Modelion-Decision contains a short decision summary in the response. The summary helps with a quick inspection; a detailed investigation should continue with the full trace.
The following is an investigation sequence, not an API response schema:
Request identifier
→ input signals seen by the policy
→ policy layers evaluated
→ matching rules and winning decision
→ remaining route candidates
→ obligations to enforce
Inspect the signal before the outcome
A rule failing to match does not necessarily mean the rule was written incorrectly. An expected signal may not have been produced, may have been unavailable, or may have arrived under a different classification.
"No personal data detected" differs from "no scanner result available." Treating them as one negative value hides missing information from a later investigation.
Use the signal the policy actually saw, not the signal you expected it to see. An earlier pipeline problem, such as incorrect prompt hydration ordering, can produce a wrong outcome even when the decision is internally consistent with its inputs.
Matching does not always mean winning
Modelion traces allow the winning rule to be examined alongside rules that matched but lost. That distinction makes a statement such as "the rule did not run" more precise.
| Observation | Next question |
|---|---|
| Rule did not match | Were the input and condition as expected? |
| Rule matched but did not win | What did precedence and layer composition do? |
| Rule won but the outcome is unexpected | How were route constraints and obligations applied? |
Finding a rule name is a starting point. The objective is to explain the sequence that produced the decision.
Separate decision from execution
When a policy produces a redaction obligation, the investigation does not end at a redaction label. Relevant execution evidence should be used to check whether the obligation was applied.
Narrowing a candidate set is also different from successfully calling a particular provider. Policy determines which candidates are eligible, while runtime provider conditions can affect execution. Keep those stages separate in an incident explanation.
Give the logging pipeline boundaries too
Decision inputs can contain sensitive information. OPA's decision-log documentation describes a separate mechanism for removing or masking fields before logs are sent out. OPA decision logs.
Define access scope, retention and the fields that may be shared in your investigation workflow. Begin an issue report with the request identifier and necessary decision evidence rather than automatically including the complete payload.
A useful trace helps explain an event without repeatedly replaying it. The final account should cover not only which model was selected, but which information, rules and obligations led to that selection.
