How Assert works

Assert reads a codebase and returns a score you can check. This documentation explains what actually happens when we do that: what we fetch, where it runs, how it is measured, and what we promise about the result.

Recommended route if you are new: what a survey is, then how we measure, then the rubric contract, then where the code runs.

It is the reference for anyone who needs to understand the system without reading its source: the people who build and support it, colleagues answering a question, and anyone evaluating the product. It assumes no background beyond knowing what a code repository is.

This documentation describes the system from a deliberate height. It does not list the supported languages, the things we measure, or the current rubric version. It does not go into individual detectors, meaning the specific rules and thresholds that decide whether something is a finding.

The reason is stability. Those things change constantly: a language is added, a measurement is refined, a rubric is bumped, a detector is improved. Documentation that repeated them would be wrong within the week, and documentation that is sometimes wrong is worse than none, because you stop being able to tell which parts to trust. What is written here changes rarely, so it can be relied on.

For the detail underneath, the code and the configuration are the source, and they are always current by definition. Where a live list is genuinely useful, we point at the machine-readable version rather than copying it: the complete catalogue of what a rubric measures is published at codeassuranceindex.info/api/rubrics/<version>/catalog.

Why our own documentation is published. This is the documentation we write for ourselves, the same pages at the same altitude, whether or not anyone outside reads them. We publish it because we have chosen to be transparent about how we work: our prices, how the product actually operates, and how we establish that it measures accurately. Making the internal documentation public simply follows from that.

• Security and data handling, the detailed, formal account of storage, retention, encryption and subprocessors. Where the two overlap, that page is authoritative.

The guides are the practical companion to this documentation: this describes how the system works, the guides describe how to use it.

• From code host to your first baseline
• From finding to fix, by hand or by agent
• Set your survey cadence, and the daily watch
• Architecture drawn from the code
• Answers for your security reviewer
• Which gate to add first
• Gate your Backstage scorecards on the CAI
• Security is not a CVE list
• The Cyber Resilience Act, and the evidence Assert gives you
• The European Accessibility Act, and the evidence Assert gives you