--- title: "How to Test a Single Record in a Policy" description: "Run a policy on one application to see which rules passed, which offers were created, and how the final decision was reached." ---

TL;DR

When you need to know why one application got the decision it did, open the policy's Single Record Review tab. It runs the policy on that one application and shows the full path: which rules passed, which offers it qualified for, and the final call. Feed it the application whichever way is quickest: look it up by ID (Application Lookup), fill a structured form (Manual Inputs), or type a few values by hand (Quick Input). Submit, then read the result.

## What is it? Single Record Review (SRR) runs a policy on one application and shows you the outcome rule by rule: which segments and rules the application hit, which offers it qualified for, and the final decision. A [simulation](/user-guide/how-tos/run-a-simulation/) gives you population-level numbers; SRR shows you one application in full. Reach for it when a simulation number looks off and you need to know why, or when someone asks you to explain a single decision. A risk reviewer, for example, can spot one approved application with a suspiciously high collections balance, paste its ID here, and watch the policy walk through it. ## How to Run a Single Record Review

#### Open the tab and see where you land

Open the policy you want to review and click its **Single Record Review** tab. What you see next depends on whether a default input mode has been set up. **A default mode is set.** You land straight in that mode's input form, ready to fill in. It is one of three: - **Application Lookup** - a single field asking for an ID (an application ID or account ID). - **Manual Inputs (JSON)** - A set of grouped cards asking for the details needed to run the review. - **Quick Input** - A list of every policy input, each with its own value field. Usually the mode you land in is the one to use, since it is the one the policy owner set. To switch, open the **Configure SRR Options** button, top right. **No default mode is set.** You see three choice cards: **Application Lookup**, **Manual Inputs (JSON)**, and **Quick Input**. Click one to continue. A card marked **Need Setup** has to be configured before you can use it (see [Configuring SRR Options](#configuring-srr-options)); Quick Input is ready to use right away.

#### Fill in the inputs

Expand your mode for what to enter:

You get a single field, labeled with the configured ID column (for example, `applicant_table:application_id`). Type the application ID and submit. If no application matches, the run returns an error naming the ID column and the value it looked for. Check the ID and try again.

You get a form the policy owner configured, so its cards and fields vary by policy. Fields are grouped into named cards, such as *Loan Details* and *Applicant*. A card backed by a data table also lets you pick a row from the Data Lake to auto-fill that card's values.

You get one field per policy input. Each field's placeholder shows the format it expects: | Input type | Placeholder | |---|---| | Single value | *Enter an integer value e.g. 10000*, *Enter a string value e.g. "Arizona"* | | List of values | *Enter integer values as list e.g. [10000, 150000]* | For a list input, enter the values in brackets, exactly as the placeholder shows.

#### Submit

Click the run button at the bottom. Its label depends on the mode: | Mode | Button label | |---|---| | Quick Input | **Submit & Review** | | Application Lookup | **Review Application** | | Manual Inputs (JSON) | **Run Manual Review** | The button shows **Reviewing** while the policy runs. To try a variation, change an input and submit again.

## Reading the output Once the run finishes, the result appears below the input form in two tabs. ### Decision Flow Evaluation At the top is a short summary of the run: which offer matched, which decision was reached, and how long it took. Below the summary, what you see depends on the policy: - Offer-based policies show a table of eligible offers, one row each. Columns cover the product-config values you defined (loan amount, rate, term, and so on), the **Decision Path**, the **Decision**, and, if offer display is configured, whether the offer was **Displayed**. Click a row to expand the block-by-block graph for that offer. - Policies that do not produce offers show a single **Execution Flow** card with the same graph. In either graph, each block, segment, and rule shows its result. To find out why a rule failed/passed, click its node to see the inputs, outputs, and definition behind it. ### Result Data The full row-level output: every input column, derived variable, strategy output, and the final decision. From the grid toolbar you can filter and sort columns, drag headers to reorder them, download as **CSV** or **Excel**, reset the view with the undo icon, or open the **Column Chooser** to show or hide columns. ## Configuring SRR Options Click the **Configure SRR Options** icon at the top of the input card to open the dialog. Each mode card shows a status badge: Selected for the current default, Ready once it is configured, and Need Setup until then. Quick Input is always Ready. Set up whichever modes you want: | Mode | What to configure | |---|---| | Application Lookup | The input table and column that hold the application ID. Only columns that map one-to-one to the application are offered. | | Manual Inputs (JSON) | The form layout, as a JSON array of sections (see below). | | Quick Input | Nothing. It works as-is. | Then pick the card users should land on first and click **Save Default Mode**. ### Manual Inputs JSON structure The config is an array of top-level sections. Each section groups related fields into one or more sub-groups under `sections`, and each sub-group lists its fields in `display_columns`, keyed by `table.column`. A field takes a `name` (the label the underwriter sees) and a `format` (a Python format string, for example `"${:,.0f}"` for currency or `"{}"` for the raw value): ```json { "title": "Loan Details", "sections": [ { "title": "None", "display_columns": { "application.requested_amount": { "name": "Requested Amount", "format": "${:,.0f}" }, "application.term": { "name": "Term (months)", "format": "{:.0f}" } } } ] } ``` That renders one card, *Loan Details*, with two fields the underwriter types in. There are two kinds of top-level section:

Section type	What it does
Manual-entry (for example, "Loan Details")	Fields the underwriter fills by hand. Defined with `title` and `display_columns` only.
Data-table (any title)	Lets the underwriter pick a row from the Data Lake to fill the section. Adds a `primary_table` (the source table) and a `type` object describing the selectable values.

Each entry in the `type` object takes:

Key	Meaning
definition	A filter of the form `table.column = value` (for example, `applicant.borrower_description = 'Primary'`). This value is fed into the policy along with the selected row.
is_optional	`false` requires the selection; `true` makes it optional (for example, a co-borrower).

Here a data-table section lets the underwriter pick an applicant row, once as the required primary borrower and again as an optional co-borrower: ```json { "title": "Applicant", "primary_table": "applicant", "type": { "Primary": { "definition": "applicant.borrower_description = 'Primary'", "is_optional": false }, "Co-Borrower": { "definition": "applicant.borrower_description = 'Co-borrower'", "is_optional": true } }, "sections": [ { "title": "None", "display_columns": { "applicant.income": { "name": "Monthly Income", "format": "${:,.0f}" } } } ] } ``` :::note Every column the policy requires must appear in the config, grouped under the table it belongs to. In the config dialog, click **More info** to open a side panel listing the required columns for the current policy, sorted by table, so you can see what still needs to be covered. ::: ## When to use Single Record Review vs a simulation | Use SRR when | Use a simulation when | |---|---| | You want to debug one application end to end | You want population metrics (approval rate, KS, score distribution) | | You need to explain why one application got the decision it did | You are checking the policy against a threshold across many records | | You are iterating on a single edge case | You are preparing evidence for an Approval Request | You can run both on the same policy. ## What's next - [Run a Simulation](/user-guide/how-tos/run-a-simulation/) to test the policy across a whole population. - [Approve an Object](/user-guide/how-tos/approve-an-object/) once SRR confirms the policy behaves as designed.