Qualitative Data: The Per-Comparable Record and How You Act On It

Every comparable carries a consolidated qualitative record: one JSON document holding what the screen computed about the company and how confident the description behind that computation was. It is written by the pipeline and read by you. Reviewer judgment enters the study through dispositions and recorded reasons, not by editing this record. This page covers exactly what is in it, what is not, and how it drives the review.

What the record holds

The qualitative record consolidates the scoring outputs for one comparable:

Field	Meaning
similarity	Semantic similarity of the company’s description to the tested party’s
keyword_overlap	Fuzzy keyword overlap score
composite_score	The combined score (semantic 0.60 + keyword 0.35, plus name and industry-column bonuses) that drove the recommendation
risk_level	LOW / MEDIUM / HIGH / CRITICAL, from the composite
recommendation	The engine’s call: ACCEPT, ALMOST_ACCEPT, FLAG or REJECT
rationale	The human-readable scoring rationale, with the component scores named
description_confidence	high / medium / low / missing - how much text the screen actually had

That is the whole record. Empty keys are stripped rather than stored as nulls, so a comparable scored without a description carries a short document - the recommendation, the risk level and the rationale explaining the gap. The thresholds behind the recommendation are the ones the knowledge guide documents in Qualitative Screening: accept at 0.42 and above, almost-accept from 0.36, flag from 0.34.

Alongside the qualitative record, the comparable’s financial record carries the description fields the screen read from - full_overview, oneliner, trade_description, products_and_services - so the qualitative and financial sides read together in the details panel.

What the record does not hold

Worth stating plainly, because a reviewer may expect it:

• No captured website text. This scoring record carries no fetched meta description, no description score, no final URL reached and no HTTP status. The qualitative score is computed purely from dump text; website is a dump column it displays but never opens. (The optional Web Research step keeps its findings in a separate field and never writes into this record.) See Website Enrichment.
• No entity block in the record. This document holds scores and the dump text they were computed from — no legal form, no geographic market, no parents, no independence verdict. Nothing in the pipeline joins a registry record onto a comparable at any point, so none of those fields exists to be absent; the report’s External Sources and Corporate Structure columns carry the vendor indicator from your own dump and any labelled web findings, not registry data.
• No computed statistics. The record is per-company comparability evidence. The arm’s length range is computed at final analysis over the accepted set, and is not stored on the comparable.

What a reviewer reads it for

The company-by-company qualitative screen is the part of the review no automated pass can finish: the embeddings say “probably comparable,” and you confirm it against the actual business description. Typical things the record answers:

• Was there enough text to judge? description_confidence tells you whether the underlying dump description was full, short, or absent - and a missing or low confidence is the strongest reason to look at the company yourself before trusting the row.
• Why did this one fall where it fell? The rationale names the components, so a rejection reads as “semantic 0.28, keyword 0.04, composite 0.19” rather than a verdict with no arithmetic behind it.
• Is the flag a scope question or a data question? ALMOST_ACCEPT is the bucket for a broader scope than the tested party; FLAG is the bucket the engine uses when it cannot decide - thin description, or a name or industry match fighting a weak score.
• Does the description fit the function you are benchmarking? A holding company’s description describing the group rather than the tested function, or a line of business the dump does not break out, will not be caught by any score. That judgment is yours.

The evidence standard for your call

Since you cannot rewrite the record, the standard applies to the disposition you record against it:

1. Read the rationale before deciding. The engine’s reason is stored text, and your override should answer it rather than sit on top of it.
2. The before/after is kept. An override is recorded with the previous and new value, the named actor, their role and a timestamp.
3. A reason travels with the decision. Grid overrides carry the free-text reason you type; when you leave it empty the entry records what happened rather than nothing at all, so an unexplained reversal is visible as unexplained. Correction entries against AI results require written justification - the backend rejects them without it.
4. The entry is write-once. Decisions land in an append-only evidence ledger with content hashing, so the chronology cannot be quietly rewritten later. Details in Reviewer Overrides and Rationale.

How a disposition changes the outcome

The chain is direct, and it runs through the grid rather than through the record:

• Your accept / reject / flag decision changes the comparable’s effective disposition. The grid shows the engine’s original call and the human’s final one side by side.
• The statistics follow the grid. Only effective accepts enter the range, so accepting a previously flagged company - or rejecting an accepted one - changes the pool that the final analysis reports on, and the ledger shows why.
• Overrides are re-applied when the report is built, so the document that leaves the platform matches the grid you settled on.

The discipline is the same as the qualitative screen it supports: every company gets a company-specific comparability statement, and the record shows the work - including where a human disagreed with it.

FAQ

Can I correct the description fields? No. The description is your upload’s data, and the run’s scores were computed from it as written. Correct the source file and re-run if the text itself is wrong; at review, record the disposition the corrected reading deserves.

Do dispositions re-run the pipeline? No. An override is applied to the settled result and re-applied at report build; it does not restart analysis. Re-running the pipeline is a fresh screen of the whole run, which retires the current comparable set and its review state.

What about a company with no description at all? It comes out flagged with “Missing/Insufficient Business Description” recorded against it - description quality never rejects a company, because there is nothing to reject on. Your choice is the disposition, with the reason on the record: verify the company outside the platform and accept it, or reject it as unscreenable. Not a description typed into the platform to replace the one the vendor did not supply.