Three Peers or No Verdict: A Hard Gate Against Fake Comps

You pull up a valuation snapshot and it tells you a company is trading at an 18% premium to its sector median forward price-to-earnings ratio (the stock price divided by analysts' estimate of next year's earnings per share). The number is clean, specific, and confident-sounding. What it usually doesn't tell you — anywhere on the page — is how many companies that "sector median" was actually built from.

That gap matters more than it looks. A median of five comparable companies is a real statistical statement. A median of two is just whichever of the two happens to be priced higher that week, wearing the costume of a median. Most data providers don't distinguish between those cases in the display — the premium or discount call reads exactly the same whether it rests on twelve peers or one. For a diligence analyst leaning on a "trading rich to peers" or "trading cheap to peers" claim to size a position or justify a valuation adjustment, that's a silent failure mode: the number is real, but the confidence it implies isn't.

The policy: a numeric floor, not a caveat

LacunaIndex's peer-comparison pipeline treats this as a hard gate rather than a footnote. The rule is one function, applied everywhere a peer-relative number gets computed:

• Fewer than 3 primary peers → the comparison is suppressed. No premium, no discount, no percentile — nothing gets published.
• 3 to 4 primary peers → published, labeled moderate confidence.
• 5 or more primary peers → published, labeled robust.

"Primary" here means peers the system has deliberately curated into that company's comparison group, not every company that happens to share a broad industry tag. The threshold is enforced at evaluation time against the live count, not against a number cached from whenever the cohort was last edited — so a cohort that shrinks (a peer gets delisted, acquired, or reclassified) loses its published comparison automatically, without anyone having to remember to re-check it.

When a comparison is suppressed, the system doesn't leave a blank cell or a stale figure sitting there. It substitutes an explicit sentence naming the actual peer count and the minimum required — something closer to "sector comparison suppressed — 2 peers, minimum 3" than a dash. The point is that a diligence analyst reading the report sees the gap in the data, not an absence that could be mistaken for "no premium."

Enforced where the number is written, not just where it's shown

The more interesting engineering detail is where this check actually lives. It would be easy to compute the spread anyway and just hide it behind a confidence label in the user interface — cheaper to build, and it would look the same to a casual reader. LacunaIndex's pipeline does the opposite: the write step that snapshots a company's valuation spread checks the peer-group policy before it writes anything, and if the peer set is too thin, it refuses to write a spread row for that company at all, for that day.

That distinction is not cosmetic. A UI-only suppression still leaves a real, calculated number sitting in the database — reachable by an export, an application programming interface (API) call, or a future feature that forgets to check the confidence flag. Refusing to persist the row in the first place means there is no thin-comp number anywhere downstream waiting to leak into a report, a chart, or a bulk data pull. The gate fails closed: if the system can't confirm the peer set is large enough, or can't read the policy check at all due to a transient error, it does not fall back to publishing a number — it skips that company for that day and tries again on the next scheduled run.

A real bug this design exists to prevent

The policy isn't theoretical hardening — the codebase's own comments point to a specific incident that motivated part of it. Peer-group membership in LacunaIndex is many-to-many: a company can legitimately belong to more than one comparison cohort at once. Fidelity National Information Services (ticker: FIS), for example, sits in both a core-banking-technology cohort and a broader financial-infrastructure cohort, because it genuinely competes in both.

An earlier version of the pipeline resolved each company's peer group using a single sector tag per company rather than this many-to-many membership table. For a company like FIS, that meant only one of its two legitimate cohorts was ever consulted — and in at least one recorded case, a data gap in a single peer's pricing feed left that single-sector view down to one comparable company, silently collapsing an entire sector's median onto that one company's multiple. The current design — resolving the full peer set through the dedicated membership table, then applying the three-peer floor on top — closes both problems at once: it stops using an under-counted cohort, and even if a cohort is inherently small, it stops treating a one- or two-company sample as a "sector."

The question worth asking regardless of source

None of this is specific to LacunaIndex as a data product — it's a general diligence discipline. Any time you see a peer-relative valuation claim — a premium, a discount, a percentile rank, a "trading in line with peers" statement — in a research note, a data terminal, or a model you inherited from someone else, the first question should be the one the display rarely answers on its own: how many companies is "peers" actually counting? A comp set of two is not a smaller version of a comp set of eight; it's a different kind of number, one that should carry a different level of trust in a valuation argument. Treat any peer-relative number that doesn't disclose its sample size as unverified until you've gone and counted the peer set yourself.