Evidence Hub
Every R50 run leaves an auditable evidence package: score pair, changed files, rollback manifest, manifest and checksums. This page explains each file and how to verify it.
SAMPLE OUTPUT
A sample executive report — from a real run
Produced by the engine (0.7.0) scanning this site's own r20260830-01 package; no value was written by hand. Findings and the roadmap vary by site — this sample shows the format. The executive brief is one page; technical depth moves to the annexes.
- Executive brief: outcome, scope, priorities and a 0-7 / 8-30 / 31-90 day roadmap
- Number provenance: every figure ties back to run records (REPORT_MANIFEST + METRIC_LINEAGE)
- Delivery formats: DOCX + PDF + a machine-readable evidence pack
Download the sample report (Markdown, Turkish)
The score is not a guarantee or a live pass; it exists to track progress across rescans with the same method.
What the evidence package contains
The SafeFix evidence package: six delivery items.
Every WebTrustEngine run leaves an evidence package; the report is not a PDF page but an auditable file set. Its core: before score, after score, changed files, rollback manifest, external actions, the runtime-checks list, the out-of-scope register, the QA report, the manifest and checksums.
This structure delivers two things at once: the story for the executive (what changed, what was gained) and verifiability for the auditor (which file, which hash, which boundary). Checksums are computed from real files after packaging; the manifest lists every file's size and type. The evidence package makes 'trust us' unnecessary — the files speak.
- before/after score
- changed files
- rollback manifest
- external actions
- runtime checks
- outside automated scope
- QA report
- manifest + checksum
What the engine does: Produces an auditable file set per run.
What it doesn't: Does not produce a one-page 'trust us' report.
What the output is: A 10-part evidence set (score→checksums).
For decision-makers: Auditability equals credibility.
For technical teams: Hash/manifest discipline locks delivery quality.
File dictionary
The files you will meet in the delivery ZIP, each with its one-line duty
- RUN_SUMMARY.json — The run's summary record: input, mode, page count, before/after score.
- SKOR_RAPORU_*.md — The 10-domain table + fix types + external-work list.
- FIX_MANIFEST.json — Type-and-count breakdown of applied changes.
- ROLLBACK_MANIFEST.json — backup_dir + changed + created file lists.
- DEGISEN_DOSYALAR_*.txt — The human-readable changed-file list.
- EXTERNAL_ACTION_RECIPES.md — Panel/DNS/account recipes under 24 headings.
- RUNTIME_BRIDGE_KONTROLLERI.md — The tool/metric/how map of the 21 live checks.
- OUT_OF_SCOPE_REGISTER.md — Signals the engine cannot measure automatically, with rationale.
- GODADDY_YUKLEME_TALIMATI.md — Upload + cache + verification steps.
- MANIFEST_*.csv — The file/size/type inventory of the package.
- CHECKSUMS_*.sha256 — Integrity digest of every file; produced after packaging.
- QA/PATCH/COUNT reports — The release's quality, change and count evidence.
How to read the report
Score table
10 rows, internal readiness out of 100. Reading order: the three lowest domains → their entries in the findings list → which class (file/live/external/manual).
Findings list
Domain · severity · file · class columns. 'High severity + ENTEGRE (integrated)' rows are first SafeFix candidates; 'UZMAN (expert)' rows go to the approval queue.
Rollback manifest
Verify the backup_dir path and the two lists (changed/created); archive it. A reversal drill is five minutes of cheap insurance.
Deploy-Verify diff report
Compare expected ↔ live columns; an 'expected present, live missing' row is a cache or server-processing issue — check purge first.
HOW DO I VERIFY?
SHA-256 verification on three platforms
Proving a delivered file is untouched takes a minute. On macOS or Linux: shasum -a 256 file.pdf or sha256sum file.pdf. On Windows PowerShell: Get-FileHash file.pdf -Algorithm SHA256. Compare the 64-character result with the matching row in the CHECKSUMS file of your delivery package. A single differing character means corruption or alteration; a match means the file in your hands is exactly the sealed file.
This small ritual is the whole site's claim in miniature: not a promise, but evidence you can reproduce.
SIX FILES
The six files of an evidence package, one by one
Every engagement produces a package with a fixed cast. changed_files — the flat list of every touched path. fix_manifest — per-file before/after hashes; the spine of accountability. rollback_manifest — the single-step way back. diff report — each change in context, reviewable line by line. score pair — before and after on the same ten-domain ruler. run log — when, on what, with which engine seal. Six files, one property: any third party can re-derive the story without asking anyone.
Client packages belong to the client and are never published. The Sample output section at the top of this page comes from a real run over this site's own package: it shows the format, the language and the evidence discipline. The score-pair walkthrough just below is a representative reading example.
How to read a score pair
Three sample rows are enough to read a before/after pair; the three pairs below are a representative reading example, not taken from a single real run. Technical SEO 62→81: the jump is large and comes from the meta layer that SafeFix covers directly — expected behaviour. Security Headers 40→40: unchanged, because headers are processed at the server, not in files; a recipe is delivered, and the rise appears only in the post-deploy live pull. Accessibility 71→74: a small gain, because few items are automatically fixable; the remaining distance sits in the outside-automated-scope class. The shared lesson of the three rows: the score is not a grade but a map of which work waits at which layer. Two traps to keep in mind when interpreting a pair: domain weights are not equal, so the discussion is about domain rows, not totals; and a change in the file set between two runs makes scores incomparable — which is exactly why the run log is attached next to the pair. Because the score is not a marketing number, it is never published anywhere on this site; it lives only in the package delivered to the client. The only thing made public is the method: how the ruler is built, how the pair is read, and what the log carries — not the number itself. This distinction comes from the same principle as the decision not to publish prices: a number without context is the raw material of misunderstanding.
Why is the run log part of the package?
The run log is the time dimension of the evidence: it records on which date, over which file set, and under which engine seal the work ran. If two runs disagree, this is the first place to look — did the file set change, or the engine version? Without the log a score pair floats in the air; with it, every number becomes the output of a reproducible experiment. The log format is deliberately plain: plain text, a timestamp, a file count, a seal digest. This plainness is chosen over fancy dashboards because evidence that still opens ten years from now is worth more than looking pretty today.
Quick answers
What is delivered?
Engine + fixed site + rollback + score + recipes + report.
Format?
ZIP + MD/DOCX/PDF + CSV.