Fact-Check Engine to system walidacji claimów na stronach internetowych oparty na YAML source of truth. Przeskanowano 31 landing pages, zweryfikowano 56 metryk, usunięto 5 niezweryfikowanych claimów, rozwiązano 7 konfliktów wartości. Pipeline: YAML registry → Prompt A (scan) → CSV raport → decyzja ludzka → Prompt B (fix) → propagacja cross-landing → weryfikacja grep 0 wystąpień. Technologie: YAML, Claude Code CLI, PHP, CSV, regex/grep, git.

Content Integrity System

31 stron. 56 metryk. 0 niezweryfikowanych claimów.

Każda liczba na Twojej stronie ma udowodnione źródło

Koniec z "wydaje mi się, że to było 80". YAML source of truth + AI scanning = zero wątpliwych claimów, zero konfliktów między stronami, pełna audytowalność.

31 stron przeskanowanych
56 metryk zweryfikowanych
0 NO_SOURCE publicznych
7 konfliktów rozwiązanych
Porozmawiajmy o Twoim serwisie
fact-check-engine v1.0
$ scan --page index.php --type root
Scanning 7 sections...
✓ hero: 4 claims [ALL VERIFIED]
⚠ value-prop: +23% ROAS CONFLICT → should be +40%
✓ proof: 3 claims [ALL VERIFIED]
⚠ systems: 80 systemów CONFLICT → should be 104

Result: 2 CONFLICT, 0 NO_SOURCE
$ fix --apply --source master_cv.yaml
✓ +23% → +40% (D1: ROAS verified)
✓ 80 → 104 (D5: projects_completed)
✓ grep "80 wdro|80 system" = 0 matches

RELEASE GATE: PASS

Problemy które rozwiązuje

Każdy serwis z >10 stronami ma te same bolączki z danymi.

Ta sama metryka, różne wartości

"80 systemów" na stronie głównej, "104 projekty" w CV, "50+ wdrożeń" w portfolio. Która jest prawdziwa?

Single source of truth (YAML)

Claim bez źródła

"ROI 300%", "150% wzrost konwersji" — kto to policzył? Skąd ta liczba? Audyt ujawni brak dowodu.

Każdy NUM ma yaml_path

Zmiana w jednym pliku, reszta nieaktualna

Poprawiasz liczbę w CV — ale zapominasz o 15 stronach, które ją używają. Drift narasta z każdą zmianą.

Cross-landing propagacja + grep weryfikacja

AI "dorabia" fakty

Prosisz LLM o naprawę tekstu — a on wymyśla nową metrykę, której nie masz w danych. Halucynacja w produkcji.

Hierarchia zmian NUM → QUAL-HARD → QUAL-SOFT

Pipeline w 6 krokach

Od chaosu metryk do release gate = 0 NO_SOURCE, 0 CONFLICT

01

YAML Registry

Jedna plik YAML jako source of truth. Każda metryka ma ścieżkę, ID i kontekst.

master_cv.yaml
02

Prompt A: Scan

AI skanuje stronę sekcja po sekcji. Klasyfikuje claimy: NUM, QUAL-HARD, QUAL-SOFT.

narrative-map.md
03

CSV Raport

Każda metryka w tabeli: wartość, źródło, status (OK/CONFLICT/NO_SOURCE), decyzja.

metrics_verification.csv
04

Decyzja ludzka

Człowiek decyduje: TAK (dodaj do YAML), NIE (usuń z landingu), QUAL-SOFT (przeformułuj).

TAK / NIE / SOFT
05

Prompt B: Fix

AI naprawia sekcje wg hierarchii: nie dodaje nowych faktów, tylko zamienia lub usuwa.

git diff
06

Release Gate

Grep weryfikacja: 0 wystąpień starych wartości. Dopiero wtedy deploy.

PASS / FAIL

Co poszło nie tak (i jak to naprawiliśmy)

Rzeczywiste problemy z wdrożenia na 31 stronach

Context drift w LLM

Problem: Po 5+ sekcjach AI zapomina reguły DISC i zaczyna mieszać tone
Fix: Odświeżanie kontekstu co 5 sekcji + mechanizm kontynuacji między sesjami

912 vs 847 w 15 plikach

Problem: Stara wartość (912 sklepów) w 15 plikach, nowa (847 lokalizacji) tylko w YAML
Fix: grep → edit replace_all → grep weryfikacja 0 wystąpień. Dopiero potem commit.

AI dorabia fakty

Problem: Prompt "napraw sekcję" → AI wymyśla "95% adopcji", "2 tyg do insightów"
Fix: Hierarchia zmian — §1 NUM, §2 QUAL-HARD, §3 QUAL-SOFT. Zakaz nowych NUM.

Konflikty cross-landing

Problem: +23% ROAS na index.php, +35% na dla-kogo, +40% w CV — która prawdziwa?
Fix: CSV z 56 metrykami → decyzja człowieka → propagacja do WSZYSTKICH plików

NDA metryki bez kontekstu

Problem: "2.1M klientów" — ale z jakiego systemu? Z jakiego dashboardu?
Fix: Każda metryka w YAML ma A-ID, opis projektu, ścieżkę cv.sections

Brak release gate

Problem: "Naprawiłem 3 pliki" — ale 12 innych nadal ma starą wartość
Fix: Gate = grep musi zwrócić 0 wyników dla KAŻDEJ starej wartości. Inaczej nie puszczamy.

Architektura systemu

Przepływ danych od YAML do produkcji

YAML master_cv.yaml — single source of truth. key_metrics + project_metrics z A-ID.
↓
SCAN Prompt A skanuje sekcja po sekcji → klasyfikuje claimy (NUM/QUAL-HARD/QUAL-SOFT) → raport
↓
CSV metrics_verification.csv — 56 wierszy. Kolumny: id, metryka, wartość, system, status, decyzja.
↓
FIX Prompt B naprawia per-sekcja → diff z source attribution → zakaz nowych faktów
↓
GATE grep --count starych wartości = 0 → PASS. Inaczej: loop back do FIX.
↓
DOCS landing_facts_audit.md — pełna historia zmian. Phase 1 → 2 → 3 → 4. Audytowalny trail.

Powiązane systemy

Inne narzędzia z tego samego stacku

System Decyzyjny

Dashboard vs system decyzyjny. 4 warstwy: dane, identity, atrybucja, predykcja.
CV Generator

YAML → ATS-compliant PDF. Jedno źródło danych, CV dopasowane do każdej oferty.
ProductFeedManager

Automatyczna klasyfikacja produktów, +28% ROI kampanii, feed optimization.

Ile niezweryfikowanych claimów jest na Twoim serwisie?

Pokażę Ci w 30 minut — przeskanuję 3 przykładowe strony i pokażę każdy claim bez źródła.

30 minut Darmowy audyt
3 strony Przeskanuję z Twojego serwisu
Raport CSV Z każdym claimem
Zamów bezpłatny audyt
Bez zobowiązań
NDA na życzenie
CSV do zachowania