Intake Sufficiency PL - ocena wystarczalnosci zlecenia
Filozofia
Polowa zlych opinii prawnych to nie blad analizy, tylko zbyt cienkie wejscie. Klient pisze
"sprawdzcie te umowe", po czym okazuje sie, ze nie wiadomo wobec jakiego ryzyka, kto jest druga
strona ani jaki jest cel. Ten skill nazywa to, czego brakuje, ZANIM zacznie sie praca - i zamienia
luki w konkretne pytania do klienta, zamiast w domysly wpisane do deliverable.
Skill nie wykonuje pracy prawnej. Ocenia kompletnosc wejscia i generuje pytania.
Lustro routera
legal-request-router-pl patrzy na zadanie i decyduje, jaka kontrole dac outputowi (grounding / debata / paczka).intake-sufficiency-pl patrzy na zlecenie i decyduje, czy wejscie wystarcza, by zaczac.
Naturalna kolejnosc: najpierw intake-sufficiency (czy mam dosc), potem praca, potem router (jak skontrolowac wynik).
Rubryka wystarczalnosci (6 wymiarow, 0-100)
| Wymiar | Pytanie kontrolne | Waga |
|---|
| Cel | Czy wiadomo, po co klient przychodzi (opinia / audyt / pismo / negocjacja)? | 20 |
| Zakres | Czy zakres jest zdefiniowany (co wchodzi, co nie)? | 20 |
| Podmiot | Czy strony / podmiot sa zidentyfikowane (nazwa, NIP/KRS, rola)? | 15 |
| Fakty | Czy sa dokumenty albo stan faktyczny do oparcia analizy? | 20 |
| Ograniczenia | Czy znane sa twarde ograniczenia (deadline, budzet, poufnosc, jurysdykcja)? | 15 |
| Kryteria sukcesu | Czy wiadomo, co dla klienta znaczy dobry wynik? | 10 |
Werdykt: strong >= 80, adequate >= 50, insufficient < 50.
Workflow
- Pseudonimizuj wejscie przez
let-it-be, jesli zawiera dane objete tajemnica.
- Oceń zlecenie wg 6 wymiarow rubryki - kazdy wymiar ma fakty na poparcie oceny, nie ogolnik.
- Wypisz luki i niejednoznacznosci - co konkretnie jest nieobecne lub niejasne.
- Wyodrebnij premisy prawne klienta - kazde twierdzenie PRAWNE w zleceniu ("termin juz minal",
"umowa jest niewazna, bo brak formy", "przepis X tego zakazuje", "mamy 14 dni na odpowiedz")
to premisa do weryfikacji, nie fakt. Klient moze sie mylic co do prawa, a analiza zbudowana
na blednej premisie jest bledna w calosci, nawet gdy rozumowanie jest poprawne. Kazda premise:
- wypisz osobno z tagiem
[premisa klienta - do weryfikacji u zrodla],
- jesli jest ISTOTNA dla wyniku: zweryfikuj przed startem (SAOS / ISAP /
szukaj-orzeczen-v2 /
tekst umowy) albo dodaj do pytan/instrukcji wstepnych jako pierwsze zadanie,
- jesli weryfikacja ja OBALA: powiedz to wprost i nie kontynuuj na blednym zalozeniu -
nawet jesli klient przedstawil je stanowczo.
- Wygeneruj pytania uzupelniajace - jedno pytanie na luke, kazde przypisane do wymiaru, oznaczone
wymagane/opcjonalne. Pytanie ma byc gotowe do wyslania klientowi, nie notatka dla siebie.
- Zloz szkielet karty zlecenia - cel / zakres / podmiot / ryzyka / kryteria sukcesu / instrukcje wstepne.
Pola, ktorych nie da sie wypelnic z wejscia, zostaja jawnie "(do ustalenia - patrz pytania)".
Schemat wyjscia
{
"wystarczalnosc": {
"score": 45,
"werdykt": "insufficient",
"luki": ["brak zdefiniowanego celu", "podmiot druga strona niezidentyfikowany"],
"niejednoznacznosci": ["'pilne' bez konkretnego terminu"]
},
"premisy_prawne": [
{ "id": "p1", "twierdzenie": "termin na odpowiedz wynosi 14 dni", "istotna": true, "status": "do_weryfikacji", "zrodlo_weryfikacji": "KPC / tekst umowy" }
],
"pytania_uzupelniajace":
Output (dla uzytkownika)
## Wystarczalnosc zlecenia: 45/100 (insufficient)
### Luki
- brak zdefiniowanego celu sprawy
- druga strona niezidentyfikowana (brak nazwy / NIP)
### Pytania do klienta (zadac PRZED rozpoczeciem)
- [wymagane] (cel) Czy oczekuja Panstwo opinii, pisma czy wsparcia w negocjacji?
- [wymagane] (podmiot) Jaka firma jest druga strona (pelna nazwa, NIP/KRS)?
- [opcjonalne] (ograniczenia) Czy jest twardy termin?
### Karta zlecenia (szkielet)
- Cel: (do ustalenia - patrz pytania)
- Zakres: weryfikacja umowy dostawy
- Podmiot: (do ustalenia)
- Instrukcje wstepne: zebrac komplet zalacznikow do umowy
Rekomendacja: NIE zaczynaj analizy merytorycznej przed odpowiedzia na pytania wymagane.
Reguly twarde
- Insufficient = stop, nie zgaduj. Przy werdykcie insufficient nie wypelniaj luk domyslami w deliverable -
najpierw pytania do klienta. Domysl wpisany jako fakt to zarodek blednej opinii.
- Pytanie na luke, nie na zapas. Nie generuj pytan o rzeczy, ktore wejscie juz zawiera.
- Jedno wejscie, jedna ocena. Skill ocenia kompletnosc, nie jakosc merytoryczna sprawy.
- Premisa prawna klienta to hipoteza, nie fakt. Twierdzen klienta o prawie (terminy, zakazy,
niewaznosc, tresc przepisu) nie przenosi sie do karty zlecenia jako ustalen - ida do
premisy_prawne ze statusem do_weryfikacji. Analiza merytoryczna nie startuje na istotnej
premisie, ktorej nikt nie sprawdzil u zrodla.
Ochrona danych (RODO)
Ocena dziala na tresci zlecenia - jezeli zawiera dane objete tajemnica zawodowa, pseudonimizuj przez
let-it-be przed wyslaniem do modelu. Skill nie zapisuje wejscia poza katalogiem sprawy.
Integracja z AI Act
Jawne nazwanie luk i niejednoznacznosci na wejsciu to element nadzoru czlowieka (art. 14) - czlowiek
swiadomie decyduje, czy zaczac z niepelnym wejsciem, zamiast dostac deliverable udajacy kompletnosc.
Ocena wystarczalnosci moze trafic do legal-ai-audit-bundle jako uzasadnienie startu sprawy.
Atrybucja
Pattern (analiza wystarczalnosci briefu: score + luki + pytania uzupelniajace + karta zlecenia)
zainspirowany przez AnttiHero/lavern (Apache 2.0, src/api/briefing/briefing-schema.ts). Rubryka
6 wymiarow, schemat i reguly napisane od zera pod polski kontekst kancelaryjny. Nie skopiowano kodu Lavern.
