CAPABILITY SET

R50 Capabilities

The R50 number contract: security patterns, 348 implemented checks, 68 security patterns, 26 SafeFix, 21 runtime bridges, 24 external recipes.

See the Number Ledger Explore Catalog Distribution

THE R50 CAPABILITY SET

The engine's core numbers

The engine is read in three separate layers: detectable checks, security patterns, and the verification/action layers. These numbers do not measure the same thing; each shows a different function of the product.

348

Detectable checks

The layer the engine actually runs on files and code: 80 core and 268 granular checks.

Boundary: Not a catalog row count; one check can cover several catalog items.

Core checks

Covers the fundamentals: meta, canonical addresses, structured data, accessibility, security readiness and deployment hygiene.

268

Granular checks

Extends the core layer with finer fields, types, attributes and page contexts.

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.

SafeFix generators

Produces low-risk, reversible changes in a working copy and records changed files with rollback data.

Runtime verification bridges

Links results that cannot be measured from static files to independent tools such as PageSpeed and SSL Labs.

External action recipes

Turns steps required on DNS, CDN, hosting, Search Console and similar platforms into actionable instructions.

WORKING LAYER

348 checks: 80 core + 268 granular

Four-step bridge flow diagram. — The runtime bridge: four steps from static signal to independent measurement.

The ten-domain scoreboard: the full decision surface from security to delivery.

The four-class split: static, runtime, external and outside-automated-scope.

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.

The number contract — at a glance

WebTrustEngine engine contract: 348 detectable checks made of 80 core and 268 granular layers; security patterns, runtime bridges, fixers and action recipes are separate units and are never summed. — The same diagram ships as press-ready PNG/WebP in the Brand Center visuals.

80 + 268 How core and granular divide the work

Splitting the 348 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 268 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 348 on every run; if the number drifts, the release is not sealed.