How the Vioscale score works
The composite is a confidence-weighted blend of independent signals, not user reviews, not a vendor's self-description. Each signal is normalised to 0-100, multiplied by a category-specific weight, and combined. The score you see is the sum of contributions, discounted by how much evidence we actually have.
This mechanism is the same for any software category. What changes per category is which signals count and how much they are weighted, which is why the score is neutral across very different kinds of software. Vioscale covers the developer tooling vertical today, so the signals below are its set.
The signals we score today (developer tooling)
These are the signals for the developer-tooling vertical. Weights are still set per category within it, so security matters more for CI/CD than for a web framework, and stars are always weighted low.
| Signal | Typical weight | Why it counts |
|---|---|---|
| Package downloads | high | The strongest independent adoption signal: real usage, hard to fake at scale. |
| Stack Overflow activity | medium | Practitioner mind-share and the size of the help ecosystem. |
| GitHub activity | medium | Commit and contributor velocity: is the project alive and maintained? |
| Release cadence | medium | How regularly the project actually ships. Momentum, not promises. |
| Security posture | medium-high | SOC 2 / ISO 27001, disclosure policy, licence; weighted higher where it matters (CI/CD, ORMs). |
| Docs quality | low-medium | How usable the software is once you adopt it. |
| GitHub stars | low (vanity) | Deliberately weighted low. Stars are a popularity artefact, easily gamed and weakly correlated with fitness. |
Other verticals score a different set. The CRM, project management, and analytics categories, for example, weigh signals like pricing transparency, compliance certifications (SOC 2, ISO 27001, GDPR, HIPAA), reliability (a public status page and SLA), and integration breadth, not npm downloads. The scoring machinery, provenance, confidence, and freshness is identical; only the signal set and weights change.
Confidence bands
We never express false precision. Each fact and each score carries a confidence in one of four bands. Missing evidence lowers confidence rather than silently assuming a value.
- high: ≥ 75%
- medium: 50-74%
- low: 1-49%
- unverified: no evidence observed
Intent-conditioned scoring
A score is not a single truth: it is one weighting of the evidence. So the facts and signals stay fixed and provenanced, and only the weight vector varies. The balanced profile is the default and the canonical number we and anyone else should cite. It never changes per query. On top of that, an agent can ask for a re-weighted ranking, by a named intent or an explicit weight vector, and the underlying numbers are identical: only the emphasis moves.
Every profile is public (there are no secretly tuned weights), so no vendor can buy a favourable one. A single-signal cap of 0.5 means one gameable signal can never dominate a popular intent, and the resolved, normalised weights ship in the response so a consumer can verify the ranking. This is an agent and API capability, not a UI toggle: the pages you read always show the balanced score.
| Profile | What it emphasises |
|---|---|
| balanced | The default, citeable composite. Category base weights, unchanged. |
| most-adopted | Real-world usage: package downloads and Stack Overflow activity. |
| most-active | Development velocity: recent commit activity and release cadence. |
| most-secure | Security and compliance posture: SOC 2, ISO 27001, disclosure policy. |
| best-value | Quality per cost. Leans on adoption as a proxy until price data lands in paid categories. |
Agents can also skip the named profiles and pass explicit weights, e.g. weights=security_posture:0.4,package_downloads:0.3,github_activity:0.3. Every profile, its multipliers, and the signal glossary are published, machine-readable, at /api/v1/intents. See the AI & agents page for the query params and examples.
Freshness
A fact's trust decays with age until it is re-crawled. Every value records when we last observed it, and the serving surface exposes that date so a reader, human or machine, can judge staleness for itself. Facts older than the freshness window are re-fetched on a schedule.
A worked example
Here is exactly how that number is built: signal by signal, weight by weight, with contribution shown. Nothing is hidden:
| Signal | Score | Weight | Contribution | Evidence |
|---|---|---|---|---|
| Github Stars | 100 | 0.04 | 3.8 | ✓ |
| Capabilities | 0 | 0.12 | 0.0 | - |
| Integrations | 0 | 0.06 | 0.0 | - |
| Github Activity | 0 | 0.14 | 0.0 | - |
| Release Cadence | 0 | 0.08 | 0.0 | - |
| Security Posture | 0 | 0.10 | 0.0 | - |
| Package Downloads | 0 | 0.20 | 0.0 | - |
| Stackoverflow Activity | 0 | 0.09 | 0.0 | - |
Machine: /api/v1/signals/computer-science
Indexed uniformly, owned by no vendor
Independence is a promise you should be able to check, so here is exactly how vendors fit in, in plain terms.
- Uniform and free. Every product is indexed and scored by the same algorithm, for free, whether or not its vendor has claimed it. A claimed profile and an unclaimed one are measured identically.
- Vendors control their own profile, not the market. A vendor can claim their profile to correct, refine, and keep it current. That governs how their own product is presented, never where it sits in a ranking or a comparison.
- Vendor content is labelled and kept separate. Anything a vendor supplies is clearly marked as provided by the vendor and kept distinct from the facts we indexed independently, so you can always tell a self-claim from an observation and weigh them accordingly.
- None of it moves rank, score, or position. Claiming and editing change only a vendor's own presentation. Signals stay algorithm-computed and vendor-locked, so no amount of vendor control moves a rank, a score, or a place in a comparison.
Provenance
Provenance is the moat. Every value Vioscale publishes is wrapped so it can be cited: what the value is, where it came from, when we last saw it, and how confident we are.
- attribute: the namespaced key, e.g. pricing.model
- value: the observed value
- source: the public URL where we observed it
- retrievedAt: ISO-8601 timestamp of last observation
- confidence: 0-1, surfaced as a band
- sourceType: who asserted it (crawler, vendor, system)
This evidence travels with the data across every format: visible on the HTML page, embedded in JSON-LD as a vioscale:provenance block, and inline in the Markdown twin. See how to consume it on the AI & agents page.