Jak to działa
Cała droga od zdarzenia w sklepie do zmiany, którą ktoś zatwierdził.
Strona główna pokazuje tę drogę w sześciu stacjach. Tutaj jest każda z nich osobno: skąd biorą się fakty, co znaczy pojedyncza liczba, jak powstaje propozycja, co ją zatrzymuje i co zostaje w systemie po wykonaniu.
Model sklepu
Luden buduje model sklepu.
Żeby przygotować decyzję, nie wystarczy znać liczb. Trzeba wiedzieć, czego dotyczą i jak są ze sobą powiązane. Marża 19,8% nie znaczy nic, dopóki nie wiadomo, którego produktu dotyczy, z jakiego kosztu wynika, w ilu zamówieniach się pojawiła i która kampania go promuje.
Model powstaje z danych, które sklep już ma. Nie trzeba wymieniać narzędzi, wdrażać nowego systemu ani niczego przepisywać.
Relacje
Osobno pojęcia niewiele mówią. Wartość jest w krawędziach między nimi — i to one pozwalają przejść od pojedynczej liczby do sytuacji, która wymaga decyzji.
produkt --- ma ---------> cena
--- ma ---------> koszt
--- ma ---------> zapas
--- sprzedany w -> zamówienie
<-- promuje ----- kampania
--- podlega ----> reguła
zamówienie --- złożył ----> klient
sesja --- poprzedza -> zamówienie
dostawca --- dostarcza -> produkt
To jest ontologia Luden — wspólny język, w którym system opisuje każdy sklep. Każda krawędź niesie zaufanie i wskazanie zdarzenia, które ją uzasadniło, więc graf da się prześledzić do surowego faktu. Po tym grafie porusza się model językowy: nie po bazie sklepu, tylko po modelu jego biznesu.
Każdy obiekt ma swoją stronę.
Model sklepu nie jest rysunkiem w dokumentacji. Operator wchodzi w produkt i widzi wszystko, co Luden o nim wie: cenę, koszt, zapas, marżę, kampanie, które go promują, zamówienia, w których się pojawił — i historię decyzji, które go dotyczyły, razem z tymi odrzuconymi.
Taka sama strona istnieje dla kampanii, kategorii, dostawcy i reguły. Z każdej z nich da się przejść po krawędzi do sąsiada, a z każdej liczby — w dół, do zdarzenia, z którego powstała.
Źródła
Model jest jeden. Dane pochodzą z systemów, których sklep rzeczywiście używa.
Podstawą kontekstu są dane sklepu i kanałów reklamowych. W zależności od tego, jak sklep pracuje, dochodzą kolejne źródła — i tyle, ile potrzeba do konkretnych decyzji.
Podstawa
platforma e-commerce Google Ads Meta Ads first-party tag
Cztery źródła, z których powstaje oś pieniędzy: co się sprzedało, po ile, za ile kupione i skąd przyszedł ruch.
Zależnie od sklepu
system magazynowy ERP PIM marketplace systemy własne
Jeśli sklep prowadzi koszty w ERP albo zapas w magazynie, Luden bierze je stamtąd. Jeśli nie prowadzi — nie ma czego podłączać i nikt tego nie wymaga.
Luden nie wymaga konkretnego stacku. Mapuje rzeczywistość konkretnego sklepu do wspólnego modelu e-commerce.
Luden milczy, gdy nie ma danych — i mówi dlaczego.
Źródło niepodpięte nie daje pustego ekranu ani ostrożnego ogólnika. Daje zdanie: „o reklamach się nie wypowiadam, bo konektor Meta nie jest podpięty”. Brak jest nazwany, umiejscowiony i widoczny dokładnie tam, gdzie operator szukałby odpowiedzi.
Systemy oparte na modelach mają skłonność do udawania wszechwiedzy — odpowiadają zawsze, także wtedy, gdy nie mają na czym stanąć. Luden pokazuje, gdzie kończy się jego wzrok, bo operator decyduje nie tylko o zmianie w sklepie, ale najpierw o tym, czy odpowiedzi w ogóle zaufać.
Źródło a znaczenie
Źródło mówi, skąd pochodzi fakt. Model mówi, co ten fakt znaczy.
Logika decyzyjna nie może stać na nazwach pól w konkretnym API ani na strukturze konkretnej platformy. Zmiana dostawcy nie może unieważniać reguł sklepu.
Koszt PrestaShop wholesale_price ERP KOSZT_ZAKUPU_NETTO arkusz koszt netto Zapas PrestaShop quantity magazyn stan_dostepny Kampania Google Ads campaign Meta Ads campaign
Koszt pozostaje kosztem niezależnie od tego, z którego systemu pochodzi. Zapas pozostaje zapasem. Kampania pozostaje kampanią. Warstwa decyzyjna pracuje na znaczeniu handlowym, nie na strukturze konkretnego systemu.
Historia
Luden pamięta, co się wydarzyło.
Zdarzenia trafiają najpierw do historii: zamówienie, zmiana ceny, aktualizacja kosztu, kliknięcie, zmiana stanu, wykonana akcja. Zapis jest dopisywany, nigdy nadpisywany. Wszystko powyżej się z niego odtwarza.
Dwa czasy
Każde zdarzenie niesie osobno kiedy się stało i kiedy system się o tym dowiedział. Późna korekta dopisuje wiersz zamiast poprawiać przeszłość.
Dzięki temu Luden odtwarza nie tylko dzisiejszy stan sklepu, ale też to, co wiedział w chwili konkretnej decyzji — a to jest jedyny uczciwy sposób oceny tamtej decyzji.
Co z tego wyrasta
zdarzenia -> model sklepu -> metryki -> sygnały -> decyzje
Każdy krok stoi na poprzednim. Metryka wskazuje zdarzenia, z których powstała; sygnał wskazuje metryki; propozycja wskazuje sygnał.
Kontekst
Model nie dostaje streszczenia.
Dostaje klucze do modelu sklepu.
Pełny kontekst to produkty, zamówienia, ceny, koszty, zapas, kampanie, klienci, metryki, relacje, historia decyzji i reguły operatora. Nie da się go streścić z góry, bo z góry nie wiadomo, co okaże się istotne. Więc Luden nie streszcza — daje modelowi narzędzia i pozwala pytać.
model językowy
|
| pyta o to, czego potrzebuje
v
pytanie odpowiedź
marża tego SKU? 19,8% · 41 szt.
kto go promuje? grupa 7719241
kiedy wzrósł koszt? 11 lipca +38,00 zł
co odrzucił operator? przecenę kategorii
czy to już działało? marża +2,1 pp
jaka reguła? marża min. 22,0%
|
v
propozycja ze słownika akcji
Nie ma tu z góry ustalonej listy pytań ani limitu rund. Model pyta tak długo, aż wie dość — i nie chodzi przy tym po systemach sklepu, tylko po modelu, który Luden już zbudował. Swoboda pytania jest pełna. Słownik działania jest zamknięty.
Koszt decyzji nie rośnie razem z katalogiem.
Model nie ogląda katalogu. Zadaje pytanie i dostaje wynik policzony po stronie danych — „pokrycie: 63 dni”, a nie tysiąc obserwacji, z których musiałby to wyliczyć sam. Każda odpowiedź ma twardy sufit na liczbę wierszy, a przekroczenie sufitu jest zgłaszane wprost, nie ucinane po cichu.
Dlatego sklep z 900 produktami i sklep z 10 000 produktów kosztują za decyzję tyle samo. Skala mieszka w danych, nie w kontekście modelu — i to jest przypięte testem, nie deklaracją.
Dane
Model nie zna ani jednego klienta.
Nie dostaje nawet identyfikatora sklepu.
Decyzja o cenie, marży, zapasie i budżecie kampanii nie zależy od tego, kto kupił — zależy od tego, ile i za ile. Klient jest w modelu sklepu liczbą zamówień, nie nazwiskiem. Ta praca nie wymaga danych osobowych, więc model ich nie dostaje.
Co dostaje model
SKU 4471 marża 19,8% · 41 szt. koszt 682,40 zł zamówień 142 · 28 dni kampania 7719241 reguła: marża min. 22,0%
Co nie wychodzi nigdy
imię i nazwisko e-mail, telefon, adres NIP, PESEL, IBAN, karta IP, cookie, sesja identyfikator odwiedzającego identyfikatory kliknięć reklamowych współrzędne geograficzne tokeny i klucze do systemów identyfikator sklepu
Jedno przejście, nie dobre chęci
Wszystko, co model dostaje, przechodzi przez jedną funkcję czyszczącą w jednym miejscu — nie ma drugiej drogi do promptu. Cięcie idzie po nazwie pola i po kształcie wartości, więc adres e-mail schowany w wolnym tekście wypada tak samo jak pole, które się tak nazywa.
Filtr celowo tnie szerzej, niż to konieczne. Koszt zbyt szerokiego cięcia to jedno zredagowane pole w wyjaśnieniu; koszt zbyt wąskiego to naruszenie ochrony danych. Ta asymetria jest rozstrzygnięta w kodzie, nie w polityce prywatności.
Wiązanie robi kod, nie model
Identyfikator odwiedzającego i identyfikatory kliknięć reklamowych istnieją po to, żeby połączyć kliknięcie z sesją, a sesję z zamówieniem. To wiązanie wykonuje kod deterministyczny w warstwie danych i tam zostaje. Model dostaje dopiero wynik: kampania 7719241, wydatek 4 820 zł, przychód 29 500 zł, 41 zamówień.
Tak jest nie tylko bezpieczniej, ale i dokładniej. Dopasowanie identyfikatorów to arytmetyka, nie osąd — te same dane dają ten sam wynik, dziś i za rok. Model nie musiałby tego robić lepiej; musiałby to robić na danych, których nie potrzebuje.
Dane jednego sklepu nie są widoczne z drugiego: warstwa danych odmawia zapytania bez wskazania sklepu, a drugim pasem jest polityka bazy. Luden nie trenuje przy tym żadnego modelu na danych sklepu — modele są wynajmowane, a jedyne, czego system się uczy, to reguły zatwierdzone przez operatora. Zostają one w jego sklepie.
Klienta da się usunąć z danych.
Gdy klient sklepu korzysta z prawa do usunięcia danych, Luden kasuje klucz, którym są zaszyfrowane. Od tej chwili odczytanie ich przestaje być możliwe — także po stronie Luden.
Łańcuch audytu jest z konstrukcji niezmienny, więc ślad decyzji zostaje nienaruszony. Zapis dokumentujący decyzję przeżywa, osoba w nim nie.
Bezpieczeństwo
Luden zakłada, że model może się pomylić.
Swoboda modelu rośnie po stronie poznania. Po stronie działania nie rusza się nic. Między pytaniem a zmianą w sklepie stoi osiem niezależnych warstw — każda działa także wtedy, gdy zawiodą pozostałe, i żadna nie zależy od tego, czy model okaże się grzeczny.
- Słownik akcji
- Zamknięty i policzalny. Model komponuje w nim swobodnie i nie ma jak go rozszerzyć.
- Granice parametrów
- Liczone z danych sklepu. Wartość spoza granicy odrzuca całą propozycję — nigdy cicha poprawka.
- Weto pamięci
- Reguła przyjęta przez operatora blokuje sprzeczną propozycję w generatorze, zanim ta dotrze do skrzynki.
- Zgoda i dry-run
- Żadna zmiana nie dotyka sklepu bez zatwierdzenia, a przed nim operator widzi dokładny efekt.
- Porty
- Zamknięty rejestr klas zapisu. Portów generycznych nie ma i test architektoniczny nie pozwala ich dodać.
- Write guard
- Każdy zapis do świata woła bramkę jako pierwszą instrukcję. Bez niej prymityw nie przechodzi testu.
- Kill switch
- Odcięcie zapisów per sklep i globalnie. Liczone w sekundach, nie we wdrożeniach.
- Izolacja sklepów
- Warstwa danych odmawia zapytania bez wskazania sklepu. Drugim pasem jest polityka bazy.
Pełna władza poznawcza. Zerowa władza wykonawcza. Tej granicy nie da się przesunąć konfiguracją, bo nie jest ustawieniem — jest konstrukcją. Każda z ośmiu warstw ma swój test w kodzie i psuje wdrożenie, gdy przestaje być prawdą.
Liczba bez źródła nie jest dowodem.
Jeśli Luden pokazuje marżę 8,4% albo 29 500 zł przychodu z kampanii, operator musi móc dojść do danych, które tę wartość uzasadniają: z których zamówień, z jakiego okresu, po jakiej definicji metryki i z którego zdarzenia w historii. Samej liczby nie podaje zresztą model: podaje wskazanie, a wartość wyciąga z niego system.
Weto dotyczy jednak pojedynczego pola, nie całej wypowiedzi. Jedna liczba bez pochodzenia nie kasuje reszty odpowiedzi — wypada z niej i zostaje oznaczona jako brakująca, a wszystko, co ma pokrycie, zostaje w mocy.
„Nie wiem, brakuje mi tej liczby” jest poprawnym wyjściem, nie awarią. System, który zawsze ma odpowiedź, prędzej czy później ma odpowiedź zmyśloną — a operator nie ma jak odróżnić jednej od drugiej.
Sygnał
Luden nie czeka, aż operator zada właściwe pytanie.
Kod liczy fakt: pokrycie zapasu w dniach, spadek marży wobec własnej bazy sklepu, kampanię pod progiem rentowności. O tym, czy ten fakt zasługuje na uwagę operatora, orzeka model. Luden nie wynajmuje stu reguł, żeby zgadywały, co jest ważne w tym konkretnym sklepie — wynajmuje najlepszy dostępny model i pokazuje mu ten sklep.
Fakty nie są zgadywane
Jeśli marża wynosi 19,8%, system ma ją policzyć. Jeśli próg wynosi 22,0%, próg ma istnieć w systemie. Jeśli koszt zmienił się o 38,00 zł, wartość ma wynikać z danych, a nie z oszacowania.
Liczenie jest deterministyczne: te same dane dają ten sam wynik, dziś i za rok. Ale liczenie orzeka wyłącznie o fakcie. O tym, czy fakt jest ważny, orzeka model — bo ważność zależy od sklepu, pory roku, umowy z dostawcą i planów operatora, a nie od progu wpisanego w regułę przez kogoś, kto tego sklepu nigdy nie widział.
Sygnał to jeszcze nie decyzja
Sygnał mówi tylko tyle: tutaj wydarzyło się coś, co może wymagać działania. Nie mówi, co zrobić, i niczego nie proponuje.
sygnał margin_leak produkt Vantar RX · SKU 4471 marża 19,8% minimum 22,0% (reguła operatora) koszt +38,00 zł od 11 lipca sprzedaż 41 szt. · 28 dni zapas 112 szt.
Skrzynka jest skrzynką, nie wylotem z węża.
Każdy operator zna zmęczenie powiadomieniami: sto alertów dziennie, z których żadne nie jest decyzją. Narzędzie, które znajduje wszystko, przerzuca z powrotem na człowieka dokładnie tę pracę, której miało go pozbawić — wybór, co z tego ma znaczenie.
Dlatego wyjściem Ludena jest garstka decyzji, a nie tysiąc znalezisk. Przy każdej stoi powód, dla którego stoi wyżej niż pozostałe, a lista ma się kończyć. Skrzynka, którą da się opróżnić przed południem, jest warta więcej niż strumień, którego nie da się domknąć nigdy.
Propozycja
Od sygnału do propozycji.
Sygnał sam nie wystarczy do decyzji. Dopiero zebrany wokół niego kontekst pozwala zacząć rozumowanie — i dopiero z niego powstaje propozycja, którą operator ma co ocenić.
sygnał + dowody liczby i zdarzenia, z których powstały + historia poprzednie decyzje na tym produkcie + polityki sklepu minimalna marża, tolerancja zmian cen + dozwolone akcje to, co dla tej sytuacji w ogóle wchodzi w grę = kontekst decyzji
Zamknięta ontologia akcji
Model nie może wymyślić dowolnego działania. Słownik możliwych akcji jest zamknięty i policzalny — model komponuje w nim swobodnie i parametryzuje propozycję do woli, ale nie ma jak go rozszerzyć, a każda wartość musi zmieścić się w granicach liczonych z danych sklepu.
Każdy typ akcji ma własny opis: parametry, granice, ryzyko, politykę zatwierdzania i sposób wykonania. Wartość spoza granicy nie jest po cichu poprawiana — leci do odrzucenia razem z całą propozycją.
akcja test_price parametr delta_pct granica [−8,0%; +8,0%] wartość +4,0% przyjęte cena 899,00 zł -> 935,00 zł port price_write ryzyko średnie · wymaga zgody
Czego w tym słowniku nie ma i mieć nie może: uprawnienia tworzonego w locie, generycznego zapisu, dowolnego żądania HTTP, uruchomienia skryptu.
Wstrzymaj grupę reklam „Fotele gamingowe — ogólne”.
Po odjęciu kosztu towaru grupa dokłada do każdej sprzedaży.
172 zł/dzień -> 0 zł/dzień
grupa 7719241 · Google Ads · ads_budget · wartość strategii −60%
Dowód
- wydatek
- 4 820 zł · 28 dni
- przychód
- 29 500 zł · 41 zamówień
- koszt towaru
- 25 340 zł
- wynik
- −660 zł · grupa dokłada do interesu
- ROAS
- 612% wobec breakeven 709%
- atrybucja
- tag first-party, nie panel Google Ads
Proweniencja
- model
- Claude · wersja w odcisku
- wersja promptu
- rev 12 · 9f2c…a81b
- odcisk
- f4d1…07c6
- granice
- −100% w [−100%; +30%] · przyjęte
Skrzynka decyzji
Nic nie dotyka sklepu bez zgody operatora.
Operator nie dostaje pustego dashboardu ani pytania „co chcesz zrobić?”. Dostaje przygotowaną decyzję: co się wydarzyło, dlaczego jest istotne, co Luden proponuje, na jakiej podstawie, w jakich granicach i jaki dokładnie będzie efekt zmiany. Może ją zatwierdzić, zmienić albo odrzucić.
Dry-run
Po zatwierdzeniu zmiana nie idzie od razu do sklepu. Najpierw operator widzi jej dokładny efekt na konkretnych encjach — nie opis zamiaru, tylko wartości przed i po.
encja SKU 4471 · Vantar RX przed 899,00 zł po 935,00 zł zakres 1 encja · 1 z 1 skutek marża 19,8% -> 23,4%
Wykonanie
Zmianę przejmuje osobna warstwa. Model nie ma tej ścieżki i nie ma jak jej sobie dorobić.
propozycja -> zgoda operatora -> dry-run -> walidacja granic -> port klasy zapisu -> guard_write -> zmiana w sklepie
Nie istnieje uniwersalny wykonawca z dowolnym dostępem do systemów. Każda klasa działania ma własną, kontrolowaną ścieżkę — a portów generycznych w rejestrze nie ma i test nie pozwala ich dodać.
Wynik
„Wykonano” nie znaczy „zadziałało”.
Po zmianie Luden obserwuje, co się stało. Zmiana zaobserwowana po decyzji nie jest automatycznie traktowana jako jej efekt — system rozróżnia wynik obserwowany po decyzji od wpływu, który da się tej decyzji przypisać.
Scorecard
Tam, gdzie jest podstawa, system korzysta z baseline'ów, porównań i eksperymentów. Tam, gdzie jej nie ma, wynik zostaje oznaczony jako obserwacyjny i nikt go nie awansuje na dowód przyczyny.
przed marża 19,8%
41 szt. / 28 dni
decyzja test_price +4,0% · 09:02
po marża 23,4%
38 szt. / 28 dni
marża +2,1 pp
CI [+0,4; +3,8]
przychód +1 240 zł
CI [−310; +2 790]
odczyt korelacyjny,
bez grupy kontrolnej
Pamięć
Następna decyzja nie zaczyna się od zera. Luden pamięta, co wykrył, co zaproponował, co operator przyjął, co odrzucił, co wykonano i jaki był wynik.
Z tej historii model może zaproponować regułę. Sama propozycja niczego nie zmienia — regułę zatwierdza operator. Dopiero przyjęta reguła trafia do pamięci i od tej chwili ma prawo weta wobec kolejnych propozycji: sprzeczna propozycja jest odrzucana w generatorze, zanim w ogóle dotrze do skrzynki.
Dane to nie cały kontekst.
Dwa sklepy mogą mieć te same liczby i podjąć różne, jednakowo poprawne decyzje. Różni je minimalna marża, tolerancja zmian cen, zasady dla produktów flagowych, progi zapasu, wymagany poziom zatwierdzenia i wyjątki, o których wie tylko operator.
Dlatego Luden ma znać nie tylko to, jak sklep wygląda, ale też zasady, według których sklep chce działać. Reguły operatora są częścią kontekstu każdej decyzji na równi z danymi.
Dowód
Łańcuch, którego nie da się przepisać.
Każde zdarzenie ląduje w łańcuchu audytu spiętym hashem. Podmiana jednego wpisu zrywa wszystkie następne, a weryfikacja to pokazuje. Poniżej jeden pełny cykl decyzji — tak, jak zapisuje go system.
[AI] model językowy [CZŁOWIEK] operator sklepu bez znacznika kod deterministyczny
Wdrożenie
Zaczynamy od decyzji, nie od systemów.
Pierwsze pytanie nie brzmi „jakie macie systemy”. Brzmi: które decyzje wymagają dziś regularnej pracy operatora. Dopiero z tego wynika, jakie fakty są potrzebne i skąd je wziąć.
Pierwsze sześć tygodni ma stały rytm: co tydzień jedna strona raportu, na końcu wspólna rekomendacja, czy jedziemy dalej. Kryterium tej decyzji operator ustala na starcie, zanim padnie pierwsza liczba.
-
01
Klasy decyzji
Wybieramy pierwsze klasy decyzji: ceny, marża, promocje, rentowność kampanii, zapas, produkty bez sprzedaży.
-
02
Fakty
Ustalamy, jakie fakty są do tych decyzji potrzebne — i tylko te.
-
03
Źródła
Ustalamy, gdzie te fakty leżą w tym konkretnym sklepie, i mapujemy je do modelu Luden.
-
04
Reguły
Spisujemy semantykę i reguły operatora: progi, wyjątki, wymagane zatwierdzenia.
-
05
Obserwacja
Luden obserwuje i przygotowuje propozycje. Operator ocenia je na żywym sklepie, nic nie zmieniając.
-
06
Wykonanie
Dopiero później, klasa po klasie, uzbraja się kontrolowane wykonanie.
Nie podpinamy wszystkiego, co się da. Podpinamy dane potrzebne do konkretnych decyzji. Celem wdrożenia jest poprawny model i poprawne decyzje, a integracje są do tego środkiem.
Systems of record below.
System of decision above.
Luden nie zastępuje systemów, na których sklep już działa. Platforma e-commerce nadal obsługuje sprzedaż, systemy reklamowe nadal prowadzą kampanie, reszta narzędzi nadal robi swoje.
Nad nimi powstaje warstwa, której dziś nie ma: kontekst, sygnały, decyzje, reguły, kontrolowane wykonanie, wyniki i pamięć.
Tyle o systemie. Reszta zależy od konkretnego sklepu.
Pierwsza rozmowa zaczyna się od realnej decyzji operatorskiej. Ustalamy, jakie fakty są do niej potrzebne, skąd pochodzą, jakie reguły obowiązują i jak wygląda dziś droga od sygnału do działania. Tę rozmowę otwiera jedna wiadomość: opis decyzji wystarczy za całe zapytanie, a odpowiedź wraca w jeden dzień roboczy.