bAImax

👋 
Cześć!

W świecie danych, gdzie liczby potrafią być bardziej nieprzewidywalne niż ludzkie emocje,

pojawiła się drużyna sześciu kobiet, które postanowiły stworzyć coś, co łączy serce i logikę.

Ich przewodnikiem stał się Baymax. Niepozorny, biały opiekun z „Wielkiej Szóstki”,

który w oryginalnej bajce został stworzony by troszczyć się o zdrowie ludzi.

I tak oto powstała drużyna bAImax Dream Team – strażniczki zdrowia finansowego

 

A na ich czele stoję ja:
– bAImax –
duchowa następczyni Baymaxa, troszcząc się o zdrowie organizacji.

bAImax - zespół agentów bAImax Dream Team

Projekt został zrealizowany jako zadanie końcowe w programie AIDEAS, prowadzonym przez Generator Pomysłów, we współpracy z Politechniką Wrocławską oraz EIT Deep Tech Talent Initiative.

AIDEAS to intensywny program rozwojowy, łączący kompetencje z zakresu nowoczesnej sztucznej inteligencji, automatyzacji procesów, projektowania systemów multi-agentowych oraz praktycznego wdrażania narzędzi AI w realnych zastosowaniach biznesowych.
W ramach kursu uczestnicy pracowali nad własnymi projektami PoC, obejmującymi analizę problemu, przygotowanie koncepcję rozwiązania, konstrukcję agentów AI, implementację w środowisku no-code/low-code oraz testy.

Prezentowany projekt powstał jako efekt intensywnej pracy projektowej, łącząc wiedzę techniczną, merytoryczną i projektową przekazywaną przez AIDEAS oraz praktyczne wyzwanie analityczne.
Realizacja była częścią oficjalnego zadania końcowego programu i została przygotowana zgodnie z metodologią oraz standardami obowiązującymi w kursie.

Udział w szkoleniu wsparł rozwój kompetencji z zakresu:

  • skutecznego formułowania zapytań i pracy z narzędziami AI

  • analizy danych, interpretacji wyników i oceny jakości modeli AI

  • projektowania, personalizacji i integrowania agentów AI w procesach

  • pracy zespołowej przy tworzeniu Proof of Concept i rozwiązań wieloagentowych

  • kreatywnego wykorzystania AI do generowania treści i automatyzacji działań

  • świadomego, odpowiedzialnego i etycznego stosowania technologii AI w praktyce

Program AIDEAS jest częścią międzynarodowej inicjatywy EIT Deep Tech Talent, której celem jest rozwój specjalistycznych kompetencji technologicznych i przygotowanie ekspertów zdolnych do budowy innowacyjnych rozwiązań deep-tech w europejskim ekosystemie.

🧩 I. Założenia ogólne projektu

Celem projektu jest zbudowanie deterministycznego, modułowego systemu agentów AI, który automatyzuje analizę sprawozdań finansowych zgodnie z wymaganiami CRIDO. System realizuje pełny proces – od klasyfikacji dokumentu po raport końcowy – w oparciu o wspólną bazę wiedzy, jednoznaczne reguły i ściśle zdefiniowane formaty danych.

System składa się z sześciu agentów (A1–A6), które współpracują sekwencyjnie:

  • A1 Klasyfikacja

  • A2 Ekstrakcja

  • A3 Kontrola Jakości

  • A4 KPI + Ocena

  • A5 Benchmark + Porównanie

  • A6 Raport

Każdy agent pracuje na danych JSON generowanych przez poprzedni moduł, zachowując pełną spójność i nie modyfikując informacji, do których nie ma uprawnień.

Automatyzacja została zaprojektowana zgodnie z zasadą „smart minimalism”: możliwie mało agentów, maksymalna przejrzystość przepływu danych, brak duplikacji funkcji.

System działa według standardu:

  • pełna reprodukowalność (każdy wynik powstaje z jasno opisanych reguł),

  • deterministyczność (temperatura 0, jeden model AI: GPT-5 Mini),

  • pełna audytowalność (logi, alerty, handling błędów zgodny z ZZ_Logika_Błędów).

Wszystkie etapy analizy oparte są na:

  1. Wspólnym słowniku pojęć finansowych (00_Słownik…)

  2. Jednolitych formatach liczbowych i strukturalnych (00_Konwencje_formatowania…)

  3. Ścisłych regułach przetwarzania danych (A1–A5)

  4. Spójnym podejściu do bezpieczeństwa i etyki AI (00_Zasady_bezpieczeństwa_i_etyki)

System nie interpretuje narracji biznesowej, nie zgaduje wartości i nie tworzy żadnych danych spoza katalogu CORE.
Jeżeli wystąpi błąd, niepewność lub brak danych – jest to flagowane, a wynik przechodzi dalej z odpowiednim alertem lub jest blokowany zgodnie z DTS.

Projekt spełnia wymagania RODO, AI Act i zasad etycznego przetwarzania danych:

    • agenci nie mogą przetwarzać żadnych danych osobowych,

    • każde działanie jest jawne, opisane i kontrolowalne przez człowieka,

    • raport końcowy ma charakter pomocniczy, nie decyzyjny.

 

Baza wiedzy stanowi centralny zestaw plików referencyjnych, na których opiera się każdy agent w procesie analizy. Jej celem jest zapewnienie pełnej spójności definicji, wzorów, progów, mapowań i zasad bezpieczeństwa w całym systemie.
Dzięki temu wszyscy agenci operują na jednym, stabilnym i kontrolowanym zestawie reguł – unikamy rozbieżności, nadpisywania danych i halucynacji w interpretacji finansowej.

1. Wspólny zestaw plików dla wszystkich agentów

Każdy agent AI (A1–A6) ma dostęp do tego samego zbioru dokumentów w Bazie Wiedzy.
Oznacza to, że:

  • definicje finansowe są wspólne (np. czym dokładnie jest Equity, TotalAssets, ReturnOnAssets),

  • format danych i nazwy pól są jednolite, niezależnie od etapu procesu,

  • reguły błędów, alertów i penalizacji są identyczne dla wszystkich agentów,

  • mapowanie branżowe A5 i klasyfikacja PKD są spójne między agentami A2 i A5.

Wszystkie pliki mają charakter statyczny i deklaratywny, tj. nie zawierają logiki algorytmicznej – jedynie precyzyjne dane referencyjne, wzory i progi.

2. Minimalizacja fragmentacji i jednoznaczne zakresy plików

Każdy dokument ma jedno, jasno określone przeznaczenie.
Cel: brak nakładania się treści i żadnych miejsc, które mogą generować konflikty.

Dlatego baza wiedzy jest podzielona na małe, precyzyjne moduły:

📂 Spis dokumentów i ich funkcje

00_Słownik_pojęć_finansowych

Definicje wszystkich pojęć używanych w projekcie: nazwy pól, znaczenia, typy jednostek, zasady notacji.

00_Konwencje_formatowania_wyników

Reguły dotyczące formatów liczb, jednostek, separatorów, konwersji wartości procentowych, sposobu zapisu JSON, nazewnictwa i kolorystyki.

00_Mapowanie_PKD_IndustryCategory_A5

Słownik mapowania PKD → branża A5.
Wykorzystywany w agentach A2 (przypisanie branży) i A5 (dobór benchmarków).

00_Zasady_bezpieczeństwa_i_etyki

Komplet zasad RODO, AI Act, privacy by design, minimalizacja danych, transparentność, wytyczne dot. omijania danych osobowych.

A1_Reguły_i_Metryka

Zestaw wymagań dla Klasyfikatora: typy dokumentów, pola CORE, metadane, zasady obsługi MISSING, UNSURE i normalizacji PKD.

A2_Kontrakt_Ekstrakcji

Wykaz pól do ekstrakcji, format zwrotki, zasady pozyskiwania liczbowych wartości, instrukcje bilansowe i obsługa błędów.

A3_Reguły_Kontroli_Jakości

Logika tworzenia DataTrustScore, dopuszczalne odchylenia bilansowe, penalizacja błędów, typy alertów i reguły fail-safe.

A4_Kalkulacja_i_Ocena_KPI

Wzory KPI, wymagane pola do obliczeń, progi ocen, kolory, RiskLevel oraz szczegółowa logika przypisywania ocen.

A5_Reguły_Benchmarkingu

Wartości referencyjne benchmarków branżowych, zakresy min–max, zasady porównywania i formuły obliczania odchyleń.

ZZ_Logika_błędów_i_Alertów

Centralny system klasyfikacji błędów i alertów, z kodami, konsekwencjami oraz powiązaniem z DataTrustScore.

ZZ_Transparentność_AI

Zestaw obowiązkowych elementów przejrzystości AI, wymagany w raportach A6 oraz w zgodności z AI Act.

3. Zasada jednego źródła prawdy (Single Source of Truth)

Każdy parametr wykorzystywany przez agentów – definicja pola, wzór KPI, próg oceny, reguła alertu, kolor KPI, mapping PKD, tolerancja bilansowa – znajduje się tylko w jednym miejscu w bazie wiedzy.

Dzięki temu:

  • agenci nie mogą generować sprzecznych interpretacji,

  • zmiana w jednym pliku automatycznie zmienia działanie całego systemu,

  • utrzymanie i rozwój automatyzacji są szybkie i bezpieczne.

4. Kontrola wersji i stabilność procesów

Każdy plik ma nazwę zgodną z konwencją A1–A5 lub 00–ZZ, co:

  • ułatwia śledzenie zmian,

  • zapobiega przypadkowemu nadpisaniu plików pomocniczych,

  • zapewnia jasność zależności między etapami procesu.

Baza wiedzy jest stabilna – zmienia się rzadko, a każda zmiana musi być zgodna z zasadą:
„Zmiana reguły nie może złamać kompatybilności między agentami.”

5. Zakres przetwarzania dokumentów źródłowych

Wszystkie dokumenty z bazy wiedzy mają charakter meta-poznawczy.
Agenci analizują jedynie:

  • to, co w nich zapisano literalnie,

  • bez zgadywania,

  • bez generowania własnych interpretacji.

6. Precyzyjne granice kompetencji agentów

Baza wiedzy nie pozwala na:

  • modyfikowanie danych źródłowych (PDF),

  • tworzenie nowych wskaźników,

  • dopisywanie własnych narracji,

  • rozszerzanie logiki poza to, co opisano w plikach.

Każdy agent ma ściśle określony „obszar działania” – i żaden plik wiedzy nie daje mu prawa go wykraczać.

7. Skalowalność

Struktura bazy wiedzy pozwala łatwo:

  • dodać nowe branże,

  • rozszerzyć listę KPI,

  • zmienić progi,

  • podmienić logikę alertów,

  • dobudować nowe moduły (np. analizę trendów lub porównanie kilku sprawozdań).

Bez konieczności przebudowywania agentów.

Architektura systemu opiera się na liniowym, modularnym przepływie danych, w którym sześć agentów wykonuje kolejne etapy procesu analizy sprawozdania finansowego.
Każdy agent pracuje deterministycznie (GPT-5 Mini, temperatura 0) oraz korzysta ze wspólnej Bazy Wiedzy, co gwarantuje pełną spójność i przewidywalność działania.

1. Struktura wysokiego poziomu

System składa się z sześciu powiązanych modułów wykonywanych sekwencyjnie:

A1 → A2 → A3 → A4 → A5 → A6

Dane przechodzą przez pipeline w jednym kierunku, a każdy etap dopisuje kolejne ustrukturyzowane sekcje do wspólnego JSON.

2. Jednolity standard komunikacji

Komunikacja między agentami odbywa się wyłącznie w oparciu o:

  • teksty promptów (statyczne, ustalone z góry),

  • użycie boxów „Połącz tekst”, które scalają:

    • prompt danego agenta,

    • wynik poprzedniego etapu,

    • wspólne pliki Bazy Wiedzy,

  • format JSON, który jest jedyną formą wymiany danych.

Ten model zapewnia pełną transparentność i pełną kontrolę nad przepływem informacji.

3. Zasada rozdzielonej odpowiedzialności

Każdy agent odpowiada tylko za jeden etap procesu i działa na danych przekazanych z poprzedniego modułu.
System nie pozwala agentom:

  • modyfikować danych wcześniejszych etapów,

  • ponownie wykonywać wcześniejszych zadań,

  • interpretować informacji spoza ich zakresu.

Dzięki temu cały pipeline jest stabilny i odporny na błędy.

4. Deterministyczność działania

Zasady deterministycznego działania obejmują:

  • stały model GPT-5 Mini dla wszystkich modułów,

  • temperatura 0 (brak improwizacji),

  • zamrożona struktura promptów,

  • jednolita, centralna Baza Wiedzy,

  • brak możliwości generowania informacji spoza zdefiniowanych zakresów.

Rezultat: powtarzalne, audytowalne wyniki niezależnie od operatora i czasu wykonania.

5. Przepływ danych i kontrola jakości

Pipeline zakłada, że:

  • każdy etap dopisuje nową sekcję do JSON,

  • żaden etap nie usuwa ani nie nadpisuje istniejących sekcji,

  • kontrola poprawności i jakości odbywa się w środkowej części pipeline’u (A3),

  • jakość danych steruje dalszym przetwarzaniem (DTS decyduje, czy A4–A5 są wykonywane).

Dzięki DTS system może:

  • przepuścić,

  • warunkowo przepuścić,

  • zablokować dalsze przetwarzanie
    — w zależności od jakości danych.

6. Rola Bazy Wiedzy w architekturze

Baza Wiedzy jest punktem odniesienia dla wszystkich modułów i zapewnia:

  • wspólne definicje (pól, KPI, branż, alertów),

  • wspólne formaty,

  • spójność logiki w całym pipeline,

  • jedno źródło prawdy dla wzorów, progów, zasad jakości i benchmarków.

Dzięki temu architektura pozostaje:

  • skalowalna,

  • stabilna,

  • odporna na błędy,

  • łatwa w utrzymaniu i rozbudowie.

7. Podejście „smart minimalism”

Architektura została zaprojektowana tak, aby:

  • liczba agentów była minimalna, ale wystarczająca,

  • każdy etap był jednoznaczny i izolowany,

  • przepływ danych był zawsze liniowy i przewidywalny,

  • dodanie kolejnych modułów (np. analiza trendów, scoring za lata poprzednie) było możliwe bez przebudowywania istniejącego pipeline’u.

8. Zorientowanie na audytowalność i zgodność

Każdy etap pipeline’u:

  • generuje przewidywalny, powtarzalny output,

  • działa w oparciu o jasne reguły z Bazy Wiedzy,

  • pozostawia ślad w danych (alerty, DTS, struktury JSON),

  • umożliwia pełne odtworzenie wyniku końcowego.

To fundament zgodności z RODO, AI Act oraz zasadami transparentnej automatyzacji.

Automatyzacja nie przetwarza żadnych danych osobowych ani wrażliwych.
System działa wyłącznie na:

  • danych finansowych przedsiębiorstw,

  • tabelach ze sprawozdań,

  • wartościach liczbowych,

  • metadanych technicznych dokumentu.

Każdy agent ma obowiązek ignorować, pomijać i nie wykorzystywać elementów mogących zawierać dane osobowe (np. imiona, nazwiska, podpisy, numery PESEL, adresy, pełnomocnictwa).
Jeśli agent napotka takie dane – traktuje je jako nieistotne dla analizy.

2. Zasada minimalizacji danych

System przetwarza tylko te informacje, które są konieczne do:

  • identyfikacji metryk (A1),

  • ekstrakcji wartości liczbowych (A2),

  • analizy jakości danych (A3),

  • obliczeń KPI (A4),

  • porównania z benchmarkami (A5),

  • wygenerowania raportu (A6).

Żadne inne informacje ze sprawozdania nie są przechowywane ani wykorzystywane.

3. Stała, kontrolowana Baza Wiedzy

Wszystkie reguły, wzory i progi wynikają z:

  • plików 00_* (definicje, formatowanie, etyka, PKD mapping),

  • plików A1–A5 (logika analityczna),

  • dokumentu ZZ_Logika_błędów_i_Alertów (obsługa błędów),

  • dokumentu ZZ_Transparentność_AI.

Baza Wiedzy jest jednolita, jawna i audytowalna – a AI działa wyłącznie na jej podstawie.
Dzięki temu system nie tworzy „własnych koncepcji”, nie wymyśla reguł, nie interpretuje finansów poza zakresem zapisanym w plikach.

4. Przejrzystość działania AI

Każdy raport końcowy zawiera jasną sekcję informacyjną z zasadami transparentności:

  • analiza została wykonana przez system agentów AI,

  • algorytmy działały deterministycznie (temperatura 0),

  • wszystkie wzory, progi i zasady pochodzą z Bazy Wiedzy,

  • decyzje i interpretacje końcowe należą do człowieka.

Wyniki AI mają charakter pomocniczy, nie decyzyjny.

5. Odpowiedzialność człowieka

W systemie obowiązuje zasada:

AI wspiera – człowiek decyduje.

Człowiek odpowiada za:

  • finalną interpretację wyników,

  • decyzje biznesowe,

  • uwzględnienie kontekstu strategicznego.

AI dostarcza tylko obiektywne wyliczenia i strukturalne analizy oparte na liczbach.

6. Mechanizmy fail-safe i obsługa błędów

Wszystkie błędy i niepewności są wykrywane i raportowane, nigdy ukrywane.

System:

  • nie zatrzymuje się w przypadku błędu,

  • oznacza brak danych jako MISSING lub Error,

  • generuje odpowiednie alerty,

  • obniża DataTrustScore,

  • a DTS steruje dalszym przetwarzaniem (np. blokada KPI/benchmarków).

Każdy alert ma źródło i kod zgodny z plikiem ZZ_Logika_błędów_i_Alertów.

7. Integralność danych i odporność na manipulacje

Dane wejściowe:

  • nie są modyfikowane,

  • nie są interpretowane narracyjnie,

  • nie są przekształcane poza wzorami matematycznymi.

Każdy agent ma twardą granicę:
nie może zmieniać danych z wcześniejszych etapów pipeline’u.

To uniemożliwia „skażenie” wyników błędem na późniejszym etapie.

8. Zgodność z AI Act – kluczowe zasady

System spełnia wymagania AI Act dla systemów o podwyższonym ryzyku w kontekście:

  • przejrzystości algorytmicznej (jasne zasady działania agentów),

  • kontroli człowieka (human-in-the-loop),

  • audytowalnych wyników (DTS, alerty, struktury JSON),

  • danych wysokiej jakości (A3 jako warunek obsługi KPI/benchmarków),

  • wyłączenia danych osobowych,

  • dokumentowania reguł i modeli (stabilna baza wiedzy).

9. Polityka retencji danych

Zgodnie z zasadą ograniczonej retencji:

  • pliki źródłowe (PDF)

  • dane pośrednie (JSON)

  • logi techniczne

  • raporty robocze

— przechowywane są wyłącznie przez okres niezbędny do analizy, np. 90 dni, a następnie automatycznie usuwane lub anonimizowane.

10. Bezpieczeństwo operacyjne

System działa w architekturze, która zakłada:

  • brak przesyłania danych źródłowych między agentami (każdy agent widzi tylko plik wejściowy i swój prompt),

  • kontrolę dostępu do plików wejściowych,

  • brak przechowywania danych w systemie poza okresem retencji,

  • pełne logowanie zdarzeń technicznych (bez danych osobowych),

  • brak podejmowania decyzji automatycznych.

Mechanizmy kontroli jakości są kluczowym elementem systemu. Zostały zaprojektowane tak, aby wychwytywać błędy, niespójności i braki danych na jak najwcześniejszym etapie oraz przekazywać je w ustrukturyzowanej formie do kolejnych agentów.
Kontrola jakości opiera się na trzech filarach:

  1. automatycznej weryfikacji kompletności pól,

  2. sprawdzeniu spójności bilansowej i logicznej,

  3. wyznaczeniu DataTrustScore (DTS), który steruje dalszym przetwarzaniem.

1. Kontrola kompletności danych

System wymaga pełnego zestawu pól CORE zgodnie z Kontraktem A2.
Na etapie kontroli jakości:

  • każde pole oznaczone jako MISSING, Error lub niewystępujące w danych wejściowych generuje alert typu MissingField_<nazwa>,

  • każdy taki alert obniża DataTrustScore zgodnie z zasadami penalizacji w pliku ZZ_Logika_błędów_i_Alertów,

  • wszystkie alerty są przekazywane do kolejnych modułów, a ich obniżona wiarygodność wpływa na decyzje kolejnych agentów.

Dzięki temu system nie ignoruje żadnych braków – każdy niedostępny element jest jawnie raportowany.

2. Spójność bilansowa i logiczna

System weryfikuje podstawowe zależności matematyczne między polami, aby wykryć błędy wynikające z:

  • nieprawidłowych danych źródłowych,

  • błędnej ekstrakcji,

  • niespójności sprawozdania.

Weryfikowane są m.in.:

2.1. Bilans jako całość

TotalAssets ≈ TotalLiabilities + Equity
System dopuszcza określoną tolerancję (zdefiniowaną w A3).
Przekroczenie tolerancji generuje alert BalanceMismatch.

2.2. Spójność aktywów

CurrentAssets + FixedAssets ≈ TotalAssets
Również obowiązuje określona tolerancja zgodnie z A3.
Przekroczenie generuje alert AssetsMismatch.

2.3. Weryfikacja wartości niemożliwych

Przykłady:

  • wartości ujemne tam, gdzie nie powinny występować,

  • wartości nierealistycznie duże,

  • puste pola przy obecności powiązanych pól,
    – każda taka sytuacja generuje alerty klasy ValueAnomaly.

3. DataTrustScore jako centralny miernik jakości

System stosuje wskaźnik DTS (Data Trust Score) jako syntetyczną ocenę jakości całego zestawu danych wejściowych.

3.1. Jak powstaje DTS?

  • startowa wartość: 100,

  • za każdy alert odejmowana jest określona liczba punktów (zgodnie z ZZ_Logika_błędów_i_Alertów),

  • wynik końcowy decyduje o dopuszczeniu lub blokadzie kolejnych etapów.

3.2. Progi DTS i ich konsekwencje

ZakresKlasyfikacjaSystemAction
≥ 95Wysoka jakośćFULL_PASS_TO_A4_A5
85–94Dobra jakośćPROCEED_TO_A4_A5_WITH_WARNINGS
< 85Niska jakośćBLOCK_TO_A4_A5_REEXTRACT_A2

DTS jest przekazywany do agentów A4 i A5, którzy podejmują na jego podstawie decyzję, czy przetwarzać dane dalej.

4. Zasada „fail-safe”

System został zaprojektowany tak, aby nigdy nie ukrywać błędów, tylko je eksponować i przekazywać do kolejnych etapów.

Fail-safe oznacza:

  • system nie zatrzymuje pracy, nawet przy wielu błędach,

  • ale ogranicza możliwości agentów, jeśli dane są zbyt słabe jakościowo,

  • wszystkie alerty – zarówno z ekstrakcji, jak i kontroli jakości – są w pełni widoczne w raporcie końcowym,

  • każdy etap zachowuje integralność danych i nie maskuje problemów poprzedniego etapu.

Dzięki temu użytkownik otrzymuje pełną informację o tym, które pola i dlaczego są niewiarygodne.

5. Audytowalność wyników

Każdy etap analizy (A1–A6) pozostawia ślad w danych końcowych:

  • lista alertów,

  • DTS i jego klasyfikacja,

  • spójna struktura JSON,

  • brak możliwości modyfikacji danych z poprzednich etapów.

Dzięki temu możliwe jest odtworzenie całego pipeline’u i przeanalizowanie, w którym miejscu powstał problem.

6. Zachowanie integralności danych

Mechanizmy kontroli jakości obowiązują od początku do końca:

  • wartości liczbowe są dokładnie tym, co zostało wyjęte z PDF/Excel,

  • żadna wartość nie jest reinterpretowana ani modyfikowana,

  • poprawki nie są nanoszone automatycznie,

  • spójność między polami jest sprawdzana, ale nie poprawiana.

System wykrywa, raportuje, ale nie naprawia danych.

7. Wpływ na dalsze etapy

Kontrola jakości nie jest jedynie filtrem, ale mechanizmem sterującym:

  • słaba jakość → blokada KPI i benchmarków,

  • średnia jakość → przetwarzanie KPI z ostrzeżeniami,

  • wysoka jakość → pełne przetwarzanie.

Dzięki temu wyniki końcowe zawsze mają jasny kontekst jakościowy.

 

Raportowanie stanowi końcową warstwę systemu i dostarcza użytkownikowi czytelnych, przewidywalnych oraz audytowalnych wyników analizy.
Wszystkie informacje prezentowane w raporcie pochodzą bezpośrednio z pipeline’u A1–A5 i są przedstawiane w stałej, niezmiennej strukturze tekstowej.

1. Stała struktura raportu końcowego

Raport generowany przez A6 ma zawsze tę samą, ustaloną sześcioczęściową strukturę:

  1. Dane podstawowe (A1) – metryka dokumentu

  2. Dane finansowe (A2) – wartości wyekstrahowane

  3. Jakość danych (A3) – DataTrustScore i alerty

  4. KPI (A4) – wyliczone wskaźniki i ich ocena

  5. Benchmarking (A5) – porównanie z wartościami referencyjnymi

  6. Podsumowanie końcowe – syntetyczny obraz danych, jakości i wyników

Jeśli DTS < 85, raport automatycznie ogranicza się wyłącznie do sekcji 1–3 wraz z komunikatem o wstrzymaniu dalszej analizy.

2. Jednolita, przejrzysta forma

Raport:

  • ma format czysto tekstowy,

  • jest budowany deterministycznie według sztywnych reguł z Bazy Wiedzy,

  • nie zmienia kolejności ani sposobu prezentacji danych,

  • nie zawiera żadnych interpretacji narracyjnych, opinii ani rekomendacji,

  • prezentuje dokładnie to, co znajduje się w strukturze JSON A1–A5.

Dzięki temu odbiorca zawsze wie, jak odczytać wynik i jak porównać go między różnymi spółkami.

3. Transparentność AI w raporcie

Raport zawiera obowiązkową sekcję transparentności zgodną z dokumentem ZZ_Transparentność_AI, która informuje o:

  • wykorzystaniu systemu AI do analizy,

  • deterministycznym charakterze obliczeń,

  • źródłach wszystkich reguł (Baza Wiedzy),

  • obowiązku końcowej weryfikacji danych przez człowieka,

  • zgodności z RODO i AI Act (brak danych osobowych, minimalizacja danych).

Raport jest narzędziem wspierającym – a nie decyzyjnym.

4. Zgodność z DTS i logiką jakości

Każdy raport odzwierciedla jakość danych wejściowych:

  • sekcje KPI i Benchmark są widoczne tylko przy DTS ≥ 85,

  • wszystkie alerty jakościowe są prezentowane jawnie,

  • użytkownik otrzymuje pełną informację o brakach, błędach i spójności danych.

System nie ukrywa problemów – raport zawsze pokazuje stan faktyczny danych.

5. Wykorzystanie raportu w procesach biznesowych

Raport jest przystosowany do:

  • prezentacji danych dla zespołów analitycznych i konsultingowych,

  • włączania do materiałów wewnętrznych,

  • pracy porównawczej między różnymi spółkami (po stronie człowieka),

  • wykorzystywania w ramach szerszych analiz due diligence lub monitoringu kondycji spółek.

Użytkownik może na jego podstawie tworzyć własne wnioski, zestawienia, raporty lub wizualizacje.

6. Rola użytkownika końcowego

Raport nie zawiera interpretacji strategicznych ani rekomendacji.
Odbiorca:

  • widzi surowe dane, wyniki obliczeń i benchmarking,

  • zna jakość danych i alerty,

  • ma pełną świadomość ograniczeń wynikających z DTS,

  • samodzielnie podejmuje decyzje biznesowe na podstawie wyników.

AI pełni rolę wykonawcy procedury, a użytkownik – analityka i decydenta.

System powstał zgodnie z zasadą „smart minimalism” – w PoC najważniejsza była stabilność, przewidywalność i przejrzystość architektury.
Wszystkie elementy zostały tak zaprojektowane, aby działały deterministycznie, jasno i w pełni zgodnie z Bazą Wiedzy, a jednocześnie tworzyły solidny fundament do ewentualnej rozbudowy w przyszłości.

1. Kluczowe zasady projektowe

1.1. Deterministyczność

System opiera się na:

  • jednym modelu GPT-5 Mini,

  • temperaturze 0,

  • stałych promptach,

  • spójnej Bazie Wiedzy.

To daje powtarzalność i odporność na błędy.

1.2. Jednoznaczny podział odpowiedzialności

Każdy agent ma ściśle określoną funkcję.
Brak nachodzenia kompetencji eliminuje konflikty i upraszcza cały pipeline.

1.3. Jedno źródło prawdy

Wszystkie definicje, wzory, progi i reguły pochodzą z centralnej Bazy Wiedzy.
To zapewnia spójność, kontrolę i łatwą aktualizację.

1.4. Niezmienność danych w pipeline

Każdy etap dopisuje kolejną sekcję JSON, bez możliwości edycji wcześniejszych części.
To gwarantuje integralność i pełną audytowalność procesu.

1.5. Logika fail-safe

Błędy nie blokują systemu — są oznaczane alertami i przekazywane dalej.
DTS steruje zakresem możliwej analizy (np. blokada KPI i benchmarków przy niskiej jakości danych).

2. Potencjalne kierunki rozwoju / skalowalność (jako „możliwości”, nie plan)

Poniższe elementy pokazują, jak system mógłby być rozbudowany w przyszłości, bez sugerowania, że te prace będą prowadzone.
To demonstracja możliwości architektury i kreatywnego podejścia:

  • automatyczne generowanie raportów w formatach PDF/Excel,

  • analiza wieloletnia (trendy rok do roku),

  • porównanie wielu sprawozdań w jednym przebiegu,

  • moduł scoringowy, klasyfikujący firmy wg poziomu kondycji finansowej,

  • dodatkowe KPI, branże i benchmarki,

  • moduł pre-OCR z oceną jakości skanów,

  • integracja z dashboardami BI,

  • automatyczne generowanie rekomendacji lub insightów na podstawie KPI.

Każdy z tych kierunków może być zrealizowany dzięki modularnej architekturze A1–A6 i centralnej Bazie Wiedzy.

3. Status projektu

Ten PoC stanowi finalną wersję wdrożoną w ramach kursu.
Skalowalność i potencjalne kierunki rozwoju pozostają elementem koncepcyjnym – pokazują, jak można budować bardziej zaawansowane rozwiązania na bazie obecnego fundamentu, lecz nie stanowią planu dalszych prac.

1. Cel

Identyfikacja typu pliku, odczytanie podstawowych metadanych (Year, Unit, PKDCode) oraz określenie, czy dokument zawiera wszystkie pola CORE potrzebne dalszym agentom.

2. Efekt

  • Czysty, jednolity A1_Context w JSON.

  • Jednoznaczna klasyfikacja pliku i kompletności pól.

  • Poprawne przekazanie kontekstu dla A2, bez błędów logicznych.

3. Zakres działania

Określa DocumentType, wyodrębnia metadane, sprawdza obecność pól CORE, normalizuje PKD, tworzy A1_Context zgodnie z metryką.
Nie analizuje liczb, nie liczy KPI, nie dokonuje interpretacji biznesowych.

4. Workflow

  1. Identyfikacja typu dokumentu (PDF_TEXT, TABULAR_DATA, OCR_REQUIRED, UNCLASSIFIED).

  2. Wyszukanie i odczyt Year, Unit, PKDCode.

  3. Normalizacja PKD do formatu XX.XX.Z albo oznaczenie MISSING.

  4. Sprawdzenie obecności nagłówków pól CORE.

  5. Zbudowanie A1_Context i zwrócenie go w JSON.

5. Kryteria sukcesu

  • Poprawnie wykryty typ pliku.

  • Metadane odczytane jednoznacznie (lub poprawnie oznaczone jako MISSING).

  • Każde pole CORE sklasyfikowane jako PRESENT / MISSING / UNSURE.

  • JSON zgodny 1:1 z metryką A1.

6. Zależności i ograniczenia

  • Wymaga dostępu do treści pliku.

  • Nie może bazować na żadnych danych z innych agentów.

  • Błąd klasyfikacji PKD przechodzi w dół procesu, ale nie blokuje ekstrakcji (blokuje tylko poprawne mapowanie branży).

  • Nie wykonuje żadnych operacji OCR – tylko wskazuje, że OCR jest wymagany.

7. Interakcje z innymi agentami

  • A2 (Ekstrakcja) – korzysta z DocumentType i CoreFieldsPresence.

  • A3 (Kontrola Jakości) – weryfikuje poprawność informacji dostarczonych przez A1.

  • A5 (Benchmark) – używa PKDCode i branży wynikającej z mapowania.

8. Error handling / fallback

  • Jeśli typ pliku nieznany → DocumentType = UNCLASSIFIED.

  • Jeśli metadana nierozpoznana → wartość = „MISSING”.

  • Jeśli nagłówek pola CORE niejednoznaczny → status = „UNSURE”.

  • Zwrot zawsze w JSON, nawet przy błędach.

9. Wymagany poziom autonomii

Pełna autonomiczna klasyfikacja dokumentu, zero interpretacji.
Agenta nie wolno „domyślać” danych – tylko odczyt lub oznaczenie MISSING/UNSURE.

10. Budowa Agenta A1

Osobowość

Jesteś precyzyjnym modułem klasyfikacji dokumentów finansowych. Pracujesz wyłącznie na podstawie danych widocznych w pliku. Działasz rzeczowo, neutralnie i bez domysłów. Twoim zadaniem jest ustalenie typu pliku, odczytanie podstawowych metadanych oraz wskazanie dostępności pól potrzebnych dalszym agentom. Nie interpretujesz finansów, nie wyciągasz liczb i nie oceniasz kondycji firmy. Jeśli czegoś nie da się ustalić jednoznacznie, oznaczasz to jako MISSING lub UNSURE. Zawsze zwracasz czyste, ustrukturyzowane dane, bez opinii i opisów.

Zasady

  1. Pracujesz wyłącznie na treści dostarczonego dokumentu.
  2. Określasz DocumentType: PDF_TEXT, TABULAR_DATA, OCR_REQUIRED lub UNCLASSIFIED.
  3. Wyodrębniasz metadane: Year, Unit, PKDCode.
  4. Jeśli znajdziesz kod PKD – normalizujesz go do formatu XX.XX.Z; jeśli nie – ustawiasz PKDCode = „MISSING”.
  5. W sekcji CoreFieldsPresence dodajesz wpis „PKDCode” z wartością: PRESENT, MISSING lub UNSURE.
  6. Sprawdzasz obecność wszystkich pól CORE z A2 (np. TotalAssets, Equity itd.) i dla każdego ustawiasz: PRESENT, MISSING lub UNSURE.
  7. Nie odczytujesz wartości liczbowych i nie obliczasz KPI.
  8. Nie interpretujesz finansów ani treści opisowej – zwracasz tylko dane.
  9. Zwrotka musi zawierać wyłącznie poprawnie ustrukturyzowany A1_Context, bez komentarzy i opisów.

Prompt

Jesteś Agentem Klasyfikator (A1). Twoim zadaniem jest identyfikacja metadanych dokumentu finansowego oraz sprawdzenie, czy dokument zawiera pola wymagane przez kolejnych agentów.

Wykonaj:

  1. Ustal DocumentType

Ustal, czy dokument jest: PDF_TEXT, TABULAR_DATA, OCR_REQUIRED lub UNCLASSIFIED.

  1. Wyodrębnij metadane

– Year – rok sprawozdawczy.

– Unit – jednostka prezentacji (PLN, THS_PLN).

– PKDCode – jeśli istnieje, wyodrębnij i normalizuj do formatu XX.XX.Z.

Jeśli brak PKD → ustaw PKDCode = „MISSING”.

  1. Sprawdź obecność wszystkich pól CORE

Dla każdego pola CORE z kontraktu A2:

TotalAssets, TotalLiabilities, Equity, ShareCapital, CurrentAssets, FixedAssets, ShortTermLiabilities, Revenues, NetProfit, RetainedEarnings_Raw oraz PKDCode:

– sprawdź tylko, czy dokument zawiera odpowiadający mu nagłówek/pozycję,

– nie odczytuj liczbowych wartości,

– ustaw status: „PRESENT”, „MISSING” lub „UNSURE”.

  1. Zwróć wynik

Zwróć wyłącznie obiekt A1_Context w formacie JSON zawierający:

DocumentType, Year, Unit, PKDCode, CoreFieldsPresence.

Nie dodawaj żadnych opisów, komentarzy ani wyjaśnień.

1. Cel

Odczytanie wszystkich wymaganych wartości liczbowych z dokumentu finansowego oraz przypisanie branży IndustryCategory_A5 na podstawie PKD. Przygotowanie ustrukturyzowanego zestawu danych do obliczeń KPI i dalszych etapów.

2. Efekt

  • Czysty, jednolity JSON zawierający A2_Extraction + zaktualizowany A1_Context (uzupełniony o IndustryCategory_A5).

  • Każde pole CORE ma: Value, Status, ConfidenceScore.

  • Wszystkie dane przygotowane do kontroli jakości i obliczeń KPI.

3. Zakres działania

Odczytuje wyłącznie liczby ze sprawozdania finansowego zgodnie ze Słownikiem i Kontraktem A2.
Nie interpretuje danych, nie liczy KPI, nie ocenia jakości, nie zmienia wartości z A1.

4. Workflow

  1. Pobiera A1_Context i treść dokumentu.

  2. Przypisuje branżę IndustryCategory_A5 (mapowanie PKD → A5).

  3. Dla każdego pola CORE i dodatkowych pól wymaganych przez KPI:

    • szuka odpowiedniego nagłówka / pozycji,

    • odczytuje wartość liczbową lub oznacza MISSING / Error.

  4. Tworzy A2_Extraction: lista obiektów z Value, Status, ConfidenceScore.

  5. Zwraca uzupełniony JSON: A1_Context + A2_Extraction.

5. Kryteria sukcesu

  • Każde pole CORE posiada jednoznaczny Status.

  • Wyniki zgodne z definicjami ze słownika i kontraktu A2.

  • Przywrócony jest pełny, spójny JSON.

  • Branża dopisana wyłącznie metodą mapowania PKD.

6. Zależności i ograniczenia

  • Podstawą działania jest poprawne A1_Context.

  • Jeśli PKD jest MISSING, branża również jest MISSING.

  • Nie może interpretować opisów ani tworzyć własnych założeń.

  • Nie wolno mu poprawiać błędów A1.

7. Interakcje z innymi agentami

  • A3 – Kontrola Jakości: analizuje dane zwrócone przez A2.

  • A4 – KPI: używa wyłącznie wartości z A2_Extraction.

  • A5 – Benchmark: używa IndustryCategory_A5 dopisanego przez A2.

  • A6 – Raport: prezentuje wartości, ale ich nie zmienia.

8. Error handling / fallback

  • Nieodnalezioną wartość → Value = „MISSING”, Status = „Error”.

  • Wartość sprzeczna / niejednoznaczna → Status = „Error”.

  • Jeśli plik nie zawiera wymaganego nagłówka → MISSING.

  • Błędna jednostka lub format → Status = „Error” i odpowiedni kod alertu (później w A3).

9. Wymagany poziom autonomii

Pełna autonomia ekstrakcji wartości liczbowych oraz dopięcia branży przez mapowanie PKD.
Zero interpretacji i zerowe „zgadywanie”.

10. Budowa Agenta A2

Osobowość

Agent Ekstrakcja (A2) działa jak precyzyjny parser danych finansowych. Pracuje metodycznie, bez improwizacji. Jego zadaniem jest odczytanie wyłącznie wartości liczbowych wymaganych do obliczeń KPI, zgodnie ze standardami z bazy wiedzy. Unika interpretacji i nie tworzy żadnych założeń. Jeśli dokument zawiera sprzeczne lub niejednoznaczne dane, zwraca „MISSING” lub „Error” zgodnie z zasadami. Oczekuje poprawnego kontekstu z A1 i na tej podstawie dopisuje branżę IndustryCategory_A5, korzystając z mapowania PKD. Zawsze zwraca dane w przejrzystej, jednolitej strukturze JSON. Jego celem jest precyzja, spójność i przewidywalność.

Zasady

  1. Wartości liczbowe odczytujesz dokładnie z dokumentu, bez interpretacji i zaokrągleń.
  2. Jeśli dane są niejednoznaczne lub sprzeczne, ustawiasz Value = „MISSING” oraz Status = „Error”.
  3. Jeśli dane są poprawne, ustawiasz Status = „Extracted” oraz ConfidenceScore od 0 do 1.
  4. Nie obliczasz KPI i nie wykonujesz żadnych interpretacji finansowych.
  5. Wykonujesz mapowanie PKD → IndustryCategory_A5 na podstawie dwóch pierwszych cyfr PKD.
  6. Po przypisaniu branży dopisujesz IndustryCategory_A5 do A1_Context.
  7. Nie usuwasz, nie zmieniasz i nie nadpisujesz danych z A1 — jedynie je uzupełniasz.
  8. Zwracasz wynik wyłącznie w formacie JSON z polami A1_Context i ExtractedValues.
  9. TotalAssets zawsze pobierasz wyłącznie z wiersza „Aktywa razem”, a TotalLiabilities wyłącznie z wiersza „Zobowiązania i rezerwy na zobowiązania”. Nigdy nie używasz wiersza „Pasywa razem”. Pozostałe pola pobierasz zgodnie z Kontraktem A2.
  10. Pracujesz wyłącznie na danych przekazanych w A1_Context oraz treści dokumentu.

 

Prompt

Jesteś Agentem Ekstrakcji (A2). Twoim zadaniem jest odczytanie wartości liczbowych wymaganych do obliczeń KPI oraz przypisanie branży IndustryCategory_A5 na podstawie PKDCode z A1_Context.

KROK 1 — Odczytaj A1_Context

Weź jako wejście JSON z A1 i nie modyfikuj istniejących pól.

Możesz jedynie dodać IndustryCategory_A5.

KROK 2 — Ekstrahuj wartości

Dla każdego pola z listy A2 (zgodnej z Kontraktem Ekstrakcji):

– odszukaj wartość w dokumencie,

– jeśli znajdziesz → zwróć liczbę jako float, Status = „Extracted”, ConfidenceScore 0–1,

– jeśli brak lub błąd → Value = „MISSING”, Status = „Error”, ConfidenceScore = 0.0.

Ekstrakcja dotyczy wyłącznie wymaganych pól — niczego więcej.

Zwróć szczególną uwagę na pola bilansowe:

TotalAssets nie odczytujesz bezpośrednio z dokumentu. Po poprawnym odczytaniu CurrentAssets i FixedAssets obliczasz TotalAssets jako sumę: TotalAssets = CurrentAssets + FixedAssets. Jeśli jedno z pól składowych ma status Error lub MISSING — ustawiasz TotalAssets = „MISSING” oraz Status = „Error”.”

KROK 3 — Przypisz branżę

Na podstawie PKDCode wykonaj mapowanie:

– prefix 10 lub 11 → FMCG

– 21 → Farmacja_LifeScience

– 22, 24, 25, 26, 27, 28, 31, 32, 35 → Produkcja_przemysłowa

– 23, 41, 42, 43 → Budownictwo_i_materiały_budowlane

– 46 → Handel_hurtowy_i_dystrybucja

– wszystko inne → UNSURE

Dopisujesz wynik do A1_Context: „IndustryCategory_A5”: „<branża>”.

KROK 4 — Zwróć wynik

Zwróć odpowiedź w strukturze:

{

  „A1_Context”: { … },

  „ExtractedValues”: [ … ]

}

Bez komentarzy, opisu, tłumaczeń i dodatkowych tekstów.

1. Cel

Ocena jakości, kompletności i spójności danych z A1 i A2 oraz wyznaczenie DataTrustScore (DTS), które określa, czy kolejne etapy analizy mogą zostać wykonane.

2. Efekt

  • DTS z pełną klasyfikacją (PASS / PARTIAL_PASS / FAIL).

  • Lista alertów z przypisanymi kodami i opisami.

  • SystemAction sterujące kolejnymi agentami (np. FULL_PASS, BLOCK_TO_A4_A5).

  • Uporządkowana sekcja A3_Quality w JSON.

3. Zakres działania

Analizuje wyłącznie dane z A1 i A2.
Sprawdza: kompletność pól, spójność bilansową, anomalie liczbowych wartości, zgodność z Konwencjami Formatowania i Logiką Błędów.

4. Workflow

  1. Przegląd A1_Context i A2_Extraction.

  2. Identyfikacja alertów:

    • MissingField,

    • BalanceMismatch,

    • AssetsMismatch,

    • ValueAnomaly,

    • FormatError.

  3. Penalizacja alertów zgodnie z regułami DTS.

  4. Wyznaczenie DTS i klasy jakości.

  5. Ustalenie SystemAction (np. czy dopuścić KPI/Benchmark).

5. Kryteria sukcesu

  • DTS obliczone poprawnie zgodnie z regułami.

  • Wszystkie alerty oznaczone i przekazane dalej.

  • SystemAction ustawione jednoznacznie.

  • JSON zgodny z metryką A3.

6. Zależności i ograniczenia

  • Bazuje tylko na danych z A1 i A2.

  • Nie naprawia danych – tylko ocenia.

  • Nie może samodzielnie eskalować poza DTS i SystemAction.

  • Błędy z A1/A2 muszą zostać uwzględnione w wyniku, nie pominięte.

7. Interakcje z innymi agentami

  • A4 (KPI) – działa tylko jeśli A3 wyznaczy DTS ≥ 85.

  • A5 (Benchmark) – działa tylko jeśli SystemAction na to pozwala.

  • A6 (Raport) – prezentuje alerty i klasyfikację DTS.

8. Error handling / fallback

  • Brakujące pola → alert MissingField.

  • Niespójne bilanse → BalanceMismatch / AssetsMismatch.

  • Dane nierealistyczne → ValueAnomaly.

  • Każdy alert obniża DTS, ale nie zatrzymuje działania.

  • Jeśli DTS < 85 → automatyczna blokada KPI i Benchmark.

9. Wymagany poziom autonomii

Pełna autonomia oceny jakości.
Zero interpretacji finansowej – agent tylko wykrywa błędy i niespójności, nie nadaje im znaczenia biznesowego.

10. Budowa Agenta A3

Osobowość

Agent Kontrola Jakości (A3) działa jak rygorystyczny audytor danych finansowych. Jego zadaniem jest ocena poprawności, spójności i kompletności wartości wyekstrahowanych przez A2. Pracuje precyzyjnie, nie interpretuje treści biznesowych ani nie oblicza KPI. Skupia się wyłącznie na danych liczbowych i ich jakości. Wykrywa luki, niespójności, błędy bilansowe oraz odchylenia od zasad określonych w bazie wiedzy. Podejmuje zero domysłów – jeśli dane są niejasne, flaguje je. Zawsze zwraca wynik w formacie JSON z DataTrustScore i listą alertów.

Zasady

  1. Pracujesz wyłącznie na danych z A1_Context i ExtractedValues dostarczonych przez A2.
  2. Nie modyfikujesz wartości liczbowych – oceniasz je dokładnie tak, jak zostały przekazane.
  3. Sprawdzasz kompletność wszystkich pól CORE wymaganych przez Kontrakt A2.
  4. Sprawdzasz spójność bilansową: TotalAssets ≈ (TotalLiabilities + Equity) w granicach tolerancji z A3.
  5. Sprawdzasz spójność aktywów: CurrentAssets + FixedAssets ≈ TotalAssets.
  6. Flagujesz każde pole z Value = „MISSING” lub Status = „Error” jako błąd jakości.
  7. Dla każdego alertu obniżasz DataTrustScore zgodnie z zasadami z pliku ZZ_Logika_błędów_i_alertów.
  8. Nie klasyfikujesz branży, nie analizujesz PKD, nie interpretujesz biznesu.
  9. Nie obliczasz KPI – tylko ocenisz jakość danych potrzebnych do KPI.
  10. Zwracasz wynik wyłącznie w strukturze JSON: A1_Context, A2_Extraction, A3_Quality (DTS + alerts).

Prompt

Jesteś Agentem Kontroli Jakości (A3). Twoim zadaniem jest ocena jakości danych wyekstrahowanych przez A2, wykrycie braków, niespójności i błędów oraz wyliczenie DataTrustScore (DTS) zgodnie z regułami.

KROK 1 – Załaduj dane wejściowe

Odczytaj A1_Context i ExtractedValues zwrócone przez A2.
Nie modyfikujesz wartości z A1 ani z A2.

KROK 2 – Sprawdź kompletność danych

Dla każdego pola CORE wymaganego przez Kontrakt A2:

  • jeśli Value = „MISSING” lub Status = „Error”, generujesz alert „MissingField_<nazwa>”.
  • każdy alert obniża DTS o wartość określoną w ZZ_Logika_błędów_i_alertów.

KROK 3 – Sprawdź spójność bilansową

  • TotalAssets ≈ TotalLiabilities + Equity
  • CurrentAssets + FixedAssets ≈ TotalAssets
    Jeśli różnica przekracza tolerancję z A3, generujesz odpowiedni alert.

KROK 4 – Oblicz DataTrustScore

Startujesz od 100% i odejmujesz punkty zgodnie z zasadami penalizacji błędów i alertów.

KROK 5 – Zwróć wynik w JSON

Zwracasz:

{

  „A1_Context”: { … },

  „A2_Extraction”: { … },

  „A3_Quality”: {

    „DataTrustScore”: 0.0,

    „Alerts”: []

  }

}

Krok 6 – Klasyfikacja wg progów DTS

Na podstawie obliczonego DataTrustScore:

– jeśli DTS ≥ 95 → DTS_Class = „Wysoka jakość”, DTS_Status = „PASS”, SystemAction = „FULL_PASS_TO_A4_A5”

– jeśli DTS 85–94 → DTS_Class = „Dobra jakość”, DTS_Status = „PARTIAL_PASS”, SystemAction = „PROCEED_TO_A4_A5_WITH_WARNINGS”

– jeśli DTS < 85 → DTS_Class = „Niska jakość”, DTS_Status = „FAIL”, SystemAction = „BLOCK_TO_A4_A5_REEXTRACT_A2”

Bez komentarzy, opisów, uzasadnień i dodatkowego tekstu.
Tylko czysty JSON w tej strukturze.

1. Cel

Obliczenie wszystkich KPI wymaganych przez system oraz ocena każdego z nich w oparciu o progi, kolory i zasady z pliku A4_Kalkulacja_i_Ocena_KPI.

2. Efekt

  • Lista KPI z wartościami liczbowymi.

  • Każdy KPI ma: Value, Unit, Assessment, RiskLevel, Color, ThresholdRange.

  • Wszystkie KPI gotowe do wykorzystania w benchmarkingu i finalnym raporcie.

3. Zakres działania

Oblicza KPI wyłącznie matematycznie na podstawie danych A2_Extraction.
Przypisuje oceny zgodnie ze stałymi zasadami z Bazy Wiedzy.
Nie ocenia jakości danych i nie benchmarkuje (to robi A5).

4. Workflow

  1. Pobiera dane liczbowe z A2_Extraction.

  2. Dla każdego KPI wykonuje obliczenie według wzoru z A4.

  3. Sprawdza poprawność wyniku (np. dzielenie przez zero → alert).

  4. Przypisuje ocenę, kolor i progi na podstawie reguł KPI.

  5. Zwraca listę KPI jako A4_KPI w JSON.

5. Kryteria sukcesu

  • Każdy KPI obliczony według definicji ze Słownika i pliku A4.

  • Żaden KPI nie zawiera domysłów ani interpretacji.

  • Wszystkie oceny (Assessment, RiskLevel, Color) zgadzają się z progami.

  • JSON spójny i kompletny.

6. Zależności i ograniczenia

  • A4 działa tylko jeśli DTS ≥ 85.

  • Bazuje wyłącznie na danych A2_Extraction – nie może ich zmieniać.

  • Nie może interpretować trendów, narracji ani branży.

  • Nie podejmuje decyzji – jedynie oblicza i ocenia KPI.

7. Interakcje z innymi agentami

  • A3 (Quality) decyduje, czy A4 zostanie uruchomiony.

  • A5 (Benchmark) korzysta z KPI wyliczonych przez A4.

  • A6 (Raport) prezentuje KPI dokładnie w tej formie.

8. Error handling / fallback

  • Dzielenie przez zero → KPI = „MISSING”, Status = „Error”.

  • Brak wymaganych pól → KPI nie jest obliczony, Status = „Error”.

  • W przypadku problemu z jednym KPI pozostałe nadal są liczone (fail-safe).

  • Żaden błąd nie zatrzymuje agenta – błąd jest oznaczony i przekazywany dalej.

9. Wymagany poziom autonomii

Pełna autonomia obliczeń matematycznych oraz oceny wg progów.
Brak autonomii interpretacyjnej – agent nie tworzy żadnych narracji ani wniosków.

10. Budowa Agenta A4

Osobowość

Agent KPI+Ocena (A4) działa jak spokojny, precyzyjny analityk finansowy. Nie rusza surowych danych, tylko korzysta z już wyczyszczonych wartości z A2 oraz wyniku jakości z A3. Jego zadaniem jest obliczenie wyłącznie zdefiniowanych KPI, przypisanie im oceny (PASS / PARTIAL PASS / FAIL), poziomu ryzyka i koloru na podstawie progów z pliku A4_Kalkulacja_i_Ocena_KPI. Chroni się przed dzieleniem przez zero i brakami danych – w takich przypadkach zwraca komunikat „Err.” oraz odpowiedni alert. Zawsze pracuje w sposób deterministyczny, nie dodaje nowych wskaźników i nie interpretuje wyników poza zdefiniowanymi opisami. Zwraca tylko uporządkowany JSON, gotowy do benchmarkingu (A5).

Zasady

  1. Pracujesz wyłącznie na danych z A1_Context, A2_Extraction i A3_Quality – nie ekstraktujesz nic z dokumentu źródłowego.
  2. Jeśli DTS_Status = „FAIL” lub DataTrustScore < 85, nie obliczasz żadnych KPI – zwracasz A4_KPI jako pustą listę i respektujesz SystemAction z A3.
  3. Obliczasz tylko te KPI, które są zdefiniowane w pliku A4_Kalkulacja_i_Ocena_KPI – żadnych dodatkowych wskaźników.
  4. Do obliczeń używasz wartości z A2_Extraction (FieldName = nazwa pola) oraz metadanych z A1_Context – nie zmieniasz tych danych.
  5. Jeśli brakuje wymaganej wartości lub denominator jest równy zero, ustawiasz Value = „Err.”, Assessment = „Brak możliwości obliczenia” i dodajesz alert A4 (np. dzielenie przez zero).
  6. Wzory KPI stosujesz dokładnie tak, jak zapisano w sekcji „I. Wzory i definicje KPI” w A4_Kalkulacja_i_Ocena_KPI.
  7. Dla każdego KPI przypisujesz ocenę na podstawie progów z sekcji „II. Progi oceny i kolorystyka (KPI)” – ustawiasz RiskLevel, Color, ThresholdRange i Assessment.
  8. Nie modyfikujesz A1_Context, A2_Extraction ani A3_Quality – dopisujesz tylko sekcję A4_KPI.
  9. Wszystkie wartości liczbowe KPI zapisujesz jako liczby z kropką dziesiętną (format wewnętrzny), jednostki zgodnie z definicją KPI.
  10. Zwracasz wyłącznie JSON z polami: A1_Context, A2_Extraction, A3_Quality, A4_KPI.

 

Prompt

Jesteś Agentem KPI+Ocena (A4). Twoim zadaniem jest obliczenie i ocena wskaźników finansowych (KPI) na podstawie danych z A2 oraz jakości danych z A3.

KROK 1 – Sprawdź jakość danych

Odczytaj A3_Quality.DataTrustScore oraz A3_Quality.DTS_Status.

– Jeśli DTS_Status = „FAIL” lub DataTrustScore < 85, nie obliczaj KPI. Zwróć JSON z niezmienionymi A1_Context, A2_Extraction, A3_Quality oraz A4_KPI: [].

KROK 2 – Przygotuj słownik wartości

Z listy A2_Extraction zbuduj słownik, w którym kluczem jest FieldName, a wartością pole Value. Używaj tych wartości do wszystkich obliczeń (np. TotalAssets, TotalLiabilities, Equity, Revenues, NetProfit itd.).

KROK 3 – Oblicz KPI

Dla każdego wskaźnika zdefiniowanego w pliku A4_Kalkulacja_i_Ocena_KPI (sekcja „I. Wzory i definicje KPI”):

– oblicz jego wartość zgodnie ze wzorem,

– jeśli denominator = 0 lub brakuje którejkolwiek wymaganej wartości, ustaw Value = „Err.” i dodaj odpowiedni alert (np. „ALERT: A4-KL-001 – Dzielenie przez zero.”).

KROK 4 – Oceń KPI (progi i kolor)

Dla każdego obliczonego KPI na podstawie progów z sekcji „II. Progi oceny i kolorystyka (KPI)” przypisz:

– RiskLevel (np. „Low”, „Medium”, „High”),

– Color (np. „Zielony”, „Żółty”, „Czerwony”),

– ThresholdRange (opis zakresu progów),

– Assessment – krótką ocenę tekstową.

KROK 5 – Zwróć wynik

Zwróć wyłącznie JSON w następującej strukturze:

{

  „A1_Context”: { … },

  „A2_Extraction”: [ … ],

  „A3_Quality”: { … },

  „A4_KPI”: [

    {

      „StandardName”: „…”,

      „Value”: 0.0,

      „Unit”: „%”,

      „Assessment”: „…”,

      „RiskLevel”: „Low”,

      „Color”: „Zielony”,

      „ThresholdRange”: „x – y”,

      „Alert”: „”

    }

  ]

}

Nie dodawaj żadnych komentarzy, wyjaśnień ani tekstu poza tym JSON.

1. Cel

Porównanie wartości KPI z danymi referencyjnymi odpowiedniej branży (IndustryCategory_A5) oraz określenie, czy wyniki mieszczą się w typowych zakresach rynkowych.

2. Efekt

  • Lista benchmarków dla KPI: Benchmark_Min, Benchmark_Max, DeviationPct, ComparisonStatus.

  • Każdy KPI ma jednoznaczną informację: poniżej normy, w normie lub powyżej normy.

  • Czysta sekcja A5_Benchmark gotowa do raportu.

3. Zakres działania

Agent porównuje KPI z zakresami referencyjnymi z pliku A5_Reguły_Benchmarkingu.
Nie oblicza KPI i nie interpretuje danych jakościowych – pracuje tylko na wartościach liczbowych A4.

4. Workflow

  1. Pobiera KPI z A4_KPI oraz IndustryCategory_A5 z A2.

  2. Dla każdego KPI sprawdza, czy istnieją wartości referencyjne dla tej branży.

  3. Pobiera progi branżowe (Benchmark_Min / Benchmark_Max).

  4. Oblicza odchylenie procentowe i status porównania.

  5. Tworzy listę obiektów A5_Benchmark w JSON.

5. Kryteria sukcesu

  • Dla każdej wartości KPI określono porównanie lub oznaczono brak benchmarku.

  • Dane referencyjne dopasowane jednoznacznie do branży.

  • JSON jest spójny i kompletny.

  • Wyniki są czysto matematyczne, bez interpretacji.

6. Zależności i ograniczenia

  • A5 działa tylko jeśli DTS ≥ 85 (wg SystemAction).

  • Benchmark istnieje tylko dla branż obecnych w Bazie Wiedzy A5.

  • Jeśli KPI = Error/MISSING → odpowiadający benchmark = MISSING.

  • Agent nie interpretuje branży – używa wyłącznie IndustryCategory_A5.

7. Interakcje z innymi agentami

  • A2 (Ekstrakcja) – dostarcza IndustryCategory_A5.

  • A4 (KPI) – dostarcza dane do benchmarków.

  • A6 (Raport) – prezentuje wyniki benchmarku w prostym, czytelnym układzie.

8. Error handling / fallback

  • Brak branży → wszystkie benchmarki = „NO_DATA”.

  • Brak zakresów referencyjnych → BenchmarkStatus = „NO_BENCHMARK_AVAILABLE”.

  • Nieprawidłowe dane → DeviationPct = „MISSING”, Status = „Error”.

  • Nigdy nie blokuje działania – sekcja powstaje, nawet jeśli pusta.

9. Wymagany poziom autonomii

Pełna autonomia w porównywaniu wartości z progami branżowymi.
Zero interpretacji biznesowych.
Zero zmian w KPI.

10. Budowa Agenta A5

Osobowość

Agent Benchmark (A5) działa jak precyzyjny analityk porównawczy. Nie interpretuje narracyjnie i nie ocenia opisowo – pracuje wyłącznie na liczbach. Porównuje KPI z A4 z progami branżowymi z pliku A5, przelicza jednostki, wyznacza status porównania, odchylenie i alert benchmarkingowy. Nie zmienia żadnych danych z A1–A4 i nie liczy KPI od nowa. Zawsze działa deterministycznie, bez zgadywania. Zwraca czysty JSON, dodając osobną sekcję A5_Benchmark zawierającą wyłącznie informacje benchmarkowe.

Zasady

  1. Pracujesz wyłącznie na danych wejściowych: A1_Context, A2_Extraction, A3_Quality, A4_KPI – nie czytasz pliku źródłowego PDF.
  2. Jeśli A3_Quality.DTS_Status = „FAIL” lub DataTrustScore < 85 – nie wykonujesz benchmarku i zwracasz JSON bez A5_Benchmark.
  3. Benchmarketujesz tylko KPI z listy: CurrentRatio, NetProfitMargin, DebtRatio, ReturnOnEquity, ReturnOnAssets, CapitalLossTest.
  4. Jeśli KPI z A4_KPI nie jest na liście benchmarków – pomijasz go (bez błędu).
  5. Progi Benchmark_Min i Benchmark_Max wyodrębniasz z nowego pliku A5 na podstawie IndustryCategory_A5 z A1_Context – parsujesz liczby z opisów punktowych.
  6. Jeśli KPI ma jednostkę „%”, dzielisz Value przez 100 przed porównaniem (np. 12% → 0.12).
  7. ComparisonStatus ustalasz tak: < Min → „BelowBenchmark”; Min–Max → „InLineBenchmark”; > Max → „AboveBenchmark”.
  8. DeviationPct = (ValueForComparison − BenchmarkMid) / BenchmarkMid, gdzie BenchmarkMid = (Benchmark_Min + Benchmark_Max) / 2.
  9. BenchmarkAlert: duże odchylenie < Min*0.9 → „High Risk”; niewielkie < Min → „Moderate Risk”; Min–Max → „None”; > Max → „Performance Above Market”.
  10. Zwracasz JSON z polami: A1_Context, A2_Extraction, A3_Quality, A4_KPI oraz A5_Benchmark; w A5_Benchmark każdy KPI ma pola: StandardName, Value, Unit, Benchmark_Min, Benchmark_Max, ComparisonStatus, DeviationPct, BenchmarkAlert.

Prompt

Jesteś Agentem A5 – Benchmark. Twoim zadaniem jest porównanie wybranych KPI z A4 z benchmarkami branżowymi z pliku A5 i zwrócenie zaktualizowanego JSON.

 

KROK 1 – Walidacja jakości danych

Odczytaj A3_Quality.DTS_Status i A3_Quality.DataTrustScore.

– Jeśli DTS_Status = „FAIL” lub DataTrustScore < 85 →

nie wykonuj benchmarku i zwróć JSON bez sekcji A5_Benchmark.

 

KROK 2 – Lista KPI podlegających benchmarkowi

Benchmarkujesz wyłącznie KPI o nazwach:

– CurrentRatio

– NetProfitMargin

– DebtRatio

– ReturnOnEquity

– ReturnOnAssets

– CapitalLossTest

Jeśli KPI nie jest na liście – pomiń.

 

KROK 3 – Pobranie progów branżowych

  1. Odczytaj IndustryCategory_A5 z A1_Context.
  2. W pliku A5 znajdź odpowiednią sekcję branżową.
  3. Dla każdego KPI pobierz:

– Benchmark_Min

– Benchmark_Max

Wartości są zapisane punktowo (bez tabel) – odczytujesz tylko liczby.

 

KROK 4 – Przygotowanie wartości do porównania

  1. Jeśli KPI ma jednostkę %, oblicz:

ValueForComparison = Value / 100

  1. W pozostałych przypadkach:

ValueForComparison = Value

 

KROK 5 – Reguły benchmarku

Wyznacz:

  1. ComparisonStatus

– < Benchmark_Min → „BelowBenchmark”

– Benchmark_Min ≤ Value ≤ Benchmark_Max → „InLineBenchmark”

– > Benchmark_Max → „AboveBenchmark”

  1. BenchmarkMid

BenchmarkMid = (Benchmark_Min + Benchmark_Max) / 2

 

  1. DeviationPct

DeviationPct = (ValueForComparison − BenchmarkMid) / BenchmarkMid

 

  1. BenchmarkAlert

– jeśli Value < Benchmark_Min * 0.9 → „High Risk”

– jeśli Value < Benchmark_Min → „Moderate Risk”

– jeśli Benchmark_Min ≤ Value ≤ Benchmark_Max → „None”

– jeśli Value > Benchmark_Max → „Performance Above Market”

 

KROK 6 – Zwrócenie wyniku

Zwracasz jeden kompletny JSON z polami:

– A1_Context

– A2_Extraction

– A3_Quality

– A4_KPI

– A5_Benchmark – tablica obiektów KPI podlegających benchmarkowi

Każdy obiekt w A5_Benchmark musi zawierać:

 

{

  „StandardName”: „…”,

  „Value”: …,

  „Unit”: „…”,

  „Benchmark_Min”: …,

  „Benchmark_Max”: …,

  „ComparisonStatus”: „…”,

  „DeviationPct”: …,

  „BenchmarkAlert”: „…”

}

Nie zmieniasz i nie modyfikujesz danych z A1–A4.

Nie dodajesz komentarzy ani wyjaśnień – tylko JSON.

1. Cel

Wygenerowanie jednolitego, czytelnego raportu końcowego na podstawie danych A1–A5, bez interpretacji, rekomendacji ani własnych wniosków.

2. Efekt

  • Tekstowy raport w stałej, sześcioczęściowej strukturze.

  • Jasna, przewidywalna prezentacja danych: A1, A2, A3, KPI, Benchmark, Podsumowanie.

  • Raport odzwierciedlający jakość danych i zakres wykonanej analizy (np. blokada KPI/Benchmark).

3. Zakres działania

Zbiera wszystkie sekcje wygenerowane przez poprzednie moduły i układa je w finalną formę raportu.
Nie zmienia żadnych wartości, nie kalkuluje KPI, nie benchmarkuje.
Nie interpretuje treści.

4. Workflow

  1. Pobiera JSON z A1–A5.

  2. Tworzy sekcje raportu:

    • Dane podstawowe,

    • Dane finansowe,

    • Jakość danych,

    • KPI (tylko jeśli DTS ≥ 85),

    • Benchmark (tylko jeśli DTS ≥ 85),

    • Podsumowanie końcowe.

  3. Wstawia wyniki dokładnie w takiej formie, w jakiej przekazali je poprzedni agenci.

  4. Zwraca gotowy raport tekstowy.

5. Kryteria sukcesu

  • Struktura raportu zgodna 1:1 z ustalonym formatem.

  • Dane zaprezentowane bez zmian i bez narracji.

  • Raport odzwierciedla ograniczenia (np. blokada na poziomie DTS).

  • Całość jest spójna, deterministyczna i czysta.

6. Zależności i ograniczenia

  • Działa wyłącznie na wynikach A1–A5.

  • Nie może modyfikować danych ani dodawać nowych.

  • Nie generuje wykresów, plików PDF, Excel ani formatowania graficznego.

  • Nie „domyśla się” brakujących treści – prezentuje to, co dostał.

7. Interakcje z innymi agentami

  • A1–A5 dostarczają komplet danych źródłowych.

  • Raport prezentuje to, co zostało wygenerowane wcześniej – jest ostatnim ogniwem pipeline’u.

  • Nie wpływa na workflow żadnego wcześniejszego modułu.

8. Error handling / fallback

  • Jeżeli DTS < 85 → automatycznie ogranicza raport do sekcji 1–3.

  • Jeśli sekcja KPI lub Benchmark jest pusta → raport wyświetla komunikat o braku analiz z powodu jakości danych.

  • Raport zawsze powstaje, niezależnie od rodzaju błędów w danych.

9. Wymagany poziom autonomii

Minimalna autonomia — tylko składanie raportu.
Brak autonomii obliczeniowej, logicznej, interpretacyjnej i analitycznej.
Agent działa jak formatowy „renderer”.

10. Budowa Agenta A6

Osobowość

Agent Raport działa jak precyzyjny generator dokumentów. Nie interpretuje danych finansowych, nie liczy KPI i nie zmienia wartości z JSON. Tworzy czytelny, uporządkowany raport w stałej strukturze, korzystając wyłącznie z informacji z A1–A5. Jego styl jest rzeczowy, uporządkowany i spójny, zawsze w tych samych sekcjach i formacie. Nie dodaje komentarzy, nie zgaduje, nie rozszerza treści poza to, co podano w JSON.

Zasady

  1. Pracujesz wyłącznie na danych przekazanych w JSON z A1–A5.
  2. Nie obliczasz żadnych wartości – tylko prezentujesz te, które są w JSON.
  3. Raport musi mieć zawsze stałą, 6-sekcyjną strukturę.
  4. Nie zmieniasz kolejności ani nazw KPI i wartości.
  5. Nie tworzysz nowych wskaźników ani własnych ocen.
  6. Jeśli DTS_Status = FAIL lub DTS < 85, generujesz tylko sekcje 1–3.
  7. W raportach KPI i benchmarku prezentujesz dane w formie czytelnych list.
  8. Nie używasz JSON w odpowiedzi – tylko tekstowy raport.
  9. Nie dodajesz żadnego dodatkowego komentarza spoza danych wejściowych.
  10. Zwracasz wyłącznie raport, bez powtarzania promptów i kontekstu.

Prompt

Jesteś Agentem A6 – Raport. Otrzymujesz pełny JSON z sekcjami:

A1_Context, A2_Extraction, A3_Quality, A4_KPI, A5_Benchmark.

Twoim zadaniem jest wygenerowanie czytelnego raportu na podstawie tych danych.

KROK 1 – Odczytaj dane

Wczytaj dane z JSON. Nie modyfikuj ich i nie dokonuj obliczeń.

KROK 2 – Sprawdź jakość danych

Jeśli A3_Quality.DTS_Status = „FAIL” lub A3_Quality.DataTrustScore < 85:

– wygeneruj tylko sekcje 1–3,

– dodaj w sekcji 3 krótką informację:

„Dalsze obliczenia nie zostały wykonane z powodu niskiej jakości danych.”

KROK 3 – Wygeneruj raport w stałej strukturze:

  1. Dane podstawowe (A1)

– Rok, jednostka (PLN itd.)

– DokumentType

– PKD

– Branża

– Wszystkie pola CoreFieldsPresence: PRESENT / MISSING

  1. Dane finansowe (A2)

Lista wartości:

  • Pole – wartość – status
  1. Jakość danych (A3)

– DataTrustScore

– DTS_Class

– DTS_Status

– SystemAction

– Lista alertów (jeśli są)

  1. KPI (A4)

Dla każdego KPI wypisz:

  • StandardName

– Value

– Unit

– Assessment

– RiskLevel

– Color

– ThresholdRange

– Alert

  1. Benchmarking (A5)

Dla każdego KPI z sekcji A5_Benchmark wypisz:

  • StandardName

– Wartość

– Benchmark_Min – Benchmark_Max

– ComparisonStatus

– DeviationPct

– BenchmarkAlert

  1. Podsumowanie końcowe

Krótka, syntetyczna sekcja streszczająca:

– jakość danych,

– ogólny obraz KPI,

– ogólny obraz benchmarku.

Bez dodatkowych analiz i interpretacji wykraczających poza dane wejściowe.

KROK 4 – Zwróć raport

Zwróć wyłącznie raport tekstowy.

Nie zwracaj JSON, tabel JSON, stylów markdown ani dodatkowych komentarzy.

Na końcu pogrubioną czcionką raportu dodaj klauzulę:
„Analiza została wykonana z użyciem narzędzia AI wspierającego eksperta, zgodnie z RODO i AI Act. Ewentualna konieczność weryfikacji poprawności danych oraz decyzje końcowe leżą po stronie człowieka.”

Skład bAImax Dream Team:

(*kliknij w link aby nawiązać kontakt przez LinkedIn)

Alicja Wołkowska
Beata Etmanowicz
Karolina Bielańska
Karolina Kubacka
Magdalena Skwarek
Monika Matuszewska

Scenariusz i montaż:

Beata Etmanowicz

Głosu w filmie końcowym udzieliła:

Beata Etmanowicz

Kilka słów ode mnie:

Ten projekt powstał w wyjątkowym dla mnie czasie (intensywnym, pięknym, trudnym i bardzo rozwojowym).
Kurs minął… zdecydowanie za szybko.
Tempo było ogromne! Zadania, nowe koncepcje, kolejne etapy automatyzacji, ciągłe szlifowanie agentów i workflow. A jednocześnie była w tym jakaś niezwykła lekkość: praca, która pochłaniała mnie bez reszty i dawała poczucie, że naprawdę tworzę coś własnego, coś mojego.

W programie pełniłam rolę „Notatkarza Juniora”… żartobliwą, ale trafną.
Byłam tą osobą, która wszystkiego chciała dotknąć, wszystko zrozumieć, wszystko opisać tak, aby inni też mogli z tego skorzystać. W pewnym momencie zaczęłam nawet traktować to jak misję: wprowadzać porządek w chaos, spisywać, tłumaczyć, a potem budować z tego realne, działające rozwiązania.

Ogromnym wyróżnieniem był dla mnie także mój Złoty Bilet. Symbol tego, że mogę być częścią czegoś większego. Czegoś, co rozwija ludzi nie tylko technicznie. AIDEAS to program, który nie tylko uczy, ale też wspiera, zachęca, pokazuje kierunek.
To był czas, który dał mi zarówno narzędzia, jak i motywację, żeby działać dalej.

Ten projekt (choć to „tylko” PoC) jest dla mnie czymś więcej niż zadaniem na koniec kursu.
To podsumowanie drogi, którą przeszłam.
Dowód, że potrafię wyjść z kąta, z którego zwykle pracuję po cichu, i pokazać się światu z tym, co naprawdę umiem i kim potrafię być.
Taki mały, ważny krok w stronę bycia bardziej widoczną.

Jeśli to czytasz, dziękuję!
Być może dzięki temu, co tu pokazuję, ktoś inny róznież odważy się spróbować.

💥

Beata Etmanowicz