How Watchdog grades your code.

The score is worked out by fixed rules that are published in advance, never by an AI model's opinion. When your score moves, it is because your code, the rules or the known security risks changed, and the survey shows which.

A product written in several languages is measured as one product, by the same rules throughout, so you get one score that means the same whatever the code is written in. When Watchdog adds a new language, the rules stay the same, so your existing scores don't move.

Every rule is published before anything is scored, and every survey carries the evidence behind its score. The program that turns that evidence into the number is open source, so you can work the score out again yourself.

Every survey measures everything that applies to your code, including the free first report. What you pay for is how much code is surveyed and how often, never how deep a survey goes.

How easy the code is to read and to change safely. This grade looks at how tangled the logic is, classes that try to do too much, code copied instead of shared, and work left unfinished: stubs that look complete but do nothing, dead code and "fix later" notes. It also catches a long list of small traps that break software quietly, such as errors that are caught and then ignored. Code that is hard to read is slow and risky to change, so every future change costs more than it should.

Whether the structure holds up as the product grows. This grade looks at how the parts depend on each other, whether those dependencies point the right way and avoid loops, whether each part has one clear job, and whether the boundaries your design intends are kept in the code. It also reads the history for files that keep changing together with no visible link between them, a sign that a boundary sits in the wrong place. When the structure is weak, a change in one place ripples into many others.

How well the project explains and looks after itself. This grade looks at the documentation, the design decisions your team has written down and whether the code still follows them, whether names are clear and consistent, and whether comments explain why rather than repeat what. It also reads the project's history: files that change often and are hard to read, parts only one person understands, and code nobody has worked on for so long that the knowledge of it has faded. This is what decides whether a new developer, or a new supplier, can take over.

Whether the product is ready to run in production and to change without breaking. This grade looks at the tests: how much of the code they exercise, whether they actually check results, and whether they pass reliably. It also looks at the automated checks every change must pass, whether problems can be seen once the product is running, how releases are rolled out and rolled back, backups and disaster recovery, and the libraries the product depends on: how up to date they are, whether their licences fit, and whether any passwords or keys have been left in the code.

How well the product is protected, and how it handles personal data. This grade looks for passwords and keys committed at any point in the history, libraries with publicly known vulnerabilities (CVEs) or published as malicious, security weaknesses in your own code (found by static analysis, SAST), unsafe settings in container and cloud configuration, and platforms that no longer receive security updates. On the compliance side it checks how personal data is protected: encryption, access control, audit trails, how long data is kept, and whether people can have their data exported or erased as the GDPR requires.

Whether the code protects the rules your business depends on. It applies when your code is built around a model of the business (domain-driven design, DDD). This grade catches business objects that just hold data for other code to change instead of enforcing their own rules; objects that can be created in a state their rules forbid; the same business rule decided in several places; and business logic mixed with database and web code. It checks that each group of objects that must stay consistent (an aggregate) is saved as one unit, one group per change, and refers to the others only by their ID.

Whether the parts of your system can rely on the messages they send each other. It applies when parts of your system communicate by sending messages or events rather than calling each other directly. This grade checks that a change and the message announcing it are saved together (the outbox pattern), so a crash halfway through can't keep one and lose the other. It also checks that each instruction (a command) has a single owner, with news that several parts need to hear sent as an event. It catches code that handles a message by waiting on a call to another service, which makes it depend on that service being available and fast.

Whether the stored history your system is built on can be trusted. It applies when your system keeps every change as a permanent record of events instead of overwriting the current state. This grade checks that events are defined so they can't be changed once recorded, and that replaying them always rebuilds exactly the same state, with no clock readings, random values or outside calls mixed in. It flags personal data written into records that can never be deleted, unless it is encrypted in a way that lets it be made unreadable on request (crypto-shredding), because the GDPR gives people the right to have their data erased.

Whether your interface is built so that everyone can use it, including people who can't see the screen or can't use a mouse. It applies when your code includes a web interface. This grade checks for text alternatives on images and captions on video, labels on forms and buttons, a clear page structure, keyboard access to everything, enough colour contrast, respect for people who switch off animation, correct use of the attributes screen readers rely on (ARIA), and automatic accessibility tests in your build. Because it reads the code, it covers the parts of the accessibility guidelines (WCAG) that can be checked there, and shows how ready the interface is rather than certifying it.

Whether your code is written and measured with speed in mind. It applies when your product's design calls for it. Benchmarks that measure the code's speed as it changes, and code written to use memory sparingly, for example by working on data in place instead of copying it, earn credit where they are present and cost nothing where they are absent. The grade marks down code that sits blocked while it waits for other work to finish, which wastes capacity and can make the program hang.

The lenses don't count equally. The rules set how much each lens counts and publish it with every version, so you can see what each lens contributed to your score. That is also why fixing a problem in one lens can move your score more than fixing a similar problem in another.

A product written in several languages is surveyed as one product, not scored one language at a time and averaged. Every file is measured under the same rules and counted in the same lenses, so a score of 74 means the same thing whatever the code is written in. When Watchdog adds a new language, the rules stay the same, so the scores you already have don't move.

Some lenses can be measured more fully in some languages than in others. Where a lens can't be measured properly, the survey marks it as not measured and gives the reason, and its share of the score moves to the lenses that could be measured, just as it does for a lens that doesn't apply. The language you chose never lowers your score, and a gap in what could be measured never counts as a zero.

Some measurements come from the history of your code rather than from the files as they are today: files that change often and are hard to read (hotspots), parts that only one person understands (bus factor), code nobody has worked on for so long that the knowledge of it has faded (knowledge freshness), and files that keep changing together with no visible link between them (change coupling). They are measured by the same fixed rules and count towards the same score as everything else, because they show things that reading today's files can't.

A lens in the lowest band, Critical, limits the whole score, however well the other lenses do. The stronger lenses still count and still show in the number, but they can't make up for the one that is failing, so a serious problem in one place always shows in the score.

A minimum score in an agreement can be checked lens by lens. A minimum of 80 means every lens that always counts is Strong or better and no lens is Critical, and that meaning is fixed when the contract is written, so both sides know what the number stands for.

A language is added only after a set of real projects written in it has been surveyed and the findings have held up when checked. Its measurements are tuned on code in that language alone, never on another language's, even when two languages look alike. The surveys published on this site are open to read, so you can judge the findings for yourself on a project you already know.

You can dispute any finding that counts towards your score and give your reason, and a person at Watchdog reviews it and decides. A dispute never changes your score or removes the finding. If the finding was wrong, the measurement itself is corrected, and the case is added to its tests to stop the same mistake from happening again. If the dispute is declined, the finding keeps a note explaining why it stands, and that note is the answer to anyone who raises the same point again.

Each survey comes with a list of what to fix, ranked by how much each item is expected to raise your score for the work it takes. The score weighs each kind of problem by how widespread it is, so a single stub that looks finished but does nothing barely changes it, while the same problem repeated across the code does.

A long list of findings doesn't prove a survey was thorough, and a short one doesn't prove the code is clean, because it may only mean that fewer measurements could run. That is why the report states how many of the measurements that apply to your code returned a result, and marks the rest not measured, with the reason.

A function called CalculateTax that takes an order and always returns 0 compiles and can pass its tests, yet no order is ever charged tax. The survey recognises these placeholders (stubs) by how the code is built rather than by what it is called: functions that only report that they haven't been written yet, functions that take inputs but always return the same value, functions marked as waiting for slower work that never wait for anything, branches that can never run, and classes whose functions are mostly placeholders.

A test that runs the checkout code but never checks the total passes whether the total is right or wrong, and the measure of how much code the tests run (coverage) still counts that code as tested. The survey looks for tests that check no result, and for tests that are switched off but still make the test suite look bigger than it is.

When a payment fails inside code that catches the error and then does nothing with it, the program carries on as if nothing went wrong: no error message, no log entry, no second attempt. The survey finds errors that are caught and ignored, and errors passed on in a way that loses the record of where they started (the stack trace), which makes the cause harder to find.

A comment that says "TODO: check the input" marks work someone knew was missing. The survey counts these notes (TODO, FIXME and HACK), warnings that have been switched off in bulk, code that has been commented out, and code that nothing uses. Each one is small, but together they count towards the score, so you can see how much known work is waiting and whether it is getting smaller.

When the same block of code is pasted into several places, a bug fixed in one copy stays in the others, and every change has to be made more than once. Watchdog finds blocks that are identical or nearly identical and scores them by how much of your code they make up. Code generated by tools is left out, because that repetition comes from the tool, not from your team.

Everything about how the rate is worked out is published before any measurement starts, so none of it can be adjusted to fit the result: what counts as noise, how the rate is calculated, how the projects are chosen and how findings are judged. The version of Watchdog under test stays fixed from start to finish, so the figure describes one exact version.

The projects for each round of measurement are picked by a random draw whose starting number (the seed) is generated rather than chosen, and announced before any results exist. The only condition for being in the draw is that a project can be surveyed without errors. Anyone can repeat the draw and get the same projects, which confirms that Watchdog didn't pick ones it does well on.

An AI model judges every finding against the code itself, following instructions anyone can read word for word. A sample of the findings is also judged by two people, separately and without seeing the model's answers, and at least one of them did not build Watchdog. If the model disagrees with them too often, the instructions are revised and every finding is judged again, and when a disagreement can't be settled, the finding counts as noise.

Before each round, Watchdog commits in public to publishing the result, whether it meets the target or misses it. The result comes with every finding, every judgement from the model and from the people, how often they agreed and the statistics, along with a small program anyone can use to recalculate the rate. The number of findings per thousand lines of code is published beside the rate, because a tool that reports almost nothing would look accurate without being useful.