- Carbon (React)@carbon/react 1.70.0 · v11.70.0 · read on 1 November 202623out of 100Loose threads
- GitLab UI@gitlab/ui 114.1.0 · v114.1.0 · read on 1 November 202645out of 100Loose threads
Each audit reads one public source
Each audit reads one public source at a pinned release: the files in it, and nothing else. A low area score can mean that the evidence is not in the source we read, rather than a weakness of the system. Guidance on a documentation site, tokens kept in another package and ownership files at a repository root are examples. Each page says which areas this applies to.
Usage is not scored. Usage measures how product code uses a system, and these sources hold only the library. Patterns and pages are not scored either, because neither source holds pattern records that Loom can read.
The score is before, the plan is the proposed after
The score describes the system as it is in that release. The plan is the proposed after: the draft pull requests Loom would open for the system's owners to review, each naming the gaps it closes. The drafts were listed in a dry run and never opened. We do not claim an after score.
The method is open
Both audits use the open rubric: eight areas, each with its checks and weights. The audit is static analysis with no AI model, so the same source and the same engine commit give the same result. Each page names the source, the pin, the commit, the licence and the command, so anyone with Loom's code can run the audit again.
Why these two systems
Both are public, well documented and released under open licences (MIT and Apache 2.0) that allow reading and quoting them. We chose them as public sources, to test the audit on real systems that many teams know. Each audit stands on its own: the pages do not compare the two systems with each other or with Loom.