Stan bieżący i zapis: dwie pamięci systemu operacyjnego firmy

Kontrolerka kredytowa otwiera skrzynkę zatwierdzeń. Agent proponuje zwolnienie wstrzymanego zamówienia: klient opłacił rano dwie przeterminowane faktury, otwarte saldo mieści się w limicie, propozycja powołuje się na obie płatności. Zatwierdza. Trzy miesiące później klient kwestionuje opłatę, a audytor zadaje proste pytanie: co system wiedział tego dnia o 9:14 i kto zdecydował?

Moduły odpowiedzą na pierwszą połowę tylko wtedy, gdy od tamtej pory nic nie zostało nadpisane. Tabela płatności pokazuje dzisiejsze saldo, nie poranne. Zamówienie pokazuje obecny status, nie ten, który widział agent. Sama propozycja zniknęła ze skrzynki, bo została wykonana. System, w którym agenci proponują, a ludzie zatwierdzają, wytwarza decyzje w tempie, przy którym „odtworzymy to” przestaje być odpowiedzią. Potrzebuje drugiej pamięci.

Dlaczego magazyn modułów nie może być jedyną pamięcią

Magazyn pod modułami jest zbudowany do jednego: bezpiecznie zmieniać bieżący stan firmy. Jedno zamówienie, jedna blokada, jedna transakcja, indeksy dostrojone do szybkiego znalezienia jednego wiersza. Dokładnie taki ma być i nic tutaj nie sugeruje, żeby go zastępować.

Superinteligencja zadaje tym samym danym inne pytania, a każde z nich obciąża ten magazyn inaczej.

Czytanie w dużej skali. Propozycja dotycząca jednego klienta czyta tysiące wierszy z zamówień, faktur, płatności i reklamacji. Model oceniający ryzyko dostaw dla całego portfela zamówień czyta miliony. Odczyty tej wielkości konkurują z transakcjami, które magazyn ma chronić.

Historia. Magazyn trzyma to, co jest prawdą teraz. Większość pytań do agenta dotyczy zmiany: jaki był limit, gdy przyjmowano zamówienie, od jak dawna ten dostawca się spóźnia, czy marża na tym kliencie spada trzeci kwartał. Magazyn, który nadpisuje, nie odpowie; pamięć, która trzyma wersje, odpowie.

Cała firma naraz. Zamówienie jest w handlu, reklamacja w obsłudze klienta, paleta w magazynie, postój w operacjach. W jednym systemie operacyjnym dzielą jeden model danych i to jest sens tego systemu. Nadal jednak nie dzielą wygodnego miejsca, w którym da się to wszystko przeczytać naraz bez dotykania tabel, do których moduły właśnie piszą.

Co widział agent. Propozycja daje się obronić tylko wtedy, gdy dane, z których powstała, da się później pokazać dokładnie takimi, jakie były. To wymaga migawki, nie bieżącej wartości.

Odpowiedzią Hurukana są dwie pamięci pod jedną ontologią: stan bieżący, który moduły zmieniają co sekundę, i zapis — niezmienna, wersjonowana historia każdego zdarzenia, każdej propozycji i każdej decyzji. Warstwa Data, która trzyma obie, jest w budowie; poniżej jest to, jak ją projektujemy.

Z czego zbudowany jest zapis

Zapis nie jest produktem. To trzy decyzje, każda podjęta raz.

Formaty plików są cegłami. Każde zdarzenie i każda migawka tabeli trafiają do plików w otwartym formacie. Wiersze, które wędrują między modułami i konektorami, idą jako Apache Avro, gdzie schemat podróżuje z danymi, a zgodność między piszącym i czytającym jest formalną regułą. Dane, które leżą i są czytane kolumnami, idą jako Apache Parquet, gdzie pytanie o dwie kolumny z milionów wierszy dotyka dwóch kolumn. Który format do którego zadania — o tym jest tekst Parquet i Avro: zdarzenie między modułami i zapis, który czyta superinteligencja.

Format tabeli jest planem. Same pliki to sterta. Format tabeli — Delta Lake, Apache Iceberg, Apache Hudi, Apache Paimon — trzyma metadane mówiące, które pliki składają się na tabelę w danej chwili, jaki ma schemat i jak się zmieniała. Ponieważ samych plików nigdy się nie edytuje, każda wersja tabeli pozostaje czytelna: stąd bierze się podróż w czasie, a z nią odpowiedź na pytanie „co widział agent o 9:14”. Wybór między nimi jest wyborem śladu audytu i zapada w tekście Ślad audytu to tabela: Delta Lake, Iceberg czy Hudi.

Katalog mówi, gdzie jest prawda. Coś musi trzymać wskaźnik na bieżącą wersję każdej tabeli i rozstrzygać, kto może ją czytać. Ten katalog, nie pliki, jest miejscem, w którym suwerenność wygrywa się albo przegrywa. Działa na infrastrukturze, którą firma wybiera, a warstwa bezpieczeństwa i suwerenności traktuje go jako część własnego majątku firmy.

Jak wędruje zdarzenie

Moduł zmienia stan bieżący: płatność zostaje zaksięgowana. Ta sama zmiana zostaje opublikowana jako zdarzenie pod umową — nazwanym schematem z wersją. Potok ląduje zdarzeniem w zapisie jako nowy plik pod metadanymi tabeli, w opóźnieniu, o które poprosił biznes. Raport marży wystarczy zasilać co noc. Decyzja kredytowa potrzebuje minut. Kolejka pracy na hali potrzebuje sekund, a sekundy kosztują więcej niż minuty — dlatego poziom opóźnienia jest decyzją, nie ustawieniem domyślnym.

Zapis pisze się w jedną stronę. Agenci i superinteligencja czytają go razem z ontologią, która mówi im, co znaczy „wstrzymane zamówienie” albo „spóźniający się dostawca”. Nie piszą do niego bezpośrednio. Wynik pracy agenta to propozycja, która trafia do skrzynki zatwierdzeń; człowiek zatwierdza; moduł zmienia stan bieżący; zmiana jest publikowana jako zdarzenie; zdarzenie ląduje w zapisie. Dziennik decyzji sam jest tabelą w zapisie, z propozycją, jej źródłami, zatwierdzającym i czasem.

Co widział agent i kto zdecydował

Ta pętla sprawia, że na pytanie audytora da się odpowiedzieć. Zapis o 9:14 to wersja tabel, nie rekonstrukcja. Propozycja to wiersz z identyfikatorami wierszy, które przeczytała. Zatwierdzenie to wiersz z nazwiskiem człowieka. Nic w tym łańcuchu nie zależy od tego, czy ktoś pamięta.

Ta sama własność służy ludziom budującym system. Gdy oceniana jest nowa wersja agenta, dzień zdarzeń można odtworzyć z zapisu przeciwko niej i porównać jej propozycje z tymi, które ludzie faktycznie zatwierdzili. Zapis jest zestawem ewaluacyjnym.

Agenci budują warstwę Data, pod zatwierdzeniem

Hurukan budują i rozbudowują agenci, a warstwa Data nie jest wyjątkiem. Agent szkicuje potok, który ląduje nowym typem zdarzenia. Agent proponuje zmianę schematu, gdy moduł zyskuje pole, a sprawdzenie zgodności z rejestrem biegnie, zanim ktokolwiek przeczyta propozycję. Agent planuje scalanie małych plików i wygaszanie starych migawek. Każda z tych rzeczy jest propozycją z różnicą i wynikiem testu, a człowiek ją zatwierdza. Zatwierdzenie jest zapisywane jak każde inne.

Przy ludziach zostaje to, czego nie da się cofnąć ani wywnioskować: umowa między modułami, retencja historii i usunięcie danych osoby, wybór formatu i katalogu oraz każde podniesienie protokołu tabeli, które zamknęłoby dostęp starszemu czytelnikowi.

Zapis, który możesz zabrać ze sobą

Każdy element zapisu jest w formacie, który czytają inne silniki. Jeśli firma odchodzi, odchodzi z historią: plikami, metadanymi tabel i katalogiem, na własnej infrastrukturze. Tam, gdzie firma ma już narzędzia czytające jeden format — środowisko Microsoft, spółkę na Snowflake — te same pliki można wystawić w tym formacie bez kopii, o czym jest tekst Jeden zapis, czytelny dla narzędzi, które już macie. A tam, gdzie agenci domenowi potrzebują stanu bieżącego, a nie historii — kolejki pracy, magazynu, skrzynki zatwierdzeń — format tabeli zbudowany pod strumienie trzyma ten stan czytelnym bez odpytywania magazynu modułów, o czym jest tekst o Paimonie.

Test, który możesz zrobić dziś

Weź jedną decyzję, którą Twoja firma podjęła w zeszłym kwartale na podstawie raportu: limit kredytowy, zamówienie uzupełniające, cenę. Spróbuj wyprodukować dane dokładnie takie, jakie były w dniu decyzji, i nazwisko osoby, która ją podjęła. Policz godziny. Ta liczba to koszt posiadania jednej pamięci — i to jest to, po co jest zapis.