A codebase survey on your team's cadence — not a CI gate
Is the codebase getting better? Now you can answer with a number.
Watchdog surveys your whole product on your team's cadence — every service, every language — and returns one reproducible 0–100 Codebase Assurance Index, with the trend on every lens and a ranked list of what to fix next. Run the same survey next sprint and the number tells you whether the work landed. A measurement, not an opinion.
Point us at your repo. Nothing to install, no CI step, no SDK, no config file in your tree — and we never open a PR. Sign in with GitHub · no card · C#, Java, TypeScript, Python, Go and more · the first full report on any repo is €0 — depth is never gated.
Every sprint
a full survey on your team's cadence — never a gate in the pipeline
Daily
a security watch on your dependencies, between surveys
10
lenses — 5 always on, 5 light up with your architecture
100%
reproducible — same commit, same rubric, same number
The loop
Survey. Fix. Prove it moved. Every sprint.
The survey runs on your cadence
The whole product, every service, every language. Ten lenses, most of them deterministic, all of them versioned. No CI job, no build hook, nothing in your repo — it runs on your team's sprint calendar, not on a commit.
You get a number and a direction
One 0–100 CAI, plus the trend on every lens since the last scan. Not a wall of warnings — a score you can watch, and the specific lenses that moved it. Down is as useful as up: you find out in days, not at the next incident.
Your agent gets a ranked list
Findings served over MCP to Claude Code, Copilot, Cursor or opencode — ranked by impact ÷ effort, each briefed with the rule that fired and the exact file and line. Your agent works what moves the score, not whatever came out first. The hand on the code stays yours: Watchdog is read-only and never opens a PR.
The next survey proves it
The fixes show up as movement on the same lenses, measured the same way. This is the part no linter gives you: evidence that the work you did actually changed the thing you were trying to change.
And every day in between. A security watch runs daily against your dependency graph — every ecosystem you ship, not just one. A new CVE in something you depend on, and you hear about it that day, not at the next survey.
The code that passes CI and does nothing
Your build is green. That's not the same as working.
Volume went up when the assistants arrived, and review capacity did not. What is landing compiles, type-checks and passes the gate — and some of it is hollow. Watchdog measures the hollowness directly, by the shape of the code. Shape carries across languages: a CalculateTax that returns 0 is the same finding in C#, Java, Python and Go.
IC1 — Stubs that look implemented
A method returning a constant under a confident name. An async that never waits. Empty types, dead branches. It compiles, it type-checks, it does nothing.
D10 — Tests that assert nothing
Passing tests with no assertion — xUnit, JUnit, pytest, RSpec, Jest and ExUnit alike. Coverage counts the file. It never asks whether the test checks a result.
X3 — Errors made invisible
An empty catch, a swallowed except: pass, an ignored error return, a rethrow that loses the stack trace. Everything passes. The failure disappears.
D17 — Untracked debt
TODO, FIXME, HACK, blanket suppressions, commented-out code, unreferenced symbols. Counted raw by other tools at best; scored here, and trended.
D4 — Copy-paste that was never parameterised
Near-duplicate blocks, detected with type awareness, scored by how much of the codebase they cover.
The composition of what you merged is scored too — the slop-vs-brilliant split — so "we're shipping faster" and "we're shipping worse" stop being the same sentence.
Not noise — findings
One finding, in full. From a real published survey.
Every claim above is checkable. These are live findings from real repositories whose owners chose to publish — the rule that fired, the file and the line, and a link to the whole survey. Nothing here is a mock-up: it is read from the public feed the moment you load the page.
Before you ask
Everything you're about to worry about.
Will it block my merge?
No. Watchdog is a survey you schedule, not a gate in your pipeline. There is no CI step to add and nothing that can fail a build. If it is down, your deploys do not care.
Will it touch my code?
No. Read-only by doctrine — it never opens a PR, never pushes a branch, never edits a file. It hands findings to your agent, under your review, in your workflow.
Is it going to be noise?
That is the failure mode we designed against. Detectors are tuned per language against real production code, so ordinary patterns — a shared base class, a Rails concern, a Spring proxy, an interface a façade has to implement — are not reported as faults. On the .NET corpus, tuned longest, the typical repository's findings are over 95% real; reference clean-architecture codebases exceed 99%.
What happens when it can't measure something?
It says so. A dimension that cannot be measured — coverage on a suite that will not run, a lens that does not go as deep in one language as another — returns not measured, with the reason, and the weights re-balance. Never a phantom 0.
Can I check the scoring?
Yes, all of it. Every dimension, weight and threshold is published at cai.canine.dev. The verdict is an open standard — the evidence engine that feeds it is ours, but you can audit what the number means, and re-run a scan and get the same number.
What if I want out?
Nothing to remove. No SDK, no config file in your tree, no build dependency. You stop scheduling surveys and it is gone. The reports you already have are still valid — they are signed, timestamped documents, not dashboard state that dies with the account.
The boundary
What Watchdog is - and isn't.
What it is not
- Not a CI scanner or linter
Never scores a line or blocks a merge. - Not a SAST / dataflow engine
Reads their signal; doesn't out-depth one. - Not a coding agent
Never edits, commits, pushes or opens a PR. - Not a certifier
Records the evidence; a named human signs.
What it is
- An independent surveyor
One altitude above your scanners. - One reproducible CAI
Signed, commit-pinned — re-runs to the same number. - A read-only oracle
Serves every finding to your agent over MCP. - A whole-system survey
Architecture, maturity, compliance & risk in one report - every language in the product, one verdict.
How we measure
Graded by the open CAI standard — across ten lenses.
Five lenses are always on. Five light up when your architecture warrants them — a DDD codebase gets measured on aggregates and bounded contexts; a CRUD service is not marked down for not having them. They light up with your architecture, not with your language: a domain model is read the same way in C#, Kotlin or Elixir, because the lens looks at how the code is organised, not at the syntax. Every finding lands on a file and a line. Every lens trends scan over scan. Every dimension links to its definition on cai.canine.dev.
Always on
Code health
Complexity, duplication, code shape and naming — how maintainable the code itself is.
Always on
Architecture
Module boundaries, coupling, cohesion and dependency direction — whether structure holds up as the repo grows.
Always on
Maturity
Docs, ADRs, comments and process signals — how well the project explains and governs itself.
Always on
Readiness
Tests, CI gates, observability, resilience and rollback — readiness to run in production.
Always on
Security & Compliance
Secrets, dependency CVEs, SAST and licence/PII posture — the deep-scan security lens.
Lights up with your architecture
Domain Modelling
DDD tactical health — aggregates, value objects and the invariants your business rules depend on.
Lights up with your architecture
Event-Driven
Messaging and integration discipline — outbox, async handlers and contract coupling.
Lights up with your architecture
Event Sourcing
Event-store correctness — immutable events, deterministic folds and PII-in-events.
Lights up with your architecture
Accessibility
Text alternatives, labels, keyboard semantics, ARIA and a11y enforcement.
Lights up with your architecture
Performance
Benchmarks, allocation-aware APIs and async hygiene.
The full vocabulary — every dimension, its evaluator and rubric version — lives on the open standard. Browse the catalog →
Artifacts
The documents you currently write by hand.
Every survey emits them, derived from the code and current because they were generated from the thing they describe — the architecture map, the SBOM and licence inventory, the CWE-tagged findings, the changelog, the ADR conformance check. They are signed and timestamped, which is what makes them usable outside engineering too: a customer's due diligence, a procurement review, or a NIS2 or DORA line item that would otherwise land on your afternoon.
A reproducible report
The CAI and every finding in a content-addressed PDF + JSON, pinned to a commit and a frozen rubric hash — re-runnable by either side.
Evidence you can share
Every scan is an Ed25519-signed, tamper-evident CAI package. Share it with a client or buyer — they get a free copy they can verify, and it can't be edited by whoever shares it.
An agent-ready fix list, over MCP
Every finding is a briefed task — the rule that fired, the file and line, the score-impact — served to your coding agent over Watchdog's Model Context Protocol server, ranked by impact ÷ effort. The next survey proves the number moved.
A standing inspection
A full survey on your team's sprint cadence, plus a daily security watch in between — your code rots even when nobody commits; the quiet months are watched, not skipped.
A changelog every survey
What moved since last time — CAI & per-lens deltas, findings resolved vs raised, features & fixes landed, added and removed API endpoints. A sprint-ready record, derived facts only.
Living documentation
A C4 architecture map, a CycloneDX SBOM + licence inventory, and ADR-conformance — derived from the code on every survey, current by construction. The architecture map covers the whole product: one diagram, even when the services are written in different languages.
Languages
One number, whatever your code is written in.
Watchdog started on .NET and still knows it best. It now surveys the rest of the languages real products are built from:
.NET - C#, F#, VB.NET JVM - Java, Kotlin, Scala Web - TypeScript, JavaScript Backend & cloud — Python, Go, Rust, PHP, Ruby Mobile - Swift, Dart Event-driven - Elixir, Erlang
The same ten lenses and the same rubric apply to all of them, so a score means the same thing wherever it comes from. If your product is a C# API, a TypeScript front end and a Go worker, you get one report and one number — not three tools and three answers that don't line up.
More languages are added over time. When one arrives, nothing about the score changes: the rubric stays as it is, and the reports you already have still mean what they said.
Don't see yours? Tell us what you work in.
Independent — and you don't have to trust us
Commissioned by one side. Trusted by both — because the method is open.
A survey is only worth something because the surveyor is independent and paid the same either way, *and* because you can check the work.
Structurally neutral
The same versioned rubric scores you whoever pays; pin it frozen for a contract. Watchdog builds nobody's software, never touches yours — and there are no success fees. We're paid to measure, never to make the number go up.
Open verdict, calibrated instrument
The CAI *verdict* is an open, reproducible standard — algorithm, lenses and rubric public, reference scorer open source. The evidence engine that feeds it is ours: tuned language by language against real production code, so it flags genuine problems and stays quiet on normal, idiomatic patterns — a .NET base class, a Rails concern, a Spring proxy. It's been tuned longest on .NET, and every language is held to the same tests.
Verify any number yourself
We publish the evidence behind a score. Take a survey, run the open scorer over its evidence, and you get the same number — or you've found a discrepancy.
Who it's for
Start where you stand. I'm a…
Pick the hat you're wearing — each page frames the survey for your situation.
Freelancer or solo dev
Prove my code to a client who can't read it — an independent score for the proposal and the hand-over. Single seat.
Engineering team
Catch the drift between sprints — a scheduled audit I can trend before it compounds. Never a PR gate.
Provider or consultancy
Prove my quality and win the bid — an independent number no slide deck can match.
Role hubs: Builders · Leads. Buying or appraising software, not building it? That's Assay's job → assay.canine.dev
The public record
Real reports, fully open — not a logo wall.
Every card below is a real repository whose owner chose to publish — the entire survey is open to read: every lens, every finding, and the exact rule each number was scored by. No cherry-picked mock-ups.
Trust
Your code never leaves your control.
EU data residency
Processed only on hardware we own in Denmark — no cloud provider in the path.
No third-party AI
The language model is self-hosted; your code is never sent to OpenAI, Anthropic or Google.
Source never persisted
Each scan clones, analyses, then deletes the working copy — and we never train on your code.
Read-only by doctrine
We measure and advise; we never commit, push, or edit your code.
How we operate
Read-only by doctrine. Honest about what a tool can claim.
Evidence you declare — certificates we don't sell
Compliance evidence with a gate you can't quietly pass.
A catalog of ten frameworks (WCAG 2.2, NIS2, DORA, SSDF, SLSA, OWASP ASVS and more). We measure the automatable slice and gate it: a control we caught failing can't be silently passed — overriding it is recorded, in full, in the artifact. You declare the rest, and a named person signs. We measure; you declare; we never certify.
Enterprise & regulated environments
Run the whole survey inside your own network.
Watchdog deploys self-hosted: your code never leaves your perimeter, the language model runs on your hardware, and the SOC 2 / data-residency question goes away. EU data residency, no third-party AI, source never persisted — on infrastructure you control.
You don't have to remove anything
Keep Sonar, keep Snyk, keep your linter, keep the IDE gate. Watchdog never re-scans the line — it works one level up, on the things a line-level tool structurally cannot see: whether the architecture is holding, whether the domain model still matches the code, whether the whole product is trending up or down. If a tool you already run answers a question better than we do, we say so. Where Watchdog fits →
Run one on a repo you already know.
Point it at something you understand well and check whether the findings match what you already believe about it. That is the only real test. The first full report on any repo is €0 — full depth, nothing gated.
Sign in with GitHub · no card · nothing installed · read-only.