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, manual-verification items, 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
- manual verification
- 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.
- MANUAL_VERIFICATION_RULES.md — Items awaiting human approval, 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' rows are first SafeFix candidates; 'MANUAL' 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.
Reading the score pair takes three sample rows: a large jump in Technical SEO traces to the meta layer SafeFix touched; an unchanged Security Headers score is expected, since headers process at the server and rise only in the post-deploy live pull; a small Accessibility gain marks the frontier where automated items end and expert-class items wait. The pair is not a grade — it is a map of which work waits at which layer.
Quick answers
What is delivered?
Engine + fixed site + rollback + score + recipes + report.
Format?
ZIP + MD/DOCX/PDF + CSV.