Rubric rubric-2026.08.19
Every dimension in this rubric, and the lens it folds into.
This is the current rubric. Surveys scored today name this version. 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 — read natively from whatever lockfile the repository ships (Cargo, npm, Go, Python, Maven, RubyGems, …). D33 and D30 add ecosystem-specific scanners on top for npm and .NET. — 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.19/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.