How Vessent scores vendors

Combines up to five public sources into one 0–100 score. Each source contributes its own weight, renormalized over whichever sources a given vendor actually has data for — a vendor missing a source (no PyPI package, say) isn't penalized for that absence, its weight simply doesn't apply that cycle.

For each source, a raw number (e.g. 8,000 GitHub stars) is log-scaled to 0–100 against a per-source saturation cap, so a source with naturally huge numbers (npm downloads) can't dominate one with naturally small numbers (Hacker News mentions) just because its raw magnitude is bigger. Once a source has two or more cycles of history, that level figure is blended 60/40 with a cycle-over-cycle growth figure — before that, a vendor is cold-start and shows a raw level only, with no fabricated trend.

A momentum score of 0 doesn't always mean a vendor is inactive. It means none of the five sources above found measurable activity — common for an established or enterprise-embedded vendor whose engineering activity is mostly private, or a vendor with no open-source distribution at all. Hacker News mention-counting in particular only looks at a single day at a time, so it reads as zero for most vendors on most days regardless of how real the company is. A low or zero momentum score is a statement about public visibility, not company health.

A snapshot, not a trend — it reads whatever compliance badges are currently detectable on the vendor's public trust-center page. Each certification below contributes its own points; the total is capped at 100 rather than normalized, so a vendor with every certification just hits the ceiling instead of diluting what any single one is worth:

HIPAA and FedRAMP are weighted close to SOC 2 since, like it, they're independently audited rather than self-attested. CCPA is weighted like GDPR's narrower cousin — a privacy-regulation compliance claim, not an audited certification, and its California-only scope overlaps heavily with what GDPR compliance already implies.

A recent, short-notice model deprecation subtracts up to 30 points — the shorter the notice period (under 30 days counts as short-notice) and the more recently it was announced (within 180 days), the larger the penalty. An old or long-notice deprecation doesn't weigh on a vendor's current readiness at all.

A dash (—) means "not enough evidence," never a confident zero. Many hosted trust-center platforms (Vanta, Drata, SafeBase) render their badge list client-side, which a plain page fetch can't see — an all-false read from one of those is ingestion noise, not a real negative, so it's shown as no score rather than a misleadingly confident 0. A real 0 only appears when the page was actually readable and genuinely showed no certifications.

For a vendor with independently confirmed, established enterprise adoption (see below), the readiness score is superseded by an "Enterprise-ready" label instead — that question is already answered by a stronger signal than a certification count.

Momentum and Readiness are computed from the public sources above and nothing else. In particular, the scoring code has no access to and cannot be influenced by:

• Reviews or ratings — Vessent doesn't collect them.
• Payment or claim status — a paid, claimed vendor and an unclaimed one with identical public activity get an identical score. Paying unlocks the ability to respond to a signal publicly and a "Verified" badge, not a score boost.
• Curator-researched facts — funding stage, founding year, and known enterprise adoption are all researched and displayed separately, but never fed into the score. A well-funded vendor and a bootstrapped one are scored on identical public-activity and compliance evidence.

This is enforced structurally, not just by convention: the scoring service connects to the database with credentials that have no read access to claim, subscription, or billing data at all — there is no code path through which that information could leak into a score, even by accident.

Every source is re-fetched daily and scores are recomputed right after. If a single fetch fails for a vendor on a given day (a rate limit, a timeout), the last known good value is carried forward and used as-is rather than dropped — the vendor's detail page marks that specific reading "stale" so it's never presented as fresher than it is.