The Comparables Grid: Review, Accept, Reject and Override

When the pipeline settles, its output is one working surface: the comparables grid. Every company the screen touched - accepted, almost-accepted, flagged, rejected - is a row with its PLI, its screening status, its stored reason and its disposition. The grid is where the study becomes defensible, because the arm’s length range is computed only over what this grid ends up accepting.

What the grid shows

The grid renders the screened population in its four buckets, each row carrying:

Column / element	Content
Company	The comparable’s name, as recorded
Revenue	The normalized revenue figure from the dump
PLI	The company’s profit level indicator for the study’s margin type
Reason	The stored reason - the rejection reason for rejects, the engine rationale for flags and borderline accepts
Verdict badge	The engine’s status - accepted, almost-accepted, flagged or rejected - colour-coded
Override badge	The reviewer’s effective verdict when it differs from the engine, shown alongside the original
Actions	Open details; then Accept, Reject, or Revert where an override already exists

The details panel for a row is the per-comparable evidence file in one place: the AI recommendation, risk level and description-confidence badges; the engine’s rationale text; the composite score, semantic similarity and keyword overlap as percentages; the financial figures (revenue, cost, operating profit, PLI, RPT share, employee cost); the reference identifiers (industry, country, website, NACE code, BvD ID); and the four description fields as they came from your dump - business description, trade description, full overview, and main products and services.

What it does not show: a parent chain, or any web-research finding - no fetched URL, no HTTP status. Web evidence reaches the report columns instead (see Website Enrichment). The Website row here is the dump field, displayed for your benefit; the grid does not open it or show any web-research result (the optional Web Research step surfaces in the report and the deep-screening pass, not this modal).

Dispositions: what each status means

• Accepted - the engine’s screen passed the company at every layer. These stand in the range without you doing anything; your job on this bucket is to find the ones that should not be there and reject them with a reason.
• Almost accepted - a functional match with broader scope than the tested party (extra product lines, extra functions or channels). A borderline bucket that exists so “close but not quite” is a named state instead of a coin flip.
• Flagged - “we cannot tell; a human needs to look.” Thin or missing descriptions, low-confidence scoring, and data gaps land here. A flag is not a rejection; it is a work order.
• Rejected - the engine found a specific, stored reason. The reason is the whole point: “High RPT,” “Below minimum revenue,” “Non Comparable Product” with the misalignment named - not a blank refusal.

The engine status is never hidden. When a reviewer overrides, the original engine verdict stays visible underneath the reviewer’s, so the grid always shows both what the machine said and what the human decided.

Accept, reject - and override

During review (the study in In Review), a reviewer with the review role can set an effective verdict on any row. There are two reviewer dispositions, not three: Accept and Reject. Flag is an engine state meaning “undecided”, and the way you resolve one is to decide it.

• Accept a flagged, almost-accepted or engine-rejected company - going against the screening recommendation, so the entry should say why.
• Reject an engine-accepted company for the same reason, or settle a flagged / almost-accepted row the other way. An undecided row offers both actions; a decided one offers the one that changes it.
• Revert - clears your override and restores the engine’s verdict.

Every decision opens a reason dialog first, and the reason is required: the dialog will not confirm on an empty box, and a verdict that arrives without one is refused at the API. An override nobody can explain is not a decision anyone can defend, so there is nothing to record. Correction entries made against AI results are governed the same way.

Decisions are staged rather than committed one at a time: they collect in the grid, the badges update immediately, and they are written together when you finish review - each one recorded in the study’s audit trail as a reviewer override with the previous and new value, the actor, the role, the timestamp and the reason. Each row carries a version, so if another reviewer settled that row first, your stale write is refused with a conflict rather than silently winning. The mechanics and the audit consequences are documented in Overrides. This grid is the product-side record of what the knowledge side calls the accept-reject matrix.

Sorting, filtering and navigation

• Bucket filters - all, needs review, accepted, rejected, almost accepted, flagged, and overridden-only, each with a live count, so “how many borderline companies are left” is a glance, not a count. The accepted and rejected tabs hold rows a verdict was actually reached on; the almost-accepted and flagged tabs hold the ones still waiting for you, so an undecided row is never counted as a rejection.
• Triage order - the list opens with the rows the screen asked a human to look at, in the order it built them (verified related-party conditions first, thin evidence last); everything else follows in bucket order. The order comes from the study’s screening summary, so the grid and the Review Queue section of the results always agree.
• Name search - find a specific company in a large pool.
• Pagination - the review screen loads the study’s settled result set and pages it at 25 rows by default, with the page size adjustable. The bucket counts reflect the whole loaded set, never just the visible page.

The review workflow is the loop: work the flagged and almost-accepted buckets first (the judgment calls), confirm the accepts, verify the rejects’ reasons against the data, override with a rationale where you disagree, and clear the overridden filter until it is empty.

How the grid feeds the statistics

The range is downstream of the dispositions. When a report is built, the reviewer verdicts are authoritative: an accept you recorded keeps a company in, a reject takes it out, and anything the engine did not explicitly accept - including an unresolved flagged or almost-accepted row - falls out of the pool unless you accept it. Statistics are then recomputed over that effective accepted set, so the workbook and the grid cannot disagree.

That is why an empty flagged bucket is a review completion criterion rather than an aesthetic preference: an unresolved company is silently a non-comparable in the finished document. When the grid settles, the statistics, the tested party’s position, and the report all reflect exactly what this surface shows.

FAQ

Can an analyst change a disposition? Override rights belong to the review roles - Manager, Firm Admin and (acting in the same scope) Superadmin - while the study is in In Review. Analysts see the grid, work the data and prepare; the recorded decision is the reviewer’s.

What happens to my overrides if the study is re-screened? A re-run replaces the engine’s comparable set with a fresh run, so the previous engine verdicts - and the overrides attached to those rows - are retired with them. The audit trail keeps the record that a re-run happened and what the prior decisions were.

Where do the reject reasons come from? Each screening layer stores a specific, human-readable reason per company - the quantitative filter that fired, the qualitative mismatch named, or the AI’s FAR category. The grid displays the stored string; it is not generated at display time.