What is R50? — Release Discipline and the Number Contract

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 R50's core numbers

The scope is read in three layers: a 2,033-item reference catalog, 319 implemented checks (80 core + 239 granular), and the verification/action layers. Each number has its own defined scope and boundary.

See where each number comes from

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 catalog apart from the engine

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.

Visual comparing catalog and working-check panels. — The 319 vs 2,033 split: the map (catalog) is never confused with the engine (working checks).

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
reference catalog	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

What does it claim?

Readiness, evidence, classification and reversible fixes.

What does it not claim?

Ranking, traffic, AI citation, a live pass, or security guarantees.

Where is the proof?

Manifests, checksums, before/after scores and the documents in the Evidence Hub.

What is the boundary?

Not a pentest; not legal advice; live scores come from independent tools.

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).
Manual verification — The item class needing human judgment; never auto-PASSed.
Implemented detectable check — A detection check the engine actually runs, counted from code.
Reference catalog — The 2,033-item signal map; not a 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. Reference catalog: the 2,033-item signal map; not a check count. Working check: one of the 319 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.