What does R50 mean?
R stands for Release: R50 is WebTrustEngine's 50th release cycle. The number is not marketing — it is the address of an auditable change chain.
The release ledger
The strip below is how release discipline reads: each row stands for one release cycle, the change set sealed in that cycle and its verification summary. The ledger closes backwards; no published row is ever edited — corrections arrive as new rows. R50 is the fiftieth link in this chain: the number exists to address which claim was verified in which cycle. When a figure is questioned, the answer is given as 'which release, which evidence' — a ledger row, not a marketing line. The four-phase narrative on this page draws on the same ledger: the recorded steps from first review to a steady governance rhythm, each producing its own evidence file. The release number is therefore an evidence address, not a marketing calendar; every public sentence that mentions R50 points at the verification summary on the ledger's fiftieth row.
SHORT ANSWER
Why an R-number?
Every R cycle is a release whose scope, files and numbers are sealed. Content does not change while the name stays the same; when content changes, the manifest and checksums are regenerated. So the single word "R50" says: every file in this set is counted, every claim is tied to its source.
The core detection engine was frozen at an earlier cycle (R39) and has not been modified since; cycles R40-R50 matured not the engine but the public narrative, the evidence packages and the verification discipline. The public capability set therefore carries the name R50: engine fixed, narrative audited.
Release and change discipline
R-releases (R49, R50…) mark the engine's capability moments; each ships with patch notes, a test report and a count report. The frozen core is never altered between releases; new capability lands in a separate layer. Marketing documents carry the same discipline: every version has a CHANGELOG, QA report and checksums — R50, as, is part of that chain.
The public value of this discipline: any number, claim or screenshot can be verified against the evidence file of the release it belongs to; 'which version was that' ambiguity disappears.
CAPABILITY SET
A look at the engine's core numbers
The scope is read in three layers: 348 detectable checks (80 core + 268 granular), 68 security patterns, and the verification/action layers. Each number has its own defined scope and boundary.
TIMELINE
From R39 to R50
| Cycle | What happened? |
|---|---|
| R39 | Core engine frozen; detection logic unchanged since. |
| R40-R49 | Evidence package, claim safety and verification bridges matured. |
| R50 | Public capability set: guide, number contract, documents and brand assets sealed. |
NUMBER CONTRACT
Keeping the units apart
Core and granular layers are counted apart: 80 + 268 = 348 detectable checks. Security patterns, runtime bridges, fixers and recipes stay in their own units.
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 ratio is computed automatically by the built-in browser run.
The engine's measurable layers, and the public meaning of each unit, are given separately in the cards above.
CLAIM SAFETY
What it says, what it never says
Public statements follow a fixed claim discipline: what is proven is stated, and what is never promised stays out of the copy.
The claim-safety matrix is not just a marketing filter; it is the product's legal and ethical defence line. The left column shows what may be said, the middle what must not be, the right column why. The rule is simple: no unverifiable result is promised; readiness, evidence and the verification chain are.
| ✓ Safe phrase | ✗ Risky phrase | Why? |
|---|---|---|
| readiness | guaranteed compliance | Guarantee claim |
| verified post-deploy | passed live | Needs live testing |
| static security review | full pentest | Needs authorization + live testing |
| security patterns | automated checks | Number-inflation risk |
| SafeFix package | production-ready | Publish decision is separate |
| before/after internal score | full marks on all tools | Independent-tool result claim |
| AI-readability readiness | AI recommends us | No citation guarantee |
Decision Panel
MANIFEST CULTURE Manifest and checksum: a release's two signatures
What makes an R cycle 'sealed' shows up in two files. First the manifest: the name, count and role of every file in the package sits in one record; nobody can argue about whether a file 'was or wasn't there'. Second the checksum list: every file's SHA-256 is written down; a change of a single byte breaks the list.
This pair is not marketing decoration; it is an operating tool. When a vendor delivery, an archive copy or an audit sample is opened years later, it is verified with the same two questions: does the file count match the manifest, do the digests match the list? If both answers are yes, you hold the package exactly as it was produced. That is the real discipline behind the name R50 — and the site's Evidence Hub opens the same rule to every visitor.
FOUR PHASES Four phases of adoption
The managed service workflow: five steps from initial review to verification and reporting.
Phase 1 · Baseline (week 1)
Input is collected (ZIP/folder/authorized URL), Review runs, the 10-domain score and finding classification emerge. Output: the decision surface + suggested SafeFix scope + external-action list. No file changes in this phase.
Phase 2 · SafeFix (week 2)
Approved-scope low-risk fixes are applied on a working copy. Output: fixed ZIP + changed-file list + rollback manifest + before/after internal score. Approval-needing items wait on a separate list.
Phase 3 · Deploy-Verify (week 3)
The package is uploaded, caches purged, live headers and previews verified, the independent-tool pass runs. Output: the baseline-diff report + tool-bridge results. 'Produced' becomes 'working' here.
Phase 4 · Monitor (ongoing rhythm)
At the agreed cadence (monthly/quarterly) the live state is compared with baseline; drifts, new risks and external-action status are reported. The loop moves the web asset from 'project' to 'governed asset'.
| Note The timeline is representative; it scales with site size and scope components. |
|---|
GLOSSARY Five terms in five sentences
- Baseline — The starting snapshot Review produces; the reference for all later comparisons.
- SafeFix — The mode producing low-risk, reversible fix packages.
- Rollback manifest — The reversal document holding the backup dir plus changed/created file lists.
- Changed files — The full list of files SafeFix touched; the core of evidence.
- Evidence package — The delivery set of scores, file lists, recipes, QA and checksums.
- Runtime bridge — The bridge binding a non-static check to a real tool.
- External action recipe — The recipe turning panel/DNS/account steps into actionable instructions.
- Conditional rule — A rule valid only when the page/sector applies (e.g. Product schema).
- Outside automated scope — A signal the engine cannot measure from files; it is excluded from the score and never auto-PASSed.
- Detectable check — A detection check the engine actually runs, counted from code.
- Security pattern — A separate unit of 68 items; never added to the check count.
- ENTEGRE — The status of a catalog row functionally covered by a working check.
- ROADMAP — The count of unclassified items; zero in R50.
- Claim-safety — The language discipline that promises no unverifiable outcome.
- Deploy-Verify — The verification loop proving live effect after upload.
- Diff report — The table of differences between baseline and live state.
- Entity clarity — Machine-level clarity of who/what/where.
- llms.txt — The file giving AI crawlers access/summary directives.
- Structured data — The JSON-LD layer making content machine-readable.
- Canonical — The tag declaring the page's primary URL; prevents duplicate signals.
- hreflang — The tag set mapping language/region versions.
- HSTS — The header instructing browsers HTTPS-only.
- CSP — The policy limiting which resources a page may run.
- SAST — Static security analysis over source without touching the system.
- DAST — Active testing on a live system; only with authorization+scope.
- OWASP mapping — Mapping findings to the shared security language.
- Core Web Vitals — LCP/INP/CLS field-experience metrics; tools measure them.
- Lab vs field — The split between controlled tests and real-user data.
- Cache purge — Clearing hosting/CDN caches to enable live verification.
- Preview debugger — The platform tool refreshing social-preview caches.
FROM THE GLOSSARY
Six core terms
Before leaving the page, six terms the R50 narrative leans on most. Security patterns: a separate unit of 68 items; never added to the check count. Detectable check: one of the 348 detection units counted from code. Manifest: the file-by-file record of a change set. Checksum: a file's fingerprint; SHA-256. Bridge: a repeatable check that pulls evidence from the live URL. Recipe: a step list you run on an external platform. These six are the building blocks of every sentence on the rest of the site.
NAMING
Why not simply "version 50"?
Because "version" implies the engine changed fifty times — it did not; it froze at R39. "Release" names the whole set: documents, numbers, visuals and site travelling together under one seal. R50 is the fiftieth release in this line, and the name promises exactly that much.
Quick answers
Can the figures be added together?
No; they are different units. Detectable checks: 348.
How many detectable checks?
348 (80 core + 268 granular).
Are the numbers consistent?
Counted from code: 80 checks / 26 fixers.
What is the catalog?
A map of the web-quality universe.
See the numbers accounted for
The number-origin ledger and catalog distribution sit line by line in the guide's appendices in the Evidence Hub.