Skip to main content
Quartyl
Predictive Riskprofessional

Study Risk Drill-Down: From Score to Action

Opening one study inside the risk engine: the per-factor breakdown, which recorded figure drove each factor, and the fix that actually moves the score.

Quartyl Team

The drill-down is the step from a number to a fix: from the portfolio figures into one study’s per-factor breakdown, the recorded figure behind each factor, and the change to the analysis that moves the score. The scoring model defines what each factor is; this page is how you work it.

What these numbers are: rule-based indices over the study’s stored analysis, with fixed weights and bands. A high score is a reason to look at the file; it is not an estimate of the chance that an authority picks it up.

The per-factor breakdown

Plan feature: This capability requires the predictive_risk plan feature (see Plan Features).

The risk page lists your assessed studies as a row of selector buttons, each badged with its audit band. Selecting one renders that study’s full breakdown under the three gauges — nothing further loads, and no company-level detail appears: the risk view stops at factors, criteria, counts and the accepted comparable total. Each score breaks into its parts:

  • Audit probability — each of the six factors with its value out of 100, its weight (shown where the weight is non-zero), its status (high / moderate / low, which colours the bar) and a description line, plus the summary sentence. The weighted contribution each factor makes to the total rides in the response too; the page surfaces value, weight and status.
  • Defensibility — each criterion with its score out of 100 and its detail line (for example, “11 comparables below recommended thresholds”, “CV of 42.3% suggests variability in the set”, “IQR/Median ratio of 0.62 indicates spread”), the grade and label, and the range analysis (the 25th-75th figures, the IQR, the CV, the sample size).
  • Litigation — the named contributing factors and the mitigation suggestions, alongside the probability and its level.

The data behind a weak factor

A factor is only as real as the data behind it — and each factor reads one specific recorded figure, not the pool as such. The risk view tells you which figure is weak; the companies sit in the study’s own results.

Weak factor The recorded figure behind it
Persistent Loss Indicators The share of accepted comparables with a recorded PLI at or below zero — the rows dragging the pool negative
Comparability Variability (CV) The CV in the study’s statistics block — the dispersion of the accepted set as the run recorded it
Range Tightness (IQR/Median) The IQR and median in the statistics block — a wide IQR relative to the median
Tested Party Margin Placement The margin stored with the analysis result, against the recorded lower/upper quartile — inside, near, or outside
Sample Size The count of accepted comparables carrying a recorded PLI — the output of the screening pipeline
Acceptance Rate The accepted-versus-screened counts stored with the analysis result — the disposition pattern on the grid

Reading the number is one step; reading the companies behind it is another, and the risk engine does not do it for you — the grid and the evidence repository do. See the FAQ below.

The pattern worth checking alongside a weak factor is the override review — but understand what is and is not wired in. The override ledger and the rejected set are not inputs to any score: a study’s factors see only the result stored with it. So a heavy ledger on the same study tells you the weak pool was assembled by hand as well as by filter, which changes how you fix it (a disposition problem, a search-design problem, or both) — it does not change what the number means.

The action path

Work the weak factor, in this order, before the assessment year closes:

  1. Re-benchmark — for a weak sample, CV or range-tightness factor: revisit the pool and the filters (the search design, the quantitative screen, the qualitative dispositions), and re-run. This is the D/F re-benchmark queue applied to one study.
  2. Override review — for a weak acceptance rate or a disposition pattern: walk the grid’s accepts and rejects against their rationales, and correct the record where a disposition is wrong. The correction is recorded, with a mandatory rationale, in the override ledger.
  3. Documentation fix — for a margin-placement or below-range conclusion: address the tested party’s margin and the adjustment before the file is closed, so the conclusion the TPO sees is the one you intend.

The order matters: re-benchmarking changes the pool, which changes the statistics, which changes every downstream factor — so it is done first and re-read after.

What changes the score

The scores are derived, never stored, and they read the analysis result the study holds. A completed re-run recomputes all three from the new data and the drill-down reflects the new factors; a re-disposition that has not landed in the stored result moves nothing. There is no manual override of a score — the lever is the study, not the number.

FAQ

Do I need to fix every weak factor? No — start with the factor whose weight and value do most of the work; the factors are weighted, and one dominant drag often explains most of the total.

Where do I see the accepted set itself? Not here. The risk response ends at factors, criteria, the range analysis and the accepted count. The companies are in the study’s benchmarking results and the Evidence Repository — the drill-down names the factor, the grid and the repository show the rows.

How soon after a re-run do the scores update? Nothing is stored, so no score is ever stale in the database. The figures on this page come from the portfolio summary, which is computed on read and cached per tenant (per owner for a Superadmin); study transitions clear that cache, so once the re-run has finished and the study has moved state the next read rebuilds it — an analytics TTL covers anything that slips through. A direct read of a single study’s risk endpoint is recomputed every time.

See it working in your workspace

Sign in to run the steps above on a real study — or book a demo and we will walk the workflow end to end.

Related docs

Book a Demo

Tell us what you'd like benchmarked

We'll confirm a 30-minute screen-share slot within one business day.

We reply within one business day. Your details are used only to arrange the demo — never shared or sold.