2.033
Reference catalog items
Classifies signals from web quality, security, accessibility, structured data and related standards under one taxonomy.
Boundary: Not an automated check count.
THE R50 CAPABILITY SET
The core numbers of R50
R50 is read in three separate layers: the reference catalog, the implemented detection checks, and the verification/action layers. These numbers do not measure the same thing; each shows a different function of the product.
319
Implemented detectable checks
The layer the engine actually runs on files and code: 80 core and 239 granular checks.
Boundary: Not a catalog row count; one check can cover several catalog items.
80
Core checks
Covers the fundamentals: meta, canonical addresses, structured data, accessibility, security readiness and deployment hygiene.
239
Granular checks
Extends the core layer with finer fields, types, attributes and page contexts.
68
Security patterns
Scans source and configuration files for secret leaks, exposed files, risky client code and server-side security signals.
Boundary: Not active exploitation or a penetration test.
26
SafeFix generators
Produces low-risk, reversible changes in a working copy and records changed files with rollback data.
21
Runtime verification bridges
Links results that cannot be measured from static files to independent tools such as PageSpeed and SSL Labs.
24
External action recipes
Turns steps required on DNS, CDN, hosting, Search Console and similar platforms into actionable instructions.
Roadmap 0
No unclassified catalog items
Every catalog item is bound to a work class: implemented check, runtime verification, external action, conditional rule, manual verification or not-applicable.
Boundary: It does not mean everything is automated.
CATALOG STATUS MODEL
2,033 items across seven status classes
The catalog status matrix: class distribution of 2,033 items and zero open entries.
The catalog status model is the visible form of R50's evidence architecture. The goal is not to throw every signal into two crude buckets of 'done' or 'to-do', but to attach it to the artifact class that fits its nature. A header policy can be produced in a file; a TLS grade can only be measured live; a DMARC record can only be enabled in a DNS panel; a contrast decision usually needs a human eye.
ROADMAP=0 carries a specific meaning in this model: it does not mean everything was automated; it means everything was attached to the right artifact class. This nuance is deliberately preserved in public communication, because a misread 'zero open items' easily becomes an inflated claim.
The table below gives the R50 distribution of the 2.033-item catalog, the public meaning of each status and typical examples.
| Status | Count | Public meaning | Example |
|---|---|---|---|
| ENTEGRE | 1.258 | Signal functionally attached to working check/fix logic | title/meta/canonical/schema |
| RUNTIME-BRIDGE | 197 | Requires live tool or runtime verification | PageSpeed, SSL Labs, Observatory |
| EXTERNAL-RECIPE | 308 | Requires hosting/DNS/CDN/panel action | DMARC, DNSSEC, Cloudflare |
| CONDITIONAL-RULE | 214 | Valid when page type/sector applies | Product, Event, FAQ schema |
| MANUAL-VERIFICATION | 55 | Requires human/expert verification | some WCAG, legal claims, visual context |
| NOT-APPLICABLE | 1 | Not applicable in a static-site context | edge case |
| ROADMAP | 0 | No unclassified items remain | — |
| ROADMAP=0 It does not mean everything was automated; it means everything was attached to the right artifact class. |
|---|
Catalog Status Table
All 2,033 items bound to a class
| Class | Items | Description |
|---|---|---|
| INTEGRATED | 1,258 | working-check coverage |
| RUNTIME BRIDGE | 197 | verified via tools |
| EXTERNAL RECIPE | 308 | platform action by recipe |
| CONDITIONAL RULE | 214 | valid by context |
| MANUAL VERIFICATION | 55 | human judgment |
| NOT APPLICABLE | 1 | out of context |
| ROADMAP | 0 | nothing left open |
No guarantees — readiness, evidence and verification. Number contract: 2,033 reference catalog · 319 working checks.
The status matrix
Every catalog item sits in its correct artifact class: implemented, runtime-verified, external, conditional, expert-verified or not applicable.
WORKING LAYER
319 checks: 80 core + 239 granular
The ten-domain scoreboard: the full decision surface from security to delivery.
The four-class split: static, runtime, external and manual verification.
Each domain follows the same seven-part template: purpose, typical problems, what the engine checks, what it can fix, live verification, sample output and executive meaning.
Security Headers
The Security Headers domain examines the policy layer that tells modern browsers within which security boundaries to run the page. It is not a mere 'is the header present?' check; HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy must be handled in a way that fits the target site type.
Typical problems
- Headers absent or on default server values
- CSP conflicts with inline code and breaks the page
- HSTS present but wrong max-age/scope
- Double CSP (server + file) intersects and narrows policy
What the engine checks: The engine statically classifies header presence, value quality, in-site conflicts (inline code ↔ strict CSP) and the risk of clashing with an existing server policy.
What it can fix: In supported environments (.htaccess) it produces a secure baseline header set; if the site already has its own CSP it does not add a duplicate policy; it turns advice into a recipe.
Live verification: Whether headers actually apply live depends on hosting behaviour; verified post-deployment with SecurityHeaders and Mozilla Observatory.
| Sample indicator | Before | After |
|---|---|---|
| Header coverage | 3/9 | 9/9 |
| CSP conflict | present | none |
| HSTS | none | max-age + subdomains |
What the engine does: The engine statically classifies header presence, value quality, in-site conflicts (inline code ↔ strict CSP) and the risk of clashing with an existing server policy.
MANUAL VERIFICATION
55 items that require human judgement
55 catalog items are deliberately kept outside automated detection: content quality, legal wording and design decisions stay with human judgement.
What does ROADMAP = 0 mean?
Claim safety
The open roadmap is zero: every item sits in its correct artifact class today. That does not mean 'everything is automatic' — it means honest classification.
The number contract — at a glance
80 + 239 How core and granular divide the work
Splitting the 319 checks into two layers is not arbitrary. The 80 core checks are the backbone that runs on every site in every review: the header family, canonical structure, schema skeleton, delivery hygiene — the non-negotiable signals. The 239 granular checks deepen with context: multilingual structures, media variants, form and interaction surfaces — continuing where the core leaves off.
The practical consequence: a small site and a large corporate surface pass through the same backbone, while the granular layer opens only as far as needed. Every finding carries the layer it came from, so 'why did this check run?' is answered inside the report itself. The same three counters — CLI, quality gate and ledger — independently count 319 on every run; if the number drifts, the release is not sealed.
Quick answers
What is the catalog?
A map of the web-quality universe.
How many roadmap items?
0 — nothing left open.
Distribution?
INTEGRATED 1,258 · RUNTIME 197 · EXTERNAL 308 · CONDITIONAL 214 · MANUAL 55 · N/A 1.
Is every item bound?
Yes; implemented/runtime/external/conditional/manual/N-A.
Core vs granular?
80 core + 239 granular = 319.
What does it detect?
Static meta/SEO/a11y/schema/security/performance signals.
Does it produce fixes?
26 SafeFix generators make reversible fixes.
See the numbers in the document
The 46-page guide's appendices carry the number-origin ledger and every matrix.