Guides

Task-shaped walkthroughs: each one starts from something you are trying to do and ends with it done. The system documentation is the other half, explaining how Watchdog works rather than what to do with it.

If you are starting from scratch, read them in this order: connect a repo and read the first baseline, then hand a finding to whoever fixes it, then set your cadence.

From code host to your first baseline
Connect GitHub, GitLab, Bitbucket or Azure DevOps read-only and read the result: what the first number means, and what it does not.

From finding to fix, by hand or by agent
How to hand a finding to whoever fixes it, a colleague or a coding agent, with enough context that they do not have to re-derive it.

Set your survey cadence, and the daily watch
Code rots even when no one commits, so a scheduled survey and a daily security watch answer different questions.

Architecture drawn from the code
C4 containers, boundaries and coupling, derived rather than declared.

Security is not a CVE list
What a repository-level security read adds to dependency scanning.

Which gate to add first
Sequencing CI checks by what the measurement says, not by what is easiest to switch on.

Gate your Backstage scorecards on the CAI
Wire the verdict endpoint into Soundcheck, Cortex or OpsLevel, so tech-health tracks stand on measured code instead of self-declared checks.

Answers for your security reviewer
Read-only as a design principle: what a security reviewer will ask, and the answers, each with a way to check it.

The Cyber Resilience Act, and what a survey can evidence
Which CRA Annex I obligations a codebase survey can establish, and which half only a named person can attest.