Deliverable Fidelity PL - weryfikator wiernosci dokumentu

Filozofia

Najgrozniejszy blad to nie zly cytat, tylko prawdziwe ustalenie, ktore wypadlo z podsumowania. Analiza znalazla klauzule RED, opinia ma 12 stron, ale w podsumowaniu dla zarzadu tej klauzuli nie ma - bo model "streszczajac" ja pominal. Cytaty sie zgadzaja, teza wytrzymuje atak, a mimo to deliverable klamie przez przemilczenie. Ten skill sprawdza wiernosc: czy to, co wyszlo, oddaje to, co znaleziono.

To trzecia, odrebna os weryfikacji:

• citation-grounding-pl - czy cytaty istnieja w zrodle (prawdziwosc).
• adversarial-legal-review-pl - czy teza wytrzymuje atak (odpornosc).
• deliverable-fidelity-pl - czy deliverable oddaje analize (wiernosc).

Kiedy odpalac

Gdy finalny dokument streszcza dluzsza analize - opinia z podsumowaniem dla zarzadu, memo DD z tabela ryzyk, raport z sekcja wnioskow. Tam, gdzie skracanie moze zgubic ustalenie. Nie trzeba dla krotkiego pisma bez warstwy "analiza -> streszczenie".

Wejscie

1. Ustalenia analizy (findings) - lista z severity i opcjonalnym rozstrzygnieciem:

   { "findings": [
       { "id": "F1", "severity": "RED", "tekst": "klauzula limitacji odpowiedzialnosci sprzeczna z art. 473 par. 2 KC", "rozstrzygniecie": "rekomendacja usuniecia" },
       { "id": "F2", "severity": "YELLOW", "tekst": "termin platnosci 60 dni - ryzyko zatorow", "rozstrzygniecie": "" }
     ],
     "deliverable": "<pelny tekst finalnego dokumentu>" }
   

2. Deliverable - finalny tekst do sprawdzenia.

Workflow

1. Check mechaniczny (skrypt, za darmo) - uruchom:

   node scripts/fidelity-check.mjs <plik-zadania.json>
   

   Skrypt wyciaga kluczowe terminy z kazdego ustalenia, normalizuje (lowercase, biale znaki, cudzyslowy, myslniki) i stosuje konserwatywny stem (utniecie 2 koncowych znakow przy slowach >=7, by zlapac fleksje
   • "klauzuli" pasuje do "klauzula"), po czym sprawdza, czy wystarczajaco terminow pojawia sie w deliverable. Per ustalenie: reprezentowane lub pominiete. Pominiete RED -> blokada (exit 1). Rozstrzygniecia tez sprawdzane.
2. Kontrola wyrywkowa LLM (osad) - dla ustalen RED (skrypt podaje liste najciezsze_do_spotcheck_llm, maks. 3) sprawdz nie tylko obecnosc slow, ale czy sens jest oddany (RED moze byc wspomniany, ale zbagatelizowany - "drobna uwaga" zamiast "klauzula niewazna"). To robi model, nie skrypt - mechaniczny match nie wykryje przeklamania tonu. Gdy brak ustalen RED, ta kontrola odpada (skrypt nie eskaluje YELLOW).
3. Werdykt - liczony deterministycznie wg funkcji ponizej, nie "na oko".

Funkcja werdyktu (deterministyczna, jawne wagi i progi)

Werdykt NIE jest ogolnym osadem modelu. Liczy sie go z wynikow kroku 1 (skrypt) i kroku 2 (kontrola wyrywkowa) wg jawnego wzoru - trzy kroki, zawsze w tej kolejnosci:

Krok A - warunki krytyczne (dowolny spelniony -> FAIL, bez liczenia dalej):

• pominiete RED (skrypt: pominiete_red niepuste, exit 1),
• RED obecny, ale zbagatelizowany (kontrola wyrywkowa LLM),
• rozstrzygniecie RED nieodzwierciedlone (skrypt: rozstrzygniecia_red_brak niepuste).

Krok B - score wazony pokrycia. Kazde ustalenie ma wage wg severity:

Severity	Waga
RED	5
YELLOW	2
GREEN / INFO	1

score = suma wag ustalen reprezentowanych / suma wag wszystkich ustalen. Score < 0.85 -> FAIL (nawet gdy zaden RED nie wypadl - masowe gubienie YELLOW tez jest przemilczeniem).

Krok C - prog warunkowy. 3 lub wiecej pominietych YELLOW -> najwyzej CONDITIONAL_PASS: deliverable moze wyjsc dopiero po decyzji czlowieka, z lista pominietych ustalen dolaczona do raportu. Inaczej PASS.

Wagi i progi sa wypisane wprost celowo: audytor odtwarza werdykt z samych liczb w raporcie, bez pytania modelu o uzasadnienie. To wymog rejestrowania zdarzen z art. 12 AI Act sprowadzony do arytmetyki - argument wprost pod PATRONa. Te same trzy kroki (krytyczne -> score wazony -> prog warunkowy) stosuje adversarial-legal-review-pl dla filarow tezy; roznia sie tylko wagi, bo inna materia.

Output (dla uzytkownika)

## Wiernosc deliverable: FAILED

Mechaniczny: 4/5 ustalen reprezentowane
- POMINIETE (RED): F3 "kara umowna bez gornego limitu" - BLOKADA, brak w deliverable
Kontrola wyrywkowa LLM (RED, maks. 3):
- F1 (RED) - oddany wiernie
- F2 (RED) - OBECNY ALE ZBAGATELIZOWANY: analiza "niewazny zapis", deliverable "kwestia do rozwazenia"
- F4 (YELLOW) - oddany

Funkcja werdyktu:
- Krok A (krytyczne): pominiete RED F3 + zbagatelizowany RED F2 -> FAIL.
- Krok B (informacyjnie): reprezentowane F1(5)+F2(5)+F4(2)+F5(1) / wszystkie F1..F5 (5+5+5+2+1)
  = 13/18 = 0.72 < 0.85 (F5 = GREEN, reprezentowane).

Werdykt: FAIL - NIE wysylaj. Dodaj F3 do podsumowania, wzmocnij F2 do faktycznej wagi.

Reguly twarde

• Pominiete RED = bezwzgledna blokada. Czerwone ustalenie nieobecne w deliverable to przemilczenie istotnego ryzyka - nigdy nie przepuszczaj.
• Bagatelizowanie liczy sie jak pominiecie. RED opisany jako "drobna uwaga" jest gorszy niz brak, bo usypia czujnosc. Kontrola wyrywkowa LLM ma to lapac.
• Skrypt mowi co obecne, model mowi czy wiernie. Nie ufaj samemu matchowi slow - i nie kaz modelowi liczyc obecnosci, od tego jest skrypt.

Ochrona danych (RODO)

Skrypt dziala lokalnie (Node, zero sieci). Kontrola wyrywkowa LLM widzi ustalenia i deliverable - jezeli zawieraja dane objete tajemnica, pseudonimizuj przez let-it-be wczesniej. Skrypt nie zapisuje logow poza katalogiem zadania.

Integracja z AI Act

Weryfikacja wiernosci to dowod, ze nadzor czlowieka (art. 14) dostaje pelen obraz - deliverable nie ukrywa przed decydentem ustalen, ktore analiza wykryla. Raport wiernosci wkladaj do legal-ai-audit-bundle.

Atrybucja

Pattern (post-assembly fidelity: mechaniczny check reprezentacji ustalen + kontrola wyrywkowa LLM najciezszych) zainspirowany przez AnttiHero/lavern (Apache 2.0, src/assembly/post-assembly-verifier.ts). Kod, reguly i polska lista stop-slow napisane od zera. Nie skopiowano kodu Lavern.

Wzorzec dodany w v1.1.0: deterministyczna funkcja werdyktu z jawnymi wagami i progami (krytyczne -> score wazony -> prog warunkowy) z AnttiHero/lavern (Apache 2.0), adaptacja od zera - wagi severity, prog 0.85 i regula CONDITIONAL_PASS to opracowanie MateMatic.

Wspólne reguły wtyczki fundament-weryfikacyjny (Fundament weryfikacyjny)

Te reguły obowiązują w każdym skillu tej wtyczki, także gdy sam skill milczy. Są skopiowane do każdego skilla, więc działają zarówno po instalacji całej wtyczki, jak i pojedynczego skilla. Pełniejszy standard: https://github.com/matematicsolutions/awesome-matematic-skills-pl/tree/main/references

Pięć warstw ochrony (przed każdym disclaimerem)

1. Weryfikacja źródła - przepisy i orzecznictwo z baz, nie z pamięci modelu.
2. Klasa pewności - każda teza prawna oznaczona: zweryfikowane / do sprawdzenia / nie używać.
3. Kontrola przesłanek - fakty od użytkownika sprawdza się przed analizą.
4. Jawny zakres ujemny - każdy skill mówi, czego NIE robi.
5. Bramka człowieka - uprawniona osoba sprawdza i zatwierdza wynik.

Jeśli błąd przeszedłby bez zatrzymania przez warstwy 1-5, wina jest w skillu. Naprawiamy narzędzie, nie dopisujemy noty. Nota "to nie porada prawna" nie zatrzymuje błędu i nie przenosi odpowiedzialności.

Tagi pewności

• Zweryfikowane - źródło sprawdzone w sesji, z pełną sygnaturą: (kodeks cywilny art. 415), (wyrok SN II CSK NN/RR, SAOS).
• Do sprawdzenia - prawdopodobne, niezweryfikowane: [sprawdź w SAOS].
• Nie używać - zmyślona sygnatura lub przepis. Pomiń, nigdy nie wymyślaj numeru.

Tag stoi przy linii, której dotyczy. Samo istnienie sygnatury nie wystarcza - treść trzeba sprawdzić.

Bramka człowieka

Nic nie zostaje wysłane, złożone, podpisane ani opublikowane, zanim sprawdzi i zatwierdzi to uprawniony człowiek. Wynik skilla to projekt, nie gotowy dokument.

Zakres pluginu

Fundament weryfikacyjny jest neutralny jurysdykcyjnie - to rdzeń metody, nie substancja prawa. Nie łączy się z żadnym źródłem zewnętrznym (brak konektorów MCP) i nie wysyła danych na zewnątrz. Substancję dostarczają osobne pluginy (orzecznictwo, dokumenty).