Każda praca — finansowa, prawna, produktowa, operacyjna — przechodzi przez cztery warstwy. Czasem świadomie, częściej niejawnie. Większość narzędzi obsługuje jedną lub dwie i miesza resztę w jeden strumień: czat, e-mail, folder. To strumień jest tym, co nazywamy „pracą" — choć w rzeczywistości jest tylko jej cienką podszewką.

Decision Interface jest zbudowane wokół tych warstw. Nie jako metafora, ale jako konkretna architektura — z osobnymi obiektami, regułami i widokami dla każdej.

Co znaczy „warstwa"

Analogia: TCP/IP. Każda warstwa robi jedną rzecz, abstrahuje się od poniższej. Gdy HTTP nie działa, sprawdzasz HTTP — nie TCP. Każda warstwa ma własny język, własne błędy, własne narzędzia diagnostyczne. Dzięki temu skomplikowane systemy są w ogóle utrzymywalne.

W pracy tak samo. Cztery oddzielne abstrakcje, każda z własną logiką. Gdy decyzja jest zła, sprawdzasz warstwę decyzji — nie wszystkich wiadomości w Slacku.

Cztery warstwy

  • Kontekst — co wiemy. Aktywny stan: źródła, decyzje wcześniejsze, otwarte pytania, terminy.
  • Struktura — jak to organizujemy. Hierarchia: projekt, artefakt, sesja. Każda rzecz ma swoje miejsce.
  • Decyzja — który wariant wybieramy. Warianty, ryzyko, decydent, data. Punkt, w którym kierunek się rozstrzyga.
  • Wykonanie — co robimy. Czyn fizyczny lub cyfrowy: dokument, transakcja, wiadomość, kod. Output dalej w świat.

Kontekst — co wiemy

Kontekst to nie historia. Historia jest chronologiczna i ulotna; każda nowa wiadomość przesuwa starsze w górę. Kontekst jest aktywnym stanem: co teraz wiemy, jakie są źródła, jakie decyzje już podjęliśmy. Pisaliśmy o tym osobno w tekście Pamięć projektu zamiast historii czatu.

W DI warstwa kontekstu jest persistowana w trzech poziomach: projekt (cały zakres), artefakt (konkretny dokument), sesja (bieżąca praca). Każdy poziom ma własny czas życia i własną politykę retencji.

Struktura — jak to organizujemy

Surowy materiał nigdy nie wystarcza. Pomysły, dokumenty, fragmenty rozmów — bez struktury są szumem. Człowiek może utrzymać kilka rzeczy w głowie naraz; powyżej tego potrzeba zewnętrznej organizacji.

Struktura w DI nadaje hierarchię: co jest projektem (długi horyzont), co artefaktem (konkretny wynik), co sesją (godzinna praca). Bez tej hierarchii nawet najlepszy kontekst rozsypuje się — wszystko leży obok wszystkiego.

Decyzja — który wariant wybieramy

Decyzja nie jest produktem ubocznym pracy. Jest jej osią — punktem, w którym kontekst i struktura zamieniają się w kierunek. Opisaliśmy ją szczegółowo w tekście Decyzja jako pierwsza klasa interfejsu.

W DI decyzja jest osobnym obiektem: warianty, ryzyko, decydent, data, konsekwencje. Jeśli decyzji nie ma jako obiektu, nie nastąpiła — niezależnie od tego, kto co powiedział w jakim wątku.

Wykonanie — co robimy

Wykonanie jest tym, co świat widzi: podpisana umowa, wysłana faktura, wdrożony kod, opublikowany raport. To moment, w którym praca opuszcza środowisko i zostawia ślad poza nim.

Ale wykonanie nie jest punktem końcowym. Każde wykonanie wraca do warstwy kontekstu jako nowy stan: „faktura wysłana, kontrahent powiadomiony, oczekiwana płatność do 30 dni". Pętla zaczyna się od nowa — nowy kontekst, nowa struktura, nowa decyzja, nowe wykonanie.

Cztery warstwy. Cztery języki. Jedno środowisko.

Czemu czat nie wystarcza

W czacie wszystkie cztery warstwy mieszają się w jeden strumień wiadomości. Kontekst leży obok wykonania, decyzje toną pomiędzy nieformalnymi pytaniami, struktury nie ma — pisaliśmy o tym w Dlaczego AI nie jest kolejnym oknem czatu.

DI rozdziela ten strumień na cztery dystynktne powierzchnie pracy. Każda ma własny widok, własne reguły, własny moment w cyklu. Czat zostaje — jako jedno z wejść — ale przestaje być centrum.

Co to znaczy w praktyce

Dla zespołu finansowego cykl wygląda tak: kontekst (poprzednie cash flow, ostatni audyt, regulacje), struktura (projekt „zamknięcie kwartału", artefakt „bilans Q1"), decyzja (zatwierdzenie wydatku przekraczającego próg), wykonanie (wystawienie polecenia przelewu w systemie). Każda warstwa ma własny ekran i własną historię.

Dla zespołu prawnego analogicznie: kontekst (akty prawne, orzecznictwo, wewnętrzne wytyczne), struktura (sprawa, pisma, terminy procesowe), decyzja (strategia obrony), wykonanie (złożenie pisma, mowa końcowa, ugoda).

Dla zespołu produktowego: kontekst (badania, dane użytkowników), struktura (epic, story, sprint), decyzja (priorytet w roadmapie), wykonanie (release).

Po co taka mapa

Bo bez niej nie wiadomo, gdzie szukać problemu. Gdy w projekcie coś nie działa — czy to brak kontekstu (nie wiemy, co już jest)? Czy zła struktura (nie wiadomo, gdzie co leży)? Czy nieudana decyzja (zły wariant)? Czy słabe wykonanie (decyzja była dobra, ale czyn niezrealizowany)?

Cztery warstwy nadają temu język. Pozwalają zatrzymać się i powiedzieć: tu konkretnie pęknięcie. W DI ten język jest wbudowany w produkt — nie jest abstrakcją w prezentacji, tylko strukturą, w której naprawdę pracujesz.