How Watchdog works

Watchdog 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.

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 "I know 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 — 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 GitHub App to your first baseline
• A finding is a work packet
• Code rots even when no one commits
• Architecture drawn from the code
• Read-only as a design principle
• Which gate to add first
• Security is not a CVE list