Czerwony zespół dla pisma prawnego - bierze gotowy deliverable wysokiej stawki (opinia, memo DD, M&A, pismo procesowe, rekomendacja do zarządu) i prowadzi kontradyktoryjną debatę: builder buduje...
Lepiej, żeby słabość Twojej tezy znalazł Twój własny agent niż przeciwnik na rozprawie.
Pojedynczy przebieg LLM produkuje argumentację, która brzmi pewnie - bo model jest trenowany, by brzmieć pewnie. To złudzenie kompetencji. Prawdziwa wartość prawnika to przewidzieć kontrargument, kontr-orzecznictwo i lukę w rozumowaniu, zanim zrobi to druga strona. Ten skill instytucjonalizuje kontradyktoryjność: jeden agent broni, drugi atakuje, trzeci godzi, czwarty weryfikuje.
To NIE jest pisanie deliverable od zera. To stress-test gotowego deliverable.
Pełny cykl jest drogi tokenowo. Uruchamiaj tylko dla wysokiej stawki:
| Uruchom (high-stakes) | NIE uruchamiaj (zwykłe) |
|---|---|
| Opinia prawna do klienta | Notatka wewnętrzna |
| Due diligence / memo M&A | Streszczenie orzeczenia |
| Pismo procesowe przed terminem | Robocza analiza, draft |
| Rekomendacja do zarządu kancelarii | FAQ, content marketingowy |
| Stanowisko niosące istotne ryzyko finansowe lub reputacyjne | Zapytanie rutynowe |
Jeśli sprawa nie jest high-stakes - powiedz to wprost i zaproponuj zwykły jednoprzebiegowy review zamiast pełnej debaty. Nie pal tokenów na rutynę.
Każda rola to osobny przebieg z czystym mandatem. Pseudonimizuj wejście przez let-it-be,
jeśli dokument zawiera dane objęte tajemnicą zawodową.
Recenzenci dzielą się na dwa poziomy o RÓŻNYM dostępie do materiału. To jest celowe, nie przypadkowe:
W trybie jednego modelu grającego wszystkie role izolacja jest dyscypliną promptu, nie sandboxem - roli IZOLOWANEJ wprost zabroń sięgania po źródła. Twarda izolacja przez osobne przebiegi to opcja premium (bramka kosztu, sekcja wyżej).
Oceń, czy sprawa kwalifikuje (tabela wyżej). Jeśli nie - stop, zaproponuj zwykły review.
Zbuduj najsilniejszą możliwą argumentację za tezą deliverable. Zbierz najlepsze przepisy, orzecznictwo, doktrynę. Cel: dać attackerowi twardy cel, nie słomianego stracha. Output: teza + 3-7 filarów (każdy z podstawą prawną).
Zaatakuj każdy filar jak przeciwnik procesowy / sceptyczny sąd:
saos-orzecznictwo / eu-sparql-search)Dla każdego filaru rozstrzygnij: przetrwał / osłabiony / obalony / NIEPEWNE. Wskaż, co zostaje z tezy po ataku, gdzie deliverable wymaga przeformułowania, gdzie trzeba zastrzeżenia ("ryzyko sporne, linia orzecznicza niejednolita"). Output: tabela filar → werdykt → rekomendowana zmiana.
NIEPEWNE to werdykt pierwszej klasy, nie unik. Synthesizer używa go, gdy debata nie rozstrzygnęła sporu, i ZAWSZE dokłada dwie rzeczy: podkategorię oraz wskazanie, jakiego dowodu brakuje do rozstrzygnięcia. Podkategorie:
Zakaz przemilczania: filaru nierozstrzygniętego NIE wolno zapisać jako "przetrwał" ani pominąć w tabeli. Ciche podciągnięcie niepewności pod pewność to najgorszy możliwy błąd tego skilla - dokładnie ten, który ma łapać. To slogan "AI, która wie, czego nie wie" jako schemat danych, nie deklaracja marketingowa.
Mechaniczna i merytoryczna kontrola zsyntetyzowanego deliverable:
citation-grounding-pl (BLOKADA na 🔴)Gdy verifier znajdzie uchybienia, deliverable wraca do poprawy i przechodzi atak ponownie. Pętla ma twarde limity i jedną gwarancję: nigdy nie wysyłamy wersji gorszej od najlepszej widzianej.
draft_v1 (po pierwszej syntezie), draft_v2... Każda iteracja to
celowane poprawki z rekomendacji synthesizera, potem ponowny atak i weryfikacja.wynik_zbiorczy (0-100) = średnia z: verifier (X/10 → x10) + spójność (IZOLOWANY,
0-100) + grounding (WZBOGACONY, 0-100). Składnik twardy: mechaniczna kontrola cytatów -
każde niepowodzenie blokuje niezależnie od wyniku (chroni przed fałszywym cofnięciem na
subiektywnej ocenie modelu).v_najlepsza: po każdej iteracji zapamiętaj draft z najwyższym wynik_zbiorczy.Decyzja o wyjściu należy do synthesizera. Drzewo, w kolejności:
zaakceptowano_na_vN.wynik_zbiorczy(vN) < wynik_zbiorczy(v_najlepsza) →
odrzuć vN, przywróć v_najlepsza, wyjdź jako wymuszone_wyjscie_na_v<najlepsza>_z_otwartymi
z banerem „runda N pogorszyła deliverable - przywrócono najlepszą wersję".zaakceptowano_wczesnie_na_vN (nie palić tokenów na
marginalny zysk).wymuszone_wyjscie_na_limicie + baner z listą nierozstrzygniętych zarzutów.Powód limitu: nieskończone polerowanie maskuje problem zamiast go rozstrzygać. Jeśli trzy rundy nie domknęły zarzutu, redakcja go nie domknie - spór jest merytoryczny albo brakuje dowodu, a to rozstrzyga prawnik, nie kolejny przebieg modelu. Licznik rund i stan końcowy zapisuj w raporcie (patrz Output).
Każde zakończenie MUSI wyprodukować artefakt dla człowieka (pełny blok recenzji albo markdown awaryjny). Nigdy ciche/puste wyjście. Stany końcowe:
zaakceptowano_na_vN | zaakceptowano_wczesnie_na_vN | wymuszone_wyjscie_na_v<najlepsza>
(regresja) | wymuszone_wyjscie_na_limicie | porazka_z_fallbackiem (np. brak danych
źródłowych - dostarcz, co masz, plus powód).
Baner zawsze pokazuje: stan końcowy, którą wersję draftu dostarczono, jakie blokery
zostały. Governance: skill produkuje rekomendację i wersje draftu; NIE wysyła
dokumentu. Decyzja „wysłać mimo wymuszone_wyjscie_na_limicie z blokerami" zostaje przy
człowieku. Transkrypt wszystkich wersji v1..vN idzie jako załącznik do paczki audytowej -
dowód ograniczonej rewizji i ewentualnego cofnięcia (AI Act art. 12/14).
Werdykt końcowy NIE jest ogólnym osądem verifiera. Liczy się go z jawnego wzoru:
Krok A - warunki krytyczne (dowolny spełniony → FAIL, bez liczenia dalej):
Krok B - score ważony. Każdy filar dostaje wagę wg werdyktu synthesizera:
| Werdykt filaru | Waga |
|---|---|
| przetrwał | 1.0 |
| osłabiony | 0.5 |
| NIEPEWNE (obie podkategorie) | 0.25 |
| obalony | 0.0 |
score = suma wag / liczba filarów. Score < 0.6 → FAIL.
Krok C - próg warunkowy. 2 lub więcej filarów osłabionych lub NIEPEWNYCH →
najwyżej WYŚLIJ_WARUNKOWO (odpowiednik CONDITIONAL_PASS w deliverable-fidelity-pl;
lista warunków: jakie zastrzeżenia dopisać, jaki dowód uzupełnić). Inaczej PASS.
Wagi i progi są wypisane w skillu celowo: audytor ma odtworzyć werdykt z samych liczb,
bez pytania modelu "dlaczego". To wymóg rejestrowania zdarzeń z art. 12 AI Act
zamieniony na arytmetykę - argument wprost pod PATRONa. Te same trzy kroki
(A krytyczne → B score ważony → C próg warunkowy) stosuje deliverable-fidelity-pl;
różnią się tylko wagi, bo inna jest materia (filary tezy vs ustalenia analizy).
Debata builder/attacker to spór wyreżyserowany: obie role gra ten sam model i może zgodnie mylić się w tym samym miejscu. Panel rozbieżności łapie inny typ błędu - interpretację, którą jeden przebieg uznaje za oczywistą, a która wcale oczywista nie jest.
Kiedy (bramka kosztu, jawna). Tylko dla klauzul i tez NOŚNYCH: takich, od których zależy wynik sprawy, przy stawce już zakwalifikowanej jako wysoka (sekcja 0). Każda niezależna ocena to osobny pełny przebieg, więc domyślnie panel dostaje 0 pytań; wskaż maksymalnie 1-2 filary, dla których rozbieżność interpretacji realnie zmienia werdykt. Jeśli żaden filar nie spełnia tego progu - nie uruchamiaj panelu i napisz to wprost w raporcie.
Protokół.
saos-orzecznictwo / ISAP (legal-data-hunter-pl) /
eu-sparql-search (polskie i unijne źródła; oryginał lavern używa
CourtListener - US) i powtórz głosowanie z dowodem na stole. Jedna runda
re-vote, nie więcej.Format FINDING w deliverable:
FINDING - rozbieżność panelu (par. 8, kara umowna):
Ocena A (model X): opcja B - "kara umowna zastrzeżona na wypadek niewykonania" (pewność: wysoka)
Ocena B (przebieg niezależny): opcja C - "z winy wykonawcy" (pewność: średnia)
Re-vote po dowodzie (uchwała SN III CZP NN/RR, SAOS): split utrzymany.
Werdykt filaru: NIEPEWNE (DOKUMENT_NIEJEDNOZNACZNY) - decyzja prawnika.
Spójność z resztą skilla (dissent wpina się, nie dubluje). Werdykt z panelu
wchodzi do tabeli synthesizera jak każdy inny: split nierozstrzygnięty = NIEPEWNE
z wagą 0.25 w funkcji werdyktu (sekcja 4b), więc 2+ takie filary same z siebie
ściągają wynik do WYŚLIJ_WARUNKOWO. Re-vote panelu NIE liczy się jako runda
rewizji z sekcji 4a - limit rund per stawka dotyczy poprawek deliverable po
verifierze, a panel ma własny, jeszcze twardszy limit: jedno głosowanie + jedno
powtórzenie z dowodem. Eskalacja do człowieka to ten sam mechanizm, co
wymuszone_wyjscie_na_limicie w drzewie wyjścia.
## Adversarial review - <nazwa deliverable>
Stawka: WYSOKA (kwalifikuje)
Filary tezy: 5 | Przetrwały: 2 | Osłabione: 1 | Obalone: 1 | NIEPEWNE: 1
| Filar | Atak (siła) | Werdykt | Działanie |
|------------------------------|------------------|------------|----------------------------|
| Podstawa roszczenia art. X | brak (niska) | przetrwał | bez zmian |
| Linia orzecznicza SN | III CZP NN/RR (wysoka)| obalony| usuń lub dodaj zastrzeżenie|
| Skuteczność zastrzeżenia umownego | II CSK NN/RR (średnia) | NIEPEWNE (NIEWYSTARCZAJĄCY_DOWÓD) | brakuje: pełny tekst uzasadnienia - pobierz przez saos-orzecznictwo |
| ... | ... | ... | ... |
Kontrola verifiera: 9/10 OK. Punkt 1 (grounding): 1 cytat 🔴 - warunek krytyczny.
Iteracje: v2 (najlepsza=v2) | Stan końcowy: zaakceptowano_wczesnie_na_v2 | wynik_zbiorczy: 78 → 86 (limit 3 rundy dla stawki wysokiej).
Funkcja werdyktu: Krok A (krytyczne) TAK - cytat 🔴 → FAIL. Krok B informacyjnie: (1.0+1.0+0.5+0.25+0.0)/5 = 0.55 (< 0.6).
Poziom pewności po debacie: ŚREDNI (1 filar NIEPEWNY, linia orzecznicza niejednolita w 1 filarze).
Werdykt: FAIL. NIE wysyłaj przed (a) poprawą cytatu 🔴, (b) dodaniem zastrzeżenia do filaru
obalonego, (c) uzupełnieniem dowodu dla filaru NIEPEWNEGO albo jawnym zastrzeżeniem w tekście.
[baner stanu końcowego - przykłady]
- wymuszone_wyjscie_na_v1: „Runda 2 obniżyła wynik_zbiorczy (84 → 79) - przywrócono v1. Blokery: 1 cytat 🔴."
- wymuszone_wyjscie_na_limicie: „3 rundy wyczerpane, blokery zostały: filar III bez odniesienia do orzecznictwa przeciwnego. Dostarczono v3 - decyzja o wysyłce należy do Ciebie."
Pełny zapis debaty (transcript builder/attacker/synthesizer, wszystkie wersje v1..vN)
zwróć jako załącznik do legal-ai-audit-bundle - to dowód kontradyktoryjnej weryfikacji
i ograniczonej rewizji.
let-it-be PRZED uruchomieniem.Kontradyktoryjna weryfikacja + jawny poziom pewności + transcript = operacjonalizacja nadzoru człowieka (art. 14) i dokumentacji (art. 12). Człowiek dostaje nie "gotową odpowiedź", lecz mapę tego, co przetrwało atak i z jaką pewnością - i na tej podstawie decyduje.
matematic-expert-panel = wieloperspektywiczna analiza decyzji biznesowej przez 5-7 person
(produkt warsztatowy dla zarządu). Ten skill = kontradyktoryjny stress-test JEDNEGO prawnego
deliverable (teza vs antyteza vs synteza vs weryfikacja). Panel patrzy wszerz, adversarial w głąb.
Ten skill atakuje deliverable (czy teza wytrzyma kontrargument, PO napisaniu, PRZED wysyłką). [[matematic-prompt-defense-pl]] atakuje system prompt (czy zawiera obronę przed 12 znanymi wektorami OWASP LLM Top 10, PRZED wdrożeniem use case'u). Razem to dwustopniowa brama: prompt zaprojektowany odpornie + deliverable przeczytany kontradyktoryjnie. Warstwę agenta z narzędziami i pamięcią (OWASP ASI) pokrywa [[agentic-risk-asi-pl]].
Pattern (debate + 3-layer verification) zainspirowany przez AnttiHero/lavern (Apache 2.0, ADR-010 w blueprincie Patrona). Role, prompty i 10-punktowa kontrola napisane od zera pod polską procedurę i semantykę. Nie skopiowano 67 promptów agentów Lavern (US common law).
Trzy wzorce dodane w v1.1.0, każdy z AnttiHero/lavern (Apache 2.0), adaptacja od zera: NIEPEWNE jako werdykt pierwszej klasy (sekcja 3), pętla rewizji z twardym limitem 2 rund i przymusową eskalacją (sekcja 4a), deterministyczna funkcja werdyktu z jawnymi wagami (sekcja 4b). Wagi, progi i podkategorie polskie - opracowanie MateMatic.
Czwarty wzorzec dodany w v1.2.0: panel rozbieżności (sekcja 4c) z AnttiHero/lavern
(Apache 2.0, src/mcp/tools/dissent.ts) - pytanie multiple-choice do niezależnych ocen,
split jako FINDING pokazywany verbatim, pętla resolveDissent (autorytet → re-vote →
eskalacja). Adaptacja od zera: źródła autorytetu polskie i unijne (saos-orzecznictwo /
ISAP / eu-sparql-search zamiast CourtListener), wpięcie splitu w werdykt NIEPEWNE i wagę
0.25 zamiast osobnego rejestru panelistów, limit jednej rundy re-vote.
Piąty wzorzec dodany w v1.3.0: ograniczona samorewizja z cofnięciem po regresji (drzewo
wyjścia, v_najlepsza, plateau), poziomy dostępu recenzentów (izolowany/wzbogacony) i zasada
„zawsze dostarcz" ze stanami końcowymi - adaptacja clean-room z gregmos/memoforge (MIT),
koncepcje sterowania pętlą i ról, nie prompty ani kod. Ten sam upstream, który od początku
kredytuje bliźniak adversarial-legal-review-en; port domyka rozjazd bliźniaków. Limit 2 rund
z v1.1.0 zastąpiony: gwarancja „nigdy gorsza wersja" pokrywa też tamten przypadek, a limit
rund jest teraz jawnym parametrem per stawka.
Odsyłacz (nie derywacja): PromptDefense z Microsoft Agent Governance Toolkit (MIT) jako
wskazanie różnicy fazy/scope. Ten skill nie adaptuje stamtąd żadnego wzorca - robi to
matematic-prompt-defense-pl, gdzie siedzi właściwa atrybucja z linkiem do repozytorium.
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
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.
(kodeks cywilny art. 415), (wyrok SN II CSK NN/RR, SAOS).[sprawdź w SAOS].Tag stoi przy linii, której dotyczy. Samo istnienie sygnatury nie wystarcza - treść trzeba sprawdzić.
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.
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).