Rubric rubric-2026.08.17
Every dimension in this rubric, and the lens it folds into.
This rubric is superseded but permanent. Any survey scored under it is still read against this catalogue, which is why the page stays. This catalogue carries 127 entries across 10 lenses: 42 dimensions published with a citable code (D1–D42), and 85 meta-dimensions that fold straight into a lens without being cited on a finding.
Published rubrics: rubric-2026.08.19 · rubric-2026.08.18 · rubric-2026.08.17 · rubric-2026.08.16 · rubric-2026.08.15 · rubric-2026.08.14 · rubric-2026.08.12
Lenses
Which lenses are always on, which light up with the architecture, and how they roll into one number is the standard itself: see the spec. Below is what this catalogue states — each lens and the dimensions that fold into it.
Code Health
7 coded dimensions
Architecture
8 coded dimensions
Maturity
8 coded dimensions
Readiness
7 coded dimensions
Security
12 coded dimensions
Domain Modelling
0 coded dimensions
Event-Driven
0 coded dimensions
Event Sourcing
0 coded dimensions
Accessibility
0 coded dimensions
Performance
0 coded dimensions
The D-family
A Watchdog SARIF finding carries its dimension code. Each row is verbatim from this catalogue: the code, the name, what it measures, the lens, and its evaluator — a deterministic tool or an advisory llm read.
- D1 — Cyclomatic Complexity — How tangled the control flow is — methods with many branches are hard to test and change. — Code Health — tool
- D2 — Cognitive Complexity — How hard the code is for a person to follow, beyond raw branching. — Code Health — tool
- D3 — God Classes — Over-large classes that try to do too much ("god classes"). — Code Health — tool
- D4 — Code Duplication — Copy-pasted code that should be shared instead. — Code Health — tool
- D5 — Coupling — Whether volatile projects sit underneath others that depend on them (so their churn ripples upward), and whether project dependencies form cycles. A widely-depended-on but stable shared/kernel project is healthy, not penalised. — Architecture — tool
- D6 — Cohesion (LCOM4) — Whether a class's methods are focused on a single responsibility. — Architecture — tool
- D7 — Architectural Integrity — Whether the code respects its intended layering / architecture rules. — Architecture — tool
- D8 — Code Coverage — How much of the code is actually exercised by tests. — Readiness — tool
- D9 — Test Distribution — Whether the test suite has a healthy mix of unit / integration / end-to-end tests. — Readiness — tool
- D10 — Test Quality — Whether the tests truly assert behaviour rather than just running the code. — Readiness — tool
- D11 — Test Reliability — Whether the tests pass reliably, with no flakiness. — Readiness — tool
- D12 — Dependency Hygiene — Whether dependencies are current, secure, and not bloated. — Readiness — tool
- D13 — Secret Scanning — Whether any secrets (keys, tokens, passwords) have leaked into the code. — Readiness — tool
- D14 — License Compliance — Whether the licenses of third-party packages are compatible with your policy. — Readiness — tool
- D15 — Churn × Complexity Hotspots — Files that change often and are also complex — the riskiest hotspots. — Maturity — tool
- D16 — Bus Factor — Whether knowledge is concentrated in too few people (the "bus factor"). — Maturity — tool
- D17 — Explicit Debt — Acknowledged debt left in the code — TODOs, dead code, suppressed warnings. — Code Health — tool
- D18 — Solution Shape — Whether the solution is laid out in a sensible, conventional structure. — Code Health — tool
- D19 — Documentation Quality — Whether the project's documentation is clear, complete, and useful. — Maturity — llm
- D20 — ADR Quality — Whether architecture decisions are recorded well (context, decision, consequences). — Maturity — llm
- D21 — Naming Consistency — Whether names — types, methods, variables — are clear and consistent. — Maturity — llm
- D22 — Internal API Consistency — Whether the internal API surface is consistent and coherent. — Architecture — llm
- D23 — Boundary Type-Coupling — Whether domain types (IDs, enums, value objects) leak across bounded-context boundaries. — Architecture — tool
- D24 — Comment Value — Whether comments are worth it — explaining WHY (valuable) rather than WHAT (redundant). — Maturity — llm
- D25 — ADR Conformance — Whether the code actually follows the decisions recorded in the project's ADRs. — Maturity — llm
- D26 — Project Cohesion — Whether each project is a focused, coherent unit rather than an oversized grab-bag. — Architecture — tool
- D27 — Navigability — How far you must trace to follow a call — low indirection and co-located slices read easier. — Architecture — tool
- D28 — Secrets (history) — Whether any secrets were ever committed — scanned across the full git history, not just now. — Security — tool
- D29 — Static Analysis (SAST) — Real static-analysis (SAST) findings — likely security bugs in the code, any language. — Security — tool
- D30 — Dependency Vulnerabilities — Whether any dependencies have known published vulnerabilities (CVEs), direct or transitive. — Security — tool
- D31 — IaC & Container Security — Whether Dockerfiles / Terraform / Kubernetes config follow security best practices. — Security — tool
- D32 — Data Compliance (PII/GDPR) — Likely personal-data (PII / GDPR) handling concerns — logging or storing data without safeguards. — Security — tool
- D33 — JS/npm Dependency Vulnerabilities — Whether JavaScript/npm dependencies have known published vulnerabilities (CVEs) — the npm ecosystem's biggest risk. — Security — tool
- D34 — Knowledge Freshness — Whether anyone still has living knowledge of each file, or it has been orphaned — last understood long ago by someone now gone quiet. The sibling of the bus factor: D16 asks who owns it, D34 asks whether anyone still knows it. — Maturity — tool
- D35 — Change Coupling — Whether files that change together actually belong together — pairs that repeatedly co-change in git history despite having no explicit code dependency, surfacing the hidden/logical coupling (and boundaries in the wrong place) a static scan can't see. — Architecture — tool
- D36 — Supply-chain Provenance & Signing — Whether the build pipeline provides supply-chain integrity — generated provenance/attestation, signed artifacts (cosign/sigstore), an SBOM, and pinned build actions. Presence of the configuration, not a runtime guarantee. — Security — tool
- D37 — Vulnerability-disclosure Policy — Whether the repository publishes a coordinated-vulnerability-disclosure policy (SECURITY.md or security.txt) with a reporting contact, so finders know how to report a vulnerability. Presence of a policy file with a contact, not whether the policy is adequate or honoured. — Security — tool
- D38 — OSV Dependency Vulnerabilities — Whether dependencies have known published vulnerabilities (CVEs) per the OSV database — npm and other lockfile ecosystems, parsed natively. Complements D33 (npm via trivy) and D30 (.NET via dotnet). — Security — tool
- D39 — IL Efficiency — IL Efficiency — Code Health — tool
- D40 — Network Egress Confinement — Whether Kubernetes workloads restrict network EGRESS with a NetworkPolicy (or Cilium policy), limiting where a compromised pod can send data or reach a command-and-control server. Presence of committed egress-restricting policy, not runtime enforcement. — Security — tool
- D41 — Kernel & Syscall Confinement — Whether Kubernetes workloads confine the kernel boundary — a seccomp profile (RuntimeDefault/Localhost) plus an AppArmor/SELinux mandatory-access-control layer — shrinking the syscall attack surface a container escape would use. Presence of committed confinement config, not runtime enforcement. — Security — tool
- D42 — Runtime Threat Enforcement — Whether the Kubernetes deployment wires runtime threat enforcement — a detection engine (Tetragon/Falco) and/or an admission-control policy gate (Kyverno / OPA Gatekeeper / PodSecurity). Presence of committed policy, not a runtime guarantee. — Security — tool
Verbatim from the open archive. This catalogue as JSON: rubric-2026.08.17/catalog. Rubrics are immutable — a score always names the one it was computed under, so read the version your survey cites, not necessarily the newest.