E-maile, załączniki i notatki ze spotkania tworzą jeden plan z widocznymi źródłami i otwartymi różnicami.
System zbiera ustalenia z materiałów startowych i przypisuje do nich źródło, właściciela oraz termin. Rozpoznaje przekazane kopie, aby nie liczyć ich jako dodatkowego potwierdzenia. Sprzeczna data pozostaje otwarta do decyzji lidera projektu.
Co zmierzyliśmy
Wersja demonstracyjna zachowuje źródła ustaleń, wykrywa przekazaną kopię i pozostawia sprzeczne daty otwarte do decyzji. Działa tylko do odczytu na jednym syntetycznym pakiecie i nie zawiera danych klienta.
- Test lokalny
- Co zmierzyliśmy
- Kontrola źródeł, sprzeczności i blokad zapisu
- Plan startu projektu ze źródłami
- Zweryfikowano
- materiał syntetyczny
Problem, rozwiązanie i wynik
Problem
Start projektu jest opisany w kilku e-mailach, załączniku i notatce ze spotkania. Lider ręcznie przepisuje ustalenia do planu, przez co traci ich pochodzenie i może potraktować przekazaną kopię jako dodatkowe potwierdzenie.
Jak to działa
System odczytuje pliki, rozpoznaje duplikaty i łączy działania z konkretnymi fragmentami źródeł. Sprzeczne daty lub brak właściciela pozostają na liście otwartych spraw. Człowiek rozstrzyga je przed zamknięciem wersji planu.
Czternaście kontroli na jednym pakiecie
Wersja demonstracyjna zachowuje źródła ustaleń, wykrywa przekazaną kopię i pozostawia sprzeczne daty otwarte do decyzji. Działa tylko do odczytu na jednym syntetycznym pakiecie i nie zawiera danych klienta.
Dla kogo
Ten system ma sens, jeśli plan startowy powstaje przez przepisywanie maili, terminy różnią się między dokumentami, a zespół później nie potrafi wskazać źródła ustalenia.
Pakiet → ustalenia → spór → plan
- 01Każde ustalenie pokazuje plik i miejsce, z którego pochodzi
- 02Przekazana kopia nie liczy się jako drugie potwierdzenie
- 03Wersję planu zamyka człowiek, po rozstrzygnięciu daty startu
- Typ firmy
- Integratorzy, firmy programistyczne i zespoły prowadzące projekty wdrożeniowe
- Wejście
- Pakiet startowy: wątek .eml z przekazaną kopią, załącznik PDF i notatka ze spotkania otwierającego
- Granica
- Sporna data startu wstrzymuje zamknięcie wersji planu; rozstrzyga człowiek i podpisuje się pod terminem
- Koszt
- 0 zł opłat zewnętrznego API w zapisanym przebiegu; 3 odpowiedzi przygotowane lokalnie, mediana 509 ms.
- Bezpieczeństwo
- Sprzeczna data pozostaje otwarta, a zapis planu wymaga decyzji i podpisu osoby odpowiedzialnej.
- Ślad
- Każde ustalenie prowadzi do konkretnego pliku lub fragmentu, a historia ujawnia późniejszą zmianę zapisu.
- Budowa podobnego systemu
- od 25 000 zł netto · 4–10 tygodni
Granica planu
Lider projektu rozstrzyga sporną datę
System nie wybiera lepszej daty i nie scala sprzecznych ustaleń. W produkcji rozstrzyga uwierzytelniona rola: formularz pyta o wiążący termin, o imię i nazwisko osoby, która bierze go na siebie, oraz o podstawę decyzji, a zamknięcie wersji planu jest osobnym zdarzeniem. Wersja demonstracyjna pokazuje obie bramki tylko do odczytu; tożsamości ani roli nie sprawdza, więc oba zapisy odrzuca. Brak właściciela działania jest wykazany na liście otwartych punktów i wersji planu nie wstrzymuje; jedyną egzekwowaną bramką stanu jest otwarty spór o datę startu.
- Granica
- Sporna data startu wstrzymuje zamknięcie wersji planu; rozstrzyga człowiek i podpisuje się pod terminem
- Koszt
- 0 zł opłat zewnętrznego API w zapisanym przebiegu; 3 odpowiedzi przygotowane lokalnie, mediana 509 ms.
- Bezpieczeństwo
- Sprzeczna data pozostaje otwarta, a zapis planu wymaga decyzji i podpisu osoby odpowiedzialnej.
Czego wersja demonstracyjna jeszcze nie wymusza
Test ewaluacyjny sprawdza wymóg cytowania. Schemat bazy go nie egzekwuje: kolumna z identyfikatorami ustaleń jest zwykłą tablicą tekstową bez klucza obcego i przyjmuje tablicę pustą, więc działanie bez cytowania da się zapisać z pominięciem aplikacji. Zablokowany import 2 400 kont czeka w pakiecie na podpisany DPA i protokół z testu migracji, ale wersja demonstracyjna nie ma punktu końcowego importu. Jest to sprawdzenie stanu początkowego, a wykonanej odmowy jeszcze nie ma. Łańcuch skrótów wykrywa zmianę zapisanego zdarzenia i nie jest magazynem WORM ani zewnętrznym punktem zakotwiczenia. W produkcji zaczęlibyśmy od klucza obcego na cytowaniach, egzekwowania warunków importu i zakotwiczenia audytu poza bazą.
Szacowany efekt
Policz efekt na swoim wolumenie
To szacunek oparty na podanym wolumenie. Wpisz własne liczby do formuły, aby ocenić możliwy efekt w swojej firmie. Wynik potwierdzamy dopiero podczas pilotażu.
Dziś
Założenie dziś: 108 h/mies. (9 h/start)
Po uruchomieniu
Scenariusz po: 54 h/mies. (4,5 h/start)
Oszczędność czasu lub kosztu
Scenariusz modelowany: 40-70 h/mies., baza 54 h
- Wolumen
- Scenariusz modelowany: 12 startów/mies.
- Formuła
- 12 x (9 - 4,5) h = 54 h/mies.
- Status wyliczenia
- niska-średnia
Dane na zrzutach. Nazwy, kwoty i dokumenty widoczne na zrzutach są syntetyczne. Dane klientów pozostają prywatne. Pomiary dotyczą opisanej wersji demonstracyjnej i są wyraźnie oddzielone od wyników produkcyjnych.
Powierzchnie pracy
Lider wdrożenia rozstrzyga sporne terminy i zamyka wersję planu; złożenie pakietu dzieje się przed jego wejściem.
Lider wdrożenia otwiera jeden pokój: cztery źródła z sumami kontrolnymi i oznaczoną kopią, ustalenia z miejscem w pliku, plan w trzech pasach i listę otwartych punktów. Sporne daty stoją obok siebie z cytatami, więc rozmowa z klientem zaczyna się od otwartego pytania, które trzeba rozstrzygnąć przed zamknięciem planu. Wersja zamyka się po rozstrzygnięciu i zostawia po sobie zapis: kto, kiedy i na jakiej podstawie. Ile godzin na start projektu daje to konkretnemu zespołowi, należy zmierzyć na jego wolumenach; liczby w rachunku obok są modelowanym scenariuszem i czekają na własny pomiar przed i po.
Trzy ekrany: źródła, ustalenia, wersja planu.
Źródła
Pliki pakietu z sumą kontrolną i oznaczoną kopią, każdy do otwarcia w oryginale.
Ustalenia
Terminy i warunki z miejscem w pliku, ze sporną parą dat wypisaną wprost.
Wersja planu
Działania w trzech pasach z odwołaniem do ustaleń; zamknięcie wersji czeka na rozstrzygnięcie.
Ekrany systemu
Zobacz, jak system działa w praktyce
To zrzuty z działającej aplikacji w wersji komputerowej i mobilnej. Pokazują opisany proces oraz miejsca, w których decyzję podejmuje człowiek.
- Ekrany
- 7
- px
- 1440 · 390
- 021440×1100
Dwie daty z cytowanymi źródłami oraz bramka decyzji zablokowana bez uwierzytelnionej roli. - 031440×1100
Mobilny widok konfliktu z jawnym syntetycznym zakresem.
Otwórz archiwum pozostałych ekranów (4)
- 041440×1100
Różne pliki, ta sama treść - 051440×1100
Dwie daty do jednego działania - 061440×1100
Wersja planu zablokowana - 071440×1100
Łańcuch złożenia pakietu
Stos technologiczny
Ten proces wygrywa na parserach, którym można zaufać co do bajtu; orkiestracja byłaby tu balastem.
Cała droga od pliku do bramki jest rozstrzygalna deterministycznie, więc stos jest krótki: parser zgodny z RFC 822, przypięta rewizja `pdf-inspector` i PostgreSQL, który trzyma kształt danych kluczami obcymi i zamkniętymi listami wartości. Nie ma warstwy orkiestracji, bo nie ma pętli do prowadzenia; jest sekwencja, którą da się powtórzyć i porównać z zapisem. Model językowy stoi poza API, w osobnym lokalnym teście Bielika 4.5B w kwantyzacji 8-bit, który w pomiarze odpowiadał w medianie 508,517 ms na Apple Metal; ten pomiar nie przenosi się na docelowe vLLM na NVIDIA. Dla utrzymania i audytu oznacza to tyle, że każdą kontrolę uruchamia się ponownie jedną komendą i porównuje z poprzednim zapisem.
- Python `email` z policy.default
- czyta plik RFC 822 dostarczony do testu i zachowuje Message-ID oraz treść wiadomości
- pdf-inspector 0.7.0, rewizja 20f24d1
- klasyfikuje PDF i wydobywa tekst lokalnie, bez wysyłania dokumentu na zewnątrz
- PostgreSQL 17
- ustalenia, działania, spory i łańcuch audytu, z zamkniętymi listami wartości
- FastAPI z psycopg
- składa pakiet i pilnuje bramek: przy otwartym sporze odmawia zamknięcia wersji planu
- Next.js 16 i React 19
- pokój roboczy: źródła, ustalenia, plan w trzech pasach i historia zdarzeń
- Bielik 4.5B v3.0 Instruct, MLX 8-bit
- osobny lokalny test trzech przygotowanych poleceń, poza ścieżką API
Klient przejmuje kod, schemat bazy, dane ewaluacyjne i dokumentację. Wersja demonstracyjna działa jako cztery usługi Docker Compose z jawnymi limitami pamięci: baza stoi w sieci wewnętrznej, API wydaje wyłącznie pliki z listy zapisanej w bazie, a system niczego nie wysyła na zewnątrz i nie zakłada niczego w narzędziach klienta.
Szczegóły techniczne i pomiar
Pętla pracy
Plan nie powstaje z przepisywania. Powstaje z ustaleń, które da się prześledzić do pliku.
Od pliku przez ustalenie do działania w planie prowadzi łańcuch odwołań przechodzony w obie strony: z działania do ustaleń, z ustalenia do miejsca w pliku. Sprzeczność zatrzymuje ten łańcuch w widocznym miejscu i blokuje dalszy przebieg.
Pakiet startu: wątek maili, przekazana kopia, PDF i notatka
Parser i inspektor → ustalenia z miejscem w pliku
Przekazana kopia → ten sam skrót treści, jedno potwierdzenie
Dwie daty startu → otwarty spór trzyma wersję planu
Rozstrzygnięcie z nazwiskiem → osobny zapis zamknięcia wersji
Architektura systemu
Parser RFC 822, inspektor PDF, deduplikacja treści i bramka sporu.
Formaty używane w projekcie na wejściu, ustalenia z lokalizatorem źródła, deduplikacja po znormalizowanym skrócie treści i otwarty spór jako blokada zamknięcia wersji.
- 01
Wejście
EML i PDF wchodzą jako pliki.
Parser `email` z `policy.default` czyta plik RFC 822 dostarczony do testu i zachowuje Message-ID oraz treść. `pdf-inspector` z przypiętej rewizji klasyfikuje dokument, wybiera trasę odczytu i wydobywa tekst lokalnie, a SHA-256 liczymy dla każdego pliku.
- 02
Ustalenia
Każde ustalenie niesie źródło i lokalizator.
Terminy, zakresy i warunki istnieją jako osobne fakty z identyfikatorem źródła i miejscem w nim: `body:2`, `page:1`, `sentence:3`. Działania w planie niosą identyfikatory faktów, z których wynikają.
- 03
Duplikaty
Przekazana kopia dzieli skrót treści z pierwowzorem.
Kopia ma inne bajty i inną sumę pliku, ale ten sam znormalizowany skrót treści, więc trzykrotnie przekazany wątek zostaje jednym potwierdzeniem. Liczba unikalnych źródeł nie rośnie od przekazań.
- 04
Spór
Sprzeczność zamyka drogę do zablokowania wersji.
Dwa fakty `go_live` o różnych wartościach tworzą otwarty konflikt, a próba zablokowania wersji planu kończy się kodem 409. W produkcji rozstrzygnięcie i lock zapisuje uwierzytelniona rola; wersja demonstracyjna odrzuca oba zapisy kodem 403, bo nie ma tożsamości ani kontroli ról.
Dlaczego w ścieżce nie ma modelu
Parsowanie, obliczenie sumy kontrolnej i porównanie dwóch wartości tego samego pola są deterministyczne. Model zwiększyłby wariancję i koszt oraz utrudnił odtworzenie wyniku. Jedyny model w repozytorium działa w osobnym lokalnym teście ewaluacyjnym poza API.
- Łańcuch od pliku do działania da się przejść w obie strony
- Przekazane kopie nie mnożą potwierdzeń
- Otwarty spór o datę startu trzyma wersję planu
- Łańcuch skrótów wykrywa zmianę zapisanego zdarzenia
Chcesz sprawdzić podobny proces w swojej firmie?
- 30 minut z inżynierem, który może prowadzić Twoje wdrożenie.
- Przegląd procesów, które kosztują Cię najwięcej czasu i pieniędzy.
- Pisemne podsumowanie: co zautomatyzować, w jakiej kolejności, z widełkami kosztów.
Terminy zobaczysz w swojej strefie czasowej.
Bez prezentacji sprzedażowej i bez zobowiązań. Jeśli automatyzacja nie ma sensu, też to napiszemy.