Skip to main content
Quartyl
Results & Analyticsprofessional

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.

Quartyl Team

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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

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.