Benchmarking Results List: Comparing Analysed Studies
The benchmarking results list across analysed studies: study, entity, state, total entities, arm length conclusion and accepted-rejected counts, paginated for side-by-side review.
The Results area has two views: the per-study results (open one study, read
one benchmark) and this one — the Benchmarking Results list, the
cross-study view. One row per study whose analysis run has committed — at
any state since, In Review included — in the firm’s context: what was
benchmarked, where the tested party landed, and how much of the screened
population survived. It is the triage layer of the practice’s finished work —
the place to compare studies side by side and to find, at a glance, the
studies that need attention. Which rows you see follows your place in the
firm: partners and firm admins see the tenant’s studies, everyone else sees
only studies they created, are assigned to, or share a team with, and a
superadmin on a tenant-less platform account sees their own studies alone
(backend/app/services/workflow/workflow.py:383-433).
The columns
| Column | What it tells you |
|---|---|
| Study Name | The study’s identity — its name in the workflow |
| Entity | The tested party entity the study benchmarks |
| Status | The study’s workflow state as a badge. Any state can appear once the analysis exists, so In Review, Report Generated, Document Generated, Signed Off and Archived all land here |
| Uploaded File | The study’s source dump file, named and linked where a URL exists |
| Total Entities | The number of candidates that entered the quantitative screens — the denominator behind the two count columns |
| Arm’s Length | The run’s conclusion badge: green for Within Arm’s Length, red for Below or Above. Under it, where the study has one, the tested party’s own margin: Tested Party: x% |
| Accepted | The accepted comparable count the run recorded (green) |
| Rejected | The rejected comparable count the run recorded (red) |
| Actions | Open — the study’s full results detail in one click |
Those three numbers and the badge are the run’s, not the review’s: the
pipeline writes them once when Final Analysis commits, and no later review
action re-cuts them
(backend/app/services/pipeline/run.py:647-650). Committing reviewer
overrides rebuilds the study’s persisted statistics on the effective accepted
set — which is what the results detail and the on-demand Word and PDF
deliverables then read — while this list keeps showing the counts the run
itself recorded. Read a row as “what the screens produced”, and the study’s
own results detail as “what the review settled on”.
The list is ordered by most recently updated and paginated with a selectable
page size, with a refresh action for when a study’s state has moved. There
are no sorting controls, and the header search box is not wired to this
endpoint: the list call accepts only a page and a page size, so the term is
sent and silently ignored and typing does not narrow the list
(backend/app/api/routers/studies.py:342-358). To find a study by name, use
the study list, which matches name and entity.
Comparing studies side by side
The list is the comparison surface. The fields that matter in a side-by-side read:
- Tested party — the entity column: same entity across years, or different entities in the same sector.
- PLI and range — the row carries the tested party’s margin; the band itself is one click into the detail. The detail’s statistical record — range, percentiles, the tested party’s position — is what the comparison is really about, documented in Reading the Statistical Results.
- In-range status — the green/red badge: the one column that separates findings from non-findings.
- Year — the study’s financial year, on the study itself; the same entity benchmarked across years shows the tested party’s trajectory.
- Jurisdiction — on the study; a cross-jurisdiction comparison is a scope comparison, and the badge means less when the regulatory context differs.
A useful discipline: compare the accepted count against the total column pair, not the accepted count alone. An accepted count of eight out of forty is a different benchmark from eight out of twelve — not because the ratio is scored anywhere (the acceptance rate is reported beside the risk metrics but feeds neither the risk nor the reliability score; it does carry weight in the separate defensibility grade), but because a heavily screened pool is a narrower evidential base. The pool’s shape is what the risk and reliability scores do measure.
The quick way to spot re-benchmarking work
Scan the list for the patterns, in order of priority:
- Red badge, thin accepted count. Out of range with a small pool — the range may be an artefact of the pool, and the first move is to widen the search, not to defend the number.
- Red badge, rich pool. Out of range with a large, clean pool — a finding about the tested party, not the benchmark. The adjustment path, not the re-benchmark path.
- Old data. A study whose financial years are the practice’s oldest — benchmark data ages, and the sector view (Industry Diagnostics) will usually show the sector has moved since the study ran.
- The same entity, multiple runs. Two finished studies for one entity with different conclusions — the parameter difference between them is the review item.
There is no separate “refresh” action: re-benchmarking is what the study already does — upload a newer dump and run the analysis again. The run replaces the study’s stored result and updates this row in place, so the counts, the badge and the tested party’s margin move with it.
Where studies come from and stay
A study enters this list when its analysis run commits, and never leaves it on account of state: a study sitting In Review is already here, so the state badge — not presence in the list — is what says whether the work is finished. Results become part of the firm’s approved record as the study passes review and sign-off, and an archived study is read-only, so its row is the settled version of that benchmark. A study still mid-run, or one whose run failed before statistics, has nothing to show yet and stays out until Final Analysis commits.
FAQ
Should a study still in review be here? Yes. The row is created when the analysis commits and is not withdrawn as the study moves, so In Review studies sit alongside Report Generated and Signed Off ones — the badge tells you which is which. A re-run updates the existing row in place rather than adding a second one.
Can I sort the list by conclusion? No — the order is fixed to most-recently-updated first, and the search box does not filter. The red/green badge is the fastest manual sort for out-of-range studies. For a structured cross-study read, the industry diagnostics view aggregates the same finished work by sector.
What does Open do? It takes you to the study’s results detail — the
full statistical record, the charts (where the firm’s plan holds
result_charts) and the report actions for that study.
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
Reading the Statistical Results: Range, IQR and Percentiles
How to read the statistical results: accepted comparables distribution, median, the applied arm’s length band, percentiles, CV, and tested party position inside the range.
Read docYour First Study in 10 Minutes (Quickstart)
From empty workspace to a benchmarked study: create it in the three-step wizard, upload and map the Excel dump, pick the PLI and averaging basis, run the pipeline and read the arm's length range.
Read doc