Dimensions & lenses

Ten lenses. Every dimension, its evaluator, its rubric version.

This is the canonical vocabulary of the standard — the lenses a survey is graded across and the dimensions inside them. Five lenses are always on; five light up when the architecture calls for them, and the weights re-normalise so absence never penalises.

How the lenses roll up Verify a survey

The ten lenses

Five always on. Five that light up with your architecture.

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.

Conditional

Domain Modelling

DDD tactical health — aggregates, value objects and the invariants your business rules depend on.

Conditional

Event-Driven

Messaging and integration discipline — outbox, async handlers and contract coupling.

Conditional

Event Sourcing

Event-store correctness — immutable events, deterministic folds and PII-in-events.

Conditional

Accessibility

Text alternatives, labels, keyboard semantics, ARIA and a11y enforcement.

Conditional

Performance

Benchmarks, allocation-aware APIs and async hygiene.

Each dimension inside a lens carries its evaluator (deterministic tool or advisory LLM read) and the rubric version it was scored under. A dimension that can't be measured returns not-measured, with the reason — never a phantom zero.

Behavioural & history dimensions

What the git history testifies to.

Four dimensions are mined from the repository's history and folded into the same deterministic score.

Hotspots

Churn × complexity — where change concentrates and where the next defect is most likely to land.

Bus factor

Key-person risk — which modules depend on a single contributor, and whose exit orphans the most significant code.

Knowledge freshness

Code that everyone who understood it has gone quiet on — knowledge decaying in place.

Change coupling

Files that repeatedly change together without a declared dependency — structure the code doesn't admit to.

Slop signatures

Hollow code, measured by shape — not authorship.

Code that looks finished and does nothing type-checks, reads as done, and sails past a line-level scanner. The standard names these shapes as measurable dimensions.

Signature	Code	What it measures
Stubs that look implemented	`IC1`	Confident names over `return 0;`, async methods that never await, skeleton types, dead branches.
Tests that assert nothing	`D10`	Green tests with no assertions; skipped tests dressed up as coverage.
Errors made invisible	`X3`	Empty catch blocks; bare rethrows that lose the stack trace.
Untracked debt & dead code	`D17`	TODO / FIXME / HACK, blanket suppressions, commented-out code, unreferenced symbols.
Copy-paste, never parameterised	`D4`	Type-aware near-duplicate density across the codebase.

Each signature feeds a per-file quality reading with diminishing returns and floors — the one-stub-versus-a-hundred-stubs distinction a flat rule can't make.

By shape, not authorship.The standard does not attempt stylometric "AI detection" — that is a credibility trap, and the claim is refused. A rushed human and an eager model produce the same finding and the same fix. The hollowness is what's measured, whoever typed it.

Watchdog measures; cai defines.The calibrated detectors that produce the evidence are the instrument's — proprietary to Watchdog. The vocabulary and the verdict are public: what is measured, how it folds, and what any number means are defined here.

The vocabulary is public. So is the fold.

How the CAI is computed Rubric versions

Reproduce any survey from its evidence → /verify