Die Methodik ist als Ganzes versioniert. Jede Änderung an einer Formel, einem Gewicht oder einem Stufen-Schwellwert erhöht die Metrikversion, und jeder veröffentlichte Bericht verzeichnet die Version, unter der er erstellt wurde (metrics.metrics_version). Das macht Ergebnisse über die Zeit auditierbar: Ein historischer Wert lässt sich unter genau den Regeln neu herleiten, die ihn erzeugt haben.
Die aktuelle Version ist 1.13.0.
Jeder Eintrag benennt die genaue Änderung, ihren Geltungsbereich und ob bestehende Ergebnisse vergleichbar bleiben. Die Daten sind Teil des öffentlichen Methodikprotokolls.
Versionshistorie
1.13.0 — 2026-07-22
Zwei Korrekturen, beide ausgelöst durch den ersten Befund einer schädlichen Abhängigkeit, den dieses Register je veröffentlicht hat.
Negativbefunde multiplizieren sich nicht mehr auf. Jede Richtlinie multiplizierte bisher, was die vorherige übrig ließ, sodass ein Repository mit zweien beim Produkt aus beiden landete. Ein Projekt fiel von gewichteten 50 auf 18 unter dem Multiplikator für schädliche Abhängigkeiten und dann auf 11 unter der Verwaisung — eine Zahl, die keine Richtlinie gewählt hat und auf die zur Erklärung auch keine verweisen könnte. Ein Multiplikator sagt aus, wie schwer ein Befund wiegt; er ist kein Kostenposten, der aufsummiert wird. Die strengste Richtlinie bestimmt nun allein, und die übrigen werden ausgewiesen, ohne den Wert erneut zu bewegen. Werte können unter dieser Änderung nur steigen, und nur bei Repositories mit mehr als einem Negativbefund.
Ein zurückgezogenes Paket wird nicht länger wie lebende Schadsoftware bewertet. Jeder Schadsoftware-Befund fragt nun bei der Registry nach, ob sie genau diese Version noch ausliefert. Ist das nicht der Fall, bleibt nichts Installierbares: Der Befund bleibt im Bericht stehen, weil das Projekt an einem Namen hängt, der kompromittiert war, aber er löst keinen Negativbefund aus und kostet keine Punkte.
Die Prüfung fragt nach der aufgelösten Version und nicht nach der neuesten des Pakets, und die Unterscheidung entscheidet reale Fälle. Nach einer Entfernung lässt npm ein Platzhalter-Release als neueste Version des Pakets zurück, was alle schützt, die einen Versionsbereich auflösen, und niemanden, der die schlechte Version exakt festgeschrieben hat. Die neueste Version zu lesen hätte genau das Repository freigesprochen, bei dem dieser Befund zuerst anschlug — es pinnt das kompromittierte Paket auf die Version, die die Registry weiter ausliefert. Wo die Frage überhaupt nicht beantwortet werden kann, wird der Befund bewertet, als wäre das Paket weiterhin verfügbar — eine Registry nicht zu erreichen ist kein Beleg dafür, dass Schadsoftware zurückgezogen wurde.
1.12.0 — 2026-07-22
Die Stufe erklärt der Richtlinie zur Verwaisung schlug zu häufig auf Registry-Belege an, die gar nicht zu dem Repository gehörten, über das sie urteilte.
Diese Stufe existiert, um die Betreuung zu zitieren statt irgendetwas zu folgern: Ein Projekt gilt als erklärt unbetreut, wenn es archiviert ist oder wenn jedes Paket, das es veröffentlicht, eingestellt wurde. Zwei Fehler weiteten sie aus. Ein Paket zählte als eigenes Paket des Projekts, solange die Registry nicht ausdrücklich das Gegenteil sagte — was Einträge zuließ, die überhaupt kein Repository angeben, genau die Form, die ein besetzter Name annimmt. Und ein zurückgezogenes neuestes Release zählte als Einstellung, obwohl das Zurückziehen eines Releases meist ein misslungener Build ist, dessen Korrektur unmittelbar folgt.
Zusammen brachten sie ein mit 68 bewertetes Projekt auf 27, gestützt auf einen PyPI-Platzhalter, den es gar nicht veröffentlicht. Ein Paket muss nun dieses Repository angeben und ausdrücklich als veraltet markiert sein; ein zurückgezogenes Release trägt nicht mehr bei. Von 403 Repositories in der Stufe erklärt ruhten 391 auf GitHubs eigenem Archiv-Flag und standen nie in Frage.
1.11.0 — 2026-07-21
Verwaisung wird zu einem Negativbefund über den gesamten Bericht.
Jedes Werkzeug in diesem Feld beantwortet die Frage „ist dieses Projekt tot?“ mit Tagen seit dem letzten Commit, und jedes irrt sich bei denselben Projekten: Eine kleine, vollständige Bibliothek, die seit drei Jahren keinen Commit brauchte, ist fertig, nicht verwaist. Sie für tot zu erklären kostet ein öffentliches Register seine Glaubwürdigkeit genau bei der Software, die das meiste Vertrauen verdient.
Die Bewertung beruht deshalb auf einer anderen Frage — Verwaisung ist eine unerfüllte Pflicht, nicht die Abwesenheit von Lärm. Die Stille wird ab dem letzten menschlichen Commit gemessen und ist für sich allein nie ein Befund; sie wird erst dann zu einem, wenn sichtbar Arbeit eintrifft und nicht bearbeitet wird: eine unbeantwortete Beitragswarteschlange, Issues, auf die nie eine Betreuung antwortete, ein nicht behobenes Advisory in einer direkten Abhängigkeit, ein an der eigenen Taktung des Projekts gemessener Release-Stillstand, eine fehlschlagende oder jahrealte CI, ein einziger Betreuer, der im gesamten Fenster fehlt. Lesarten, die die Stille erklären, halten das Ergebnis bei ruhend, was keine Abwertung nach sich zieht — Stille ist bereits in der Entwicklungsaktivität eingepreist, und sie zweimal zu berechnen würde genau die fertigen Bibliotheken bestrafen, zu deren Schutz die Unterscheidung existiert.
Befunde multiplizieren den Gesundheitsindex: 85% gefährdet, 60% wahrscheinlich verwaist mit einer Obergrenze Gefährdet von 49, 40% erklärt mit einer Obergrenze Kritisch von 29. Erklärt ist die zitierte eigene Aussage der Betreuung statt einer Folgerung — das Repository ist archiviert, oder jedes Paket, das es veröffentlicht, ist als veraltet markiert oder zurückgezogen. Repositories, die nicht bewertet werden können, lesen sich als nicht verifiziert und werden nicht abgewertet. Siehe Verwaisung.
Vergleichbarkeit: Werte können gegenüber 1.10.0 nur fallen, und nur bei Repositories, bei denen eine Dürre durch unerfüllte Pflichten erhärtet wird. Stille, gut gepflegte Projekte sind konstruktionsbedingt nicht betroffen.
1.10.0 — 2026-07-21
Als schädliche Pakete gemeldete Abhängigkeiten werden zu einem eigenen sicherheitsbezogenen Negativbefund, getrennt von Schwachstellen-Advisories.
Die Belege trafen ohnehin schon ein. OSV.dev liefert den OpenSSF-Korpus schädlicher Pakete neben gewöhnlichen Advisories aus, auf derselben Abfrage, die dieses Register bereits stellte — doch die Meldung eines schädlichen Pakets trägt weder eine Schweregradangabe noch eine korrigierte Version, fiel also auf „unbekannter Schweregrad“ durch und wurde wie eine moderate Schwachstelle bewertet. Ein als Schadsoftware befundenes Paket zählte etwas weniger als ein durchschnittlicher CVE.
Schädliche Pakete werden nun aus den Advisory-Befunden entfernt und nach eigenen Maßstäben bewertet: ein Multiplikator von 35% auf die Sicherheitslage und auf den gewichteten Gesundheitsindex, mit einer Obergrenze Kritisch von 29 auf beiden. Das ist eine Stufe strenger als die Obergrenze für Hochrisikojurisdiktionen, denn eine schädliche Abhängigkeit ist eine bestätigte Kompromittierung und keine Exposition gegenüber einem Risiko. Direkte und indirekte Abhängigkeiten zählen gleich — eine beim Installieren ausgeführte Nutzlast läuft in jeder Tiefe des aufgelösten Graphen.
Der Befund dürfte selten sein: Vor der Freigabe über eine Stichprobe von 300 Repositories mit 46.889 aufgelösten Abhängigkeiten laufen gelassen, fand er nichts. Registries entfernen schädliche Pakete binnen Tagen, sodass eine Lock-Datei, die noch zu einem auflöst, ungewöhnlich ist. Siehe schädliche Abhängigkeiten.
Vergleichbarkeit: unverändert für jedes Repository ohne schädliche Abhängigkeit, also für nahezu alle. Wo eine gefunden wird, sind Sicherheit und Gesundheitsindex mit keiner früheren Version vergleichbar.
1.9.0 — 2026-07-21
Der in 1.6.0 eingeführte Faktor für menschliche Autorschaft schlägt bei Projekten, die schlicht gut automatisieren, nicht mehr an.
Starke Automatisierung für sich genommen erwies sich als schlechtes Signal. Unter den Repositories, in denen Maschinen den Großteil des Commit-Aufkommens verfassen, waren die gesündesten allein am Anteil nicht von den aufgegebenen zu unterscheiden: Ein Projekt mit 59.000 Stars führt rund drei Viertel seiner Commits über einen Abhängigkeits-Bot und hatte vor zwei Tagen einen menschlichen Commit, und eine Paket-Registry, deren ganzer Zweck automatisierte Versionsanhebungen sind, liegt bei 93%. Beide wurden abgewertet.
Der Abschlag setzt nun eine zweite Bedingung voraus: Die Maschinen müssen zudem seit mehr als 90 Tagen allein committet haben. Der Abstand wird innerhalb des erfassten Commit-Fensters gemessen und nicht gegen die Uhr, sodass ein gespeicherter Bericht stets zum selben Wert neu bewertet wird. Repositories mit einem jüngeren menschlichen Commit sind bei keinem Automatisierungsgrad mehr betroffen; wirklich von Automatisierung getragene Projekte behalten ihren Abschlag.
Vergleichbarkeit: Werte können gegenüber 1.8.0 nur steigen, und nur in der Vitalität.
1.8.0 — 2026-07-21
Ein Signal wird zurückgezogen. Der Ausschlag vor Substanz der Wachstumsauthentizität beanspruchte, dass ein Schub, der vor dem ersten Release eines Projekts eintraf, ein Beleg für irgendetwas sei. Gemessen an 795 gewöhnlichen Repositories, schlug er in jedem einzelnen der fünf Befunde an, die die Richtlinie erzeugte — und jeder einzelne dieser fünf war ein gewöhnlicher Launch. Veröffentlichen, Aufmerksamkeit gewinnen, später ein Release herausgeben: So arbeiten Projekte.
Der Vergleich war in einer zweiten Hinsicht unsauber. Die Release-Liste, die ein Bericht führt, ist auf ihre 100 neuesten Einträge begrenzt; bei jedem Projekt jenseits dieser Grenze ist der früheste Eintrag daher nicht sein erstes Release, und jeder Schub scheint ihm vorauszugehen.
Was an seine Stelle tritt, keine Releases veröffentlicht, behält nur den absoluten Fall: Das Projekt hat überhaupt nie ein Release veröffentlicht. Es ist bewusst schwächer und erhärtet, statt zu entscheiden. Die Befunde in der gewöhnlichen Grundgesamtheit gehen auf null zurück, und beide bestätigten Befunde in der Evaluationsstichprobe bleiben bestehen.
Eine veröffentlichte Methodik, die ein Signal nicht zurückziehen kann, sobald sie es nicht mehr vertreten kann, ist keine Methodik. Dafür ist die Versionshistorie da.
1.7.0 — 2026-07-21
Wachstumsauthentizität erhält ein fünftes Signal, die Star-Konzentration: Die fünf stärksten Tage vereinen 80% oder mehr aller vom Scan erfassten Stars.
Ergänzt wurde es nach der ersten Auswertung der Richtlinie im Live-Betrieb, die sie als präzise, aber nahezu blind auswies — über 714 gewöhnliche Repositories hinweg markierte sie keines, und über 45 Repositories, die nach der Form gekaufter Aufmerksamkeit ausgewählt wurden, markierte sie eines. Der Schwellwert ist am Datenbestand abgelesen und nicht vorab gewählt: Unter 502 gewöhnlichen Repositories im Band von 100 bis 1.500 Stars entfallen im Median 6,9% der Stars auf die fünf stärksten Tage, und keines erreichte 80%.
Das Signal erhärtet einen Schub; es entscheidet nie für sich allein. Ein legitimes, ankündigungsgetriebenes Release nähert sich derselben Form — die Veröffentlichung eines Forschungsmodells wurde mit 73,7% gemessen —, und ein Signal, das beides nicht auseinanderhalten kann, darf nicht allein entscheiden.
Werte können unter dieser Änderung nur fallen, und nur bei Repositories, die ohnehin bereits einen Schub zeigten. Sonst bewegt sich nichts.
1.6.0 — 2026-07-21
Eingangsdaten, die sich aufblähen lassen, zählen nicht länger zum Nennwert.
Ergänzt um Wachstumsauthentizität. Der für jeden Bericht erhobene Tagesverlauf von Stars und Forks wird nun auf Wachstum gelesen, dessen Form organische Aufmerksamkeit nicht hervorbringt, und die Richtlinie zu unorganischem Wachstum wertet die Komponenten Stars und Forks der Popularität um 40% bei einem bestätigten Fenster und um 70% bei mehreren ab. Ein Schub allein ist nie ein Befund: Eine Bestätigung erfordert mindestens zwei unabhängige erhärtende Signale, sodass Launches und Titelseiten-Tage sich als organisch lesen. Repositories, deren erhobener Verlauf die Frage nicht beantworten kann, lesen sich als nicht verifiziert und werden nicht abgewertet. Die Richtlinie trägt kein additives Gewicht, ein sauberer Verlauf kann einen Wert also nie erhöhen.
Entwicklungsaktivität erhält einen Faktor für den menschlichen Anteil an der Autorschaft über ihre Komponenten Commit-Rhythmus und Commit-Volumen. Ein Projekt, das ausschließlich von den eigenen Robotern getragen wird, liest sich nicht länger als aktiv entwickelt; die volle Punktzahl gilt ab einem menschlichen Anteil von 40% aufwärts, sodass umfangreiche, aber echte Automatisierung unberührt bleibt. Maintainer-Resilienz zählt nun ausschließlich Menschen — Automatisierungskonten wurden zuvor unter die Maintainer eines Projekts gereiht, was ausgerechnet die Projekte begünstigte, die am meisten automatisieren.
Bestehende Werte bleiben vergleichbar, ausgenommen bei Community & Verbreitung für Repositories mit einem bestätigten Wachstumsbefund sowie bei Vitalität und Nachhaltigkeit & Governance für Repositories, deren Liste der Beitragenden weitgehend aus Automatisierung besteht. Werte können unter diesen Änderungen nur fallen, nie steigen.
1.5.0 — 2026-07-20
Ergänzt um Abhängigkeits-Advisories. Der aufgelöste Abhängigkeitssatz, der ohnehin für jeden Bericht erhoben wird – direkte Abhängigkeiten plus transitive Hülle –, wird nun mit der Advisory-Datenbank OSV abgeglichen; betroffene Pakete werden mit ihrem Schweregrad und der Version ausgewiesen, in der das jeweilige Problem behoben wurde.
Sicherheit wird zum gewichteten Mittel aus Sicherheitslage mit 80% und der neuen Metrik mit 20%. Der Multiplikator der Richtlinie für Hochrisikojurisdiktionen bleibt unverändert: er gilt weiterhin für die Sicherheitslage und für den gewichteten Gesamtwert und trägt kein eigenes additives Gewicht.
Die neue Metrik wird ausgeschlossen und das verbleibende Gewicht renormalisiert, sobald der Abhängigkeitsgraph oder die Advisory-Abfrage nicht verfügbar war – kein Repository wird dafür bestraft, dass sein Abhängigkeitsgraph abgeschaltet ist. Bestehende Werte bleiben vergleichbar, außer bei Sicherheit: jedes Repository mit Abhängigkeitsgraph wird nun anhand von Belegen bewertet, die zuvor nicht berücksichtigt wurden.
1.4.0 — 2026-07-19
Neu ist die Exposition gegenüber Hochrisikojurisdiktionen für eindeutige selbst veröffentlichte Standorte in Russland, Iran oder Nordkorea. Hierarchie-Multiplikator: Inhaber 20%, Top-Contributor 50%, öffentliche Organisationszugehörigkeit 75%. Ein Treffer multipliziert und begrenzt Sicherheitslage und nach der Gewichtung den Gesamtwert auf 49. Sicherheit spiegelt die angepasste Lage ohne doppelte Multiplikation. Fehlende, mehrdeutige oder trefferfreie Daten werten nicht. Das Signal priorisiert eine vertiefte Prüfung; es bestimmt weder Nationalität, Sanktionsstatus, Absicht noch persönliche Vertrauenswürdigkeit.
1.3.0 — 2026-07-18
Das Lizenzsignal der Community-Gesundheit wurde zu einer dreistufigen Abstufung — Standard, eigen oder keine — und ersetzt damit eine einzelne Vorhanden/Fehlend-Prüfung. Ein Repository, dessen Lizenzdatei existiert, deren Text aber keine anerkannte Lizenz ist, erhält nun drei Viertel des Lizenzgewichts statt entweder der vollen Anrechnung oder gar keiner.
Auch die Erkennung hat sich geändert: Der Zustand wird aus allen drei Lizenzquellen gemeinsam aufgelöst (den Lizenz-Metadaten des Repositorys, dem Community-Profil von GitHub und dem License-Check der Scorecard), statt allein der Scorecard den Vorrang zu geben. Die Präsenz ist ein logisches ODER, sodass eine Datei zählt, die auch nur eine einzige Quelle erkennt. Die Quellen weichen bei rund 1% der Repositories voneinander ab.
Eigene Lizenzen wurden bereits vor dieser Version geringfügig niedriger bewertet als Standardlizenzen, weil Scorecard sie mit 9 von 10 statt mit 10 bewertet. Dieser Abstand war vom Werkzeug übernommen und nicht als Position ausgesprochen; er ist nun bewusst gesetzt und dokumentiert.
Vergleichbarkeit: Bestehende Ergebnisse wurden unter 1.3.0 aus den in jedem Bericht bereits gespeicherten Daten neu berechnet — kein Repository wurde erneut gescannt, sodass sich nichts aus einem anderen Grund als dieser Änderung bewegt hat. Die Bewegung ist gering: Die Lizenz-Zeile trägt 22,5 von 100 Punkten innerhalb der Community-Gesundheit, die ihrerseits 35% von Community & Verbreitung ausmacht, was wiederum 18% des Index sind.
1.2.0 — 2026-07-14
Registry-Adapter für veröffentlichte Pakete wurden für Go (den Modul-Proxy), Maven Central und NuGet hinzugefügt, und die PyPI-Paketidentifikation wurde auf ältere setup.py-Manifeste erweitert. Repositories, die in diesen Ökosystemen veröffentlichen, tragen nun Registry-Evidenz in der Paketpflege — Aktualität der Veröffentlichungen, Versionshistorie, Deprecation-Status — und NuGet speist zusätzlich über die Gesamtzahl aller Downloads die Ökosystem-Verbreitung. Go und Maven Central veröffentlichen keinerlei Download-Statistiken und liefern daher kein Verbreitungssignal. Keine Formeln oder Gewichte wurden geändert — nur, für welche Repositories Registry-Evidenz verfügbar ist.
1.1.0 — 2026-07-14
Community-Gesundheit erkennt eine Lizenz nun einmal. Zuvor enthielt sie zwei überlappende Lizenzkomponenten — ein Flag aus dem GitHub-Community-Profil und eine separate License-Karte geteilter Evidenz. Diese sind zu einer einzigen License-Zeile zusammengeführt, die über den License-Check der OpenSSF Scorecard erkannt wird; das Community-Profil-Flag bleibt nur als Fallback für Repositories ohne Scorecard erhalten. Scorecards eigener License-Check bleibt eine vollwertige Komponente der Sicherheitslage. Die Zusammenführung beseitigt Doppelzählung und folgt bei Abweichungen der beiden Quellen der zuverlässigeren Erkennung durch Scorecard. Dieses Release ändert betroffene community_health-Werte; Berichte bleiben über ihre verzeichnete metrics_version reproduzierbar.
1.0.0 — 2026-07-13
OpenSSF-Scorecard-Checks liefern nun geteilte Evidenz, wo eine Sicherheitspraktik zugleich eine andere Gesundheitsdimension belegt. Scorecard bleibt in der Sicherheitslage vollständig risikogewichtet; sieben ausgewählte Checks erhalten zusätzlich kleine, dokumentierte Gewichte in ihren Zielmetriken: Maintained, Signed-Releases, Contributors, Code-Review, License, CI-Tests und Pinned-Dependencies.
Dies ist beabsichtigter kategorienübergreifender Einfluss, keine Wiederverwendung der Sicherheitsrisiko-Gewichte von Scorecard. Ein als n/a gemeldeter Check oder nicht verfügbare Scorecard-Daten werden aus der Zielmetrik ausgeschlossen, und die verbleibenden Komponenten werden renormalisiert. Dieses Release ändert betroffene Repository-Werte; Berichte bleiben über ihre verzeichnete metrics_version reproduzierbar.
0.9.0 — 2026-07-07
Der Fallback der Sicherheitslage behandelt eine fehlende Abhängigkeits-Lockdatei bei veröffentlichten Bibliotheken nicht mehr als Mangel. Lockdateien sind eine Praxis auf Anwendungsebene; viele Bibliotheken und Gems lassen sie zu Recht weg. Für diese Repositories wird die Fallback-Komponente nun ausgeschlossen, und die verbleibenden Komponenten renormalisieren. Der OpenSSF-Scorecard-Pfad blieb unverändert.
0.8.0 — 2026-06-30
Die Kategorie KI-Bereitschaft mit vier Metriken hinzugefügt (Agentenkontext, Verifikationsschleife, Code-Lesbarkeit, Schnittstellen), die bewerten, ob ein Repository verlässliche KI-gestützte Entwicklung unterstützt. Die Kategorie trägt das Gewicht 0,0: Sie ist ein unabhängiges, additives Badge und ändert den gesamten Gesundheitsindex nie. Bestehende Repository-Formeln blieben unverändert.
0.7.0 — 2026-06-20
Unterstützte Ökosysteme erweitert. Ökosystem-Verbreitung greift auf die Gesamtzahl aller Downloads zurück, wenn eine Registry keine Monatszahl veröffentlicht (RubyGems), sodass Ruby- und Hex-Pakete nun Verbreitungswerte erhalten. Registry-Adapter für RubyGems und Hex hinzugefügt; das Parsen deklarierter Abhängigkeiten auf Go, Maven, RubyGems, NuGet und Hex erweitert. Siehe unterstützte Ökosysteme.
0.6.0 — 2026-06-09
Sicherheitslage neu aufgebaut auf der OpenSSF Scorecard: werkzeugneutrale, risikogewichtete Checks, die Projekte nicht mehr für Tooling außerhalb von GitHub bestrafen; ergebnislose Checks werden ausgeschlossen statt als null gewertet. Grobe Dateibaum-Checks bleiben als Fallback erhalten. Nur die Kategorie Sicherheit betroffen.
0.5.0 — 2026-05-29
Paket-Ökosystem-Metriken hinzugefügt: Ökosystem-Verbreitung (Registry-Downloads) in Community & Verbreitung und Paketpflege (Aktualität der Veröffentlichungen, Deprecation) in Nachhaltigkeit & Governance. Beide sind null für Repositories, die kein Paket veröffentlichen. Innere Kategoriegewichte neu austariert; Kategoriegewichte und übrige Formeln unverändert.
0.4.0 — 2026-05-18
Metriken in fünf gewichtete Kategorien mit aggregierten Werten neu gruppiert. Vier neue Repository-Metriken: Release-Disziplin, Popularität, Trägerschaft und Dokumentation. activity umbenannt in Entwicklungsaktivität. Der Gesamtindex aggregiert nun Kategorien statt einzelner Metriken.
0.3.0 — 2026-05-06
Organisationsmetriken hinzugefügt — Profilvollständigkeit, Portfolio-Aktivität, Community-Reichweite und ein Organisations-Gesamtwert (siehe Organisationsbewertung). Repository-Formeln unverändert.
0.2.0 — 2026-04-25
Ergebnisse je Komponente zu jeder Metrik hinzugefügt, sodass ein Bericht genau zeigt, welche Kriterien erfüllt, teilweise erfüllt oder ausgeschlossen wurden. Formeln, Gewichte und Stufen-Schwellwerte unverändert gegenüber 0.1.0.
0.1.0 — 2026-04-15
Erste Methodik.
Was Versionierung garantiert
- Reproduzierbarkeit — ein Bericht und seine verzeichnete Version bestimmen vollständig, wie jeder Wert berechnet wurde.
- Vergleichbarkeit — zwei unter derselben Version geprüfte Repositories werden nach identischen Regeln gemessen.
- Rechenschaft — Methodikänderungen sind öffentlich, datiert und begründet; es gibt keine stillen Anpassungen.
Verwandt: der Gesundheitsindex · Bewertungsstufen · Scan-Konfiguration