Artykuł 7, ostatni z toru Evidence Graph ← Mapa rozgraniczeń
Sześć artykułów toru dało kolejno: definicję, metodę pomiaru, typologię dowodów, implementację techniczną, żywy przypadek i mapę rozgraniczeń. Ten artykuł składa wszystko w jedną powtarzalną procedurę — audyt atrybucji — którą można przeprowadzić samodzielnie w jeden do dwóch dni pracy i powtarzać w stałym rytmie.
Różnica względem testu dwustronnego: test mierzy rozjazd (co modele czytają vs co przypisują). Audyt odpowiada dodatkowo na pytania dlaczego rozjazd istnieje i co dokładnie naprawić — łącząc pomiar zewnętrzny z przeglądem czterech warstw atrybucji od środka.
Faza 0: Zakres — zdefiniuj encję i jej ekosystem
Audyt bez zdefiniowanego zakresu produkuje wyniki, których nie da się interpretować. Przed pierwszym pytaniem do modelu ustal na piśmie:
Encja główna — podmiot, o którego wiarygodność pytamy: nazwa kanoniczna, warianty nazwy (dawne, potoczne, z literówkami występującymi w sieci), domena główna.
Ekosystem — wszystkie miejsca, gdzie żyje dorobek encji: własne serwisy i subdomeny, serwisy tematyczne prowadzone przez ten sam podmiot, profile, kanały. To jest lista domen, po których w fazie 1 będzie szukać się dowodów, a w fazie 3 — sprawdzać spójność.
Dziedzina kompetencji — obszar, w którym encja twierdzi, że ma dorobek, sformułowany tak, jak pytają klienci, nie jak mówi branża.
Typowy błąd tej fazy: zawężenie ekosystemu do domeny głównej. Dowody organizacji z realnym dorobkiem prawie nigdy nie mieszkają wyłącznie pod jej głównym adresem — i dokładnie dlatego atrybucja się sypie.
Faza 1: Inwentaryzacja dowodów
Przejdź ekosystem i zbuduj rejestr wszystkiego, co pretenduje do miana dowodu. Dla każdej pozycji zanotuj cztery pola: co to jest (jedno zdanie), gdzie żyje (URL), poziom według typologii (deklaratywny / obserwowalny / replikacja), czy zawiera jawną atrybucję (czy tekst i dane strukturalne łączą dowód z encją, czy autor uznał to za „oczywiste”).
Dwa wyniki tej fazy są cenniejsze niż sam rejestr. Pierwszy: rozkład poziomów — jeśli 90% pozycji to poziom 1, problemem nie jest atrybucja, tylko dorobek, i żadna schema tego nie naprawi. Drugi: lista kandydatów do awansu — dowody poziomu 1 opisujące realną pracę, którym brakuje tylko metryk, dat i ścieżki weryfikacji, żeby stać się poziomem 2. To najtańsza poprawa jakości grafu.
Faza 2: Pomiar zewnętrzny — test dwustronny
Pełny protokół opisuje artykuł drugi; tu przypomnienie parametrów: trzy modele różnych rodzin z wyszukiwaniem, świeże sesje, strona A (6–10 pytań merytorycznych z dziedziny — pomiar konsumpcji), strona B (4–6 pytań o encję — pomiar atrybucji), każde pytanie w dwóch–trzech wariantach.
Nowość względem samego testu: w stronie B notuj wyniki względem rejestru z fazy 1. Nie „czy model coś przypisał”, tylko: które konkretnie pozycje rejestru model połączył z encją, które pominął, a które przypisał błędnie (cudze osiągnięcia, nieistniejące projekty — halucynacje atrybucji też się zdarzają i też są wynikiem audytu).
Wynik fazy: pozycja w macierzy czterech stanów oraz wskaźnik atrybucji — ułamek dowodów z rejestru, które modele łączą z encją. W case study toru baseline wyniósł 0/5. To jest liczba, którą kolejne audyty będą porównywać.
Faza 3: Diagnoza warstw — dlaczego jest, jak jest
Pomiar zewnętrzny mówi „co widzą maszyny”. Faza 3 sprawdza od środka, co miały do zobaczenia — warstwa po warstwie, według architektury z artykułu pierwszego i implementacji z czwartego.
Warstwa treści. Dla każdego dowodu obserwowalnego z rejestru: czy tekst zawiera jawne zdanie atrybucyjne łączące dowód z encją główną — po nazwie kanonicznej, nie po domyśle?
Warstwa danych strukturalnych. Zbierz wszystkie bloki JSON-LD z ekosystemu i przeczytaj je obok siebie. Pytania kontrolne: czy encja główna ma jeden, stabilny @id? Czy treści własne wskazują ten @id w author / publisher / creator? Czy encja ma subjectOf do materiałów dowodowych? Czy któryś blok jest pusty lub bez typów?
Warstwa spójności między domenami. Czy serwisy ekosystemu deklarują przynależność (parentOrganization / subOrganization) wzajemnie? Czy nazwa, opis i identyfikatory encji są identyczne wszędzie? Czy sameAs prowadzą do miejsc, które istnieją i odwzajemniają powiązanie?
Warstwa zewnętrzna. Dla wzmianek ze źródeł trzecich: test z mapy rozgraniczeń — czy zawierają sprawdzalne twierdzenie o dokonaniach, czy tylko potwierdzają istnienie encji?
Wynik fazy: lista konkretnych braków przypisana do warstw — czyli gotowy backlog naprawy.
Faza 4: Raport i plan
Raport audytu atrybucji mieści się na jednej stronie i zawiera pięć elementów: stan z macierzy (1–4), wskaźnik atrybucji (x/n dowodów), rozkład poziomów w rejestrze, listę braków per warstwa, plan naprawy z kolejnością.
Kolejność napraw wynika ze stanu. Stan 4: najpierw obecność (piętro entity SEO), atrybucja później. Stan 3: budowa dowodów obserwowalnych — praca na miesiące, ale bez niej fundament jest z deklaracji. Stan 2: czysta inżynieria atrybucji według kolejności z artykułu czwartego — encja z @id, relacje treści, struktura ekosystemu, spięcie dowodów. Stan 1: utrzymanie i rozbudowa rejestru.
Arkusz punktów kontrolnych
Wersja skrócona całej procedury — dwanaście pytań, każde tak/nie. Wynik poniżej ośmiu „tak” oznacza, że graf dowodów nie działa, niezależnie od jakości dorobku.
- Czy istnieje pisemna definicja encji głównej i pełna lista domen ekosystemu?
- Czy istnieje rejestr dowodów z poziomami typologii?
- Czy w rejestrze jest co najmniej kilka pozycji poziomu 2 (obserwowalnych)?
- Czy wykonano test dwustronny w ostatnim kwartale?
- Czy znany jest wskaźnik atrybucji (x/n) i stan z macierzy?
- Czy każdy dowód obserwowalny ma w treści jawne zdanie atrybucyjne?
- Czy encja główna ma jeden stabilny
@idużywany w całym ekosystemie? - Czy treści własne wskazują encję przez
@idwauthor/publisher/creator? - Czy encja ma
subjectOfspinający materiały dowodowe? - Czy serwisy ekosystemu wzajemnie deklarują przynależność?
- Czy
sameAsprowadzą do istniejących, odwzajemniających miejsc? - Czy zaplanowany jest następny pomiar (data, ten sam protokół)?
Rytm
Audyt atrybucji nie jest jednorazowy. Sensowny rytm: pełna procedura raz na kwartał, test dwustronny (sama faza 2) po każdej istotnej zmianie — publikacji nowego dowodu, przebudowie serwisu, zmianie struktury ekosystemu. Modele, ich indeksy i dane treningowe zmieniają się bez zapowiedzi; wskaźnik atrybucji zmierzony raz jest fotografią, mierzony rytmicznie — wykresem.
Domknięcie toru
Tor zaczął się od zdania, że AI Visibility mówi, czy Cię widać, a ten tor — co z tego wynika, gdy ktoś zapyta o Twoją wiarygodność. Siedem artykułów później odpowiedź da się streścić w trzech regułach:
Dowód kompetencji ma dwa składniki — istnienie i atrybucję — i model nie sumuje dowodów, których nie umie przypisać. Wartość dowodu jest proporcjonalna do kosztu jego podrobienia — dlatego deklaracje tanieją do zera, a replikacja jest bezcenna. Atrybucja jest problemem danych — mierzalnym testem dwustronnym, naprawialnym w warstwach, weryfikowalnym ponownym pomiarem.
Reszta jest inżynierią — opisaną w tym torze, zastosowaną publicznie w case study, którego część druga ukaże się z wynikami, niezależnie od tego, jakie będą. Samo pojęcie żyje w Słowniku Agentic Web — i, zgodnie z własną teorią, będzie warte tyle, ile dowodów uda się z nim powiązać.
Pojęcia ze słownika: Evidence Graph · AI Visibility Audit · Sześć warstw AI-readiness · Brand Mention w AI · Schema Density
