Skip to content

How to Test a Single Record in a Policy

TL;DR
Open your policy and use Single Record Review to trace exactly how one application flows through every block, rule, and offer. Pick one of three input modes (Quick Input, Application Lookup, Manual Inputs), submit, and read the decision path in the output.

What is it?

Single Record Review (SRR) runs a policy on one application at a time, so you can see exactly which rules passed or failed, which offers were created, and which decision the policy reached. It's the debugging tool you reach for when a simulation shows an unexpected approval rate or a stakeholder asks "why did this specific application get declined?"

  • Test one record at a time instead of running a whole simulation.
  • See the rule-by-rule path the application takes through the policy.
  • Try variations by tweaking a single input and re-running.

Before you start

  • The policy must be registered (it doesn't need to be approved, but it must save without errors).
  • You need read access to the policy.
  • If you plan to use Application Lookup, the policy's input tables must contain at least one application with a unique ID. You also need someone (usually a Platform Admin or policy owner) to have configured an ID column under Configure SRR Options.
  • If you plan to use Manual Inputs (JSON), the input layout must already be set up under Configure SRR Options.

How to Run a Single Record Review

Step 1: Open the SRR tab

Open the policy's details page and click the Single Record Review tab.

If no input mode has been set up, the page shows three choice cards. Quick Input is always available; the others show a Need Setup badge until configured.

Step 2: Pick an input mode

Mode Use when
Application Lookup You want to pull an existing application from a registered table by its ID, so the inputs match production exactly. Best for reproducing a real customer case. Requires the lookup ID column to be configured.
Manual Inputs (JSON) You want a structured form grouped by section (for example, Loan Details, Applicant), with the option to auto-fill a section from a Data Lake table. Best for thorough manual entry. Requires the input layout to be configured.
Quick Input You want to type a few key inputs by hand (for example, just FICO, income, and DTI) and ignore the rest. Fastest. Always available.

To switch later, click the mode card again, or click Configure SRR Options (gear icon) to set up Application Lookup or Manual Inputs.

Step 3: Provide the inputs

Application Lookup

Enter the application ID into the field under the configured ID column (for example, app_table:corridor_application_id). If preset IDs are configured, the dropdown suggests them as you type. The platform pulls all input values from the matching row in the configured table.

Manual Inputs (JSON)

Inputs are grouped into named cards (for example, Loan Details, Applicant). Each card shows the configured display columns; a data-table section additionally lets you select a row from the Data Lake to auto-fill that section's values.

Quick Input

A flat list of every policy input, one field per row. Each field shows a placeholder hinting at its type (for example, Enter an integer value e.g. 10000, Enter a string value e.g. "Arizona", Enter boolean value e.g. True/False). Fill only what you care about; the rest fall back to platform defaults.

Step 4: Submit

Click the run button at the bottom. The button label tells you which mode you're in:

Mode Button label
Quick Input Submit & Review
Application Lookup Review Application
Manual Inputs (JSON) Run Manual Review

The button changes to Reviewing… while the policy runs.

Reading the Output

The output card appears below the input form once the run completes. It has two tabs.

Rule Evaluation tab

This is where you debug. It contains:

  • Executive summary: a short text summary of what happened (which offer matched, which decision was reached, how long the run took).
  • Offer grid (for offer-based policies): one row per eligible offer with columns for Offer, the product-config values you defined (loan amount, rate, term, and so on), Decision Path, Decision, and (if offer display is configured) Displayed.
    • Click any offer row to expand a master-detail view showing the policy artifact graph for that offer: every block, rule, and segment with its result badge.
  • Decision Path dots: a sequence of dots, one per strategy that was evaluated, colored by pass/fail. Hover any dot to see the strategy name and its result.
  • For policies that don't produce offers, you see a single Execution Flow card with the same artifact graph view.

Tip

Click any node in the artifact graph to drill into the rule's inputs, outputs, and definition. This is the fastest way to answer "why did this specific rule fail?"

Dataframe Output tab

The full row-level output: every input column, every derived variable, every strategy output, and the final decision. Use the toolbar to:

  • Filter and sort columns directly in the grid.
  • Reorder columns by dragging headers.
  • Download as CSV or Excel via the toolbar icons.
  • Reset the view state with the undo icon, or open the Column Chooser to show/hide columns.

Configuring SRR Options

Click the Configure SRR Options gear icon at the top of the input card. The dialog shows all three mode cards with a status badge (Selected, Ready, or Need Setup); pick a card, configure it, and click Save Default Mode to set the experience users land in first. You can still switch modes from the main page.

  • Application Lookup: pick which column (and which input table) contains the application ID, and optionally preset a list of IDs that show up as suggestions.
  • Quick Input: no setup needed. Selecting it as the default just lands users on the direct key-value input experience.
  • Manual Inputs (JSON): define the form layout as a JSON array of sections (see below).

Once saved, the corresponding card becomes Ready (or Selected if it's the default).

Manual Inputs JSON structure

The config is an array of section objects. Each section has a title and a sections array of sub-groups, where every sub-group lists display_columns keyed by table.column. Each display column takes a name (the label shown to the underwriter) and a format (a Python format string, for example "${:,.0f}" for currency or "{}" for raw value).

Two kinds of top-level section exist:

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 auto-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 column 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).

Note

Every column the policy requires must appear in the config, grouped under the table it belongs to. The dialog lists the required columns (with name, format, and dtype) for the current policy.

When to Use SRR vs Simulation

Use SRR when Use Simulation when
You want to debug one application end to end You want population-level metrics (approval rate, KS, score distribution)
You're asked to explain why a specific decision was reached You're testing whether the policy meets a threshold across many records
You're iterating quickly on a single edge case You're preparing evidence for an Approval Request

Both can be run on the same policy without conflict.

What's next