Skip to main content

ABOUT THE EXTENSION SCORECARD

The scorecard is a quality score attached to every published extension. It answers two questions that anyone installing an extension cares about: can I figure out how to use this, and can I trust where it came from?

What the score is

The score is a number out of 100, a letter grade (A through F), and a per-factor breakdown. The breakdown is the important part — the number on its own does not tell a publisher what to fix, and does not tell a consumer what kind of gap to expect. The factor list makes the score self-explaining: a 70% split as "no README, good types" is different from a 70% split as "great README, no repository link", and the card shows which.

The score renders in two places. On an extension's detail page, the full ring and factor breakdown appear alongside the usual metadata. On the extensions browse page, a small ring and the letter grade sit in the bottom-right corner of each card. Extensions that have not been scored show nothing on the browse page — no placeholder — and display "Not yet scored" on their detail page.

The exact factors, weights, and thresholds are on the rubric reference page. This page is about the shape of the system, not the numbers.

Why it exists

A registry with no quality signal forces consumers to evaluate each extension themselves. That does not scale. The scorecard gives a consistent, automated first pass: is there a README, does it show real usage, is the type surface documented, does the repository resolve to a public source. These are things consumers would check anyway, done up front and rendered the same way for every extension.

It is not a competition. The scorecard does not rank extensions against each other, and high scores do not lock in placement. The intent is trust signalling and self-audit. A publisher can look at their own card and know exactly which documentation gap or missing manifest field is the next thing to fix.

How scoring happens

Every publish kicks off a background scoring job. The analyzer pulls the tarball from object storage, reads the README, runs deno doc --lint over the entry points, and writes the per-version results to a metadata record. Factors that live on the extension itself rather than the version — description, platforms, repository, license — are read live from the extension record. Editing them in the owner panel updates the score immediately; no republish needed.

An owner can trigger a fresh analysis with the "Score this extension" or "Rescore" button on the extension detail page. This is useful after fixing a per-version factor like README content or JSDoc coverage — the per-version meta does not otherwise change until the next publish.

Why 100% is reserved

The top 8% of the score can only be earned by extensions published under the @swamp namespace or marked verified by a System Initiative admin. This is deliberate. An automated rubric can check whether a README exists, whether a license is declared, whether a repository URL resolves to a public source — but it cannot check whether the extension does what it claims to do, whether the author is who they say they are, or whether the code is worth running. Those judgments need a human, and 100% is the signal that a human has made them.

A third-party extension that fills in every automatable factor earns 12/13 = 92% = Grade A. That is the ceiling for automation alone, and the scorecard is designed so reaching it is achievable by any publisher who puts care into their manifest and README.

Rubric stability

The rubric will not shift every quarter. When a factor is added it is added deliberately, and when it changes the reasoning is communicated. Existing extensions are not retroactively re-analysed when the rubric moves — their stored per-version data is composed against the current factor list. A publisher who invests in hitting the current rubric can trust that their improvements will persist through future updates.

← PreviousAI Agent Integration