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.
Ź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.
Ź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.
PrestaShop wholesale_price -> Koszt ERP KOSZT_ZAKUPU_NETTO -> Koszt arkusz koszt netto -> Koszt PrestaShop quantity -> Zapas magazyn stan_dostepny -> Zapas Google Ads campaign -> Kampania Meta Ads campaign -> Kampania
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
Luden zna pełny kontekst sklepu.
Model dostaje kontekst jednej decyzji.
Pełny kontekst to produkty, zamówienia, ceny, koszty, zapas, kampanie, klienci, metryki, relacje, historia decyzji i reguły operatora. Nie znaczy to, że cały sklep trafia do promptu.
pełny model sklepu
|
| pojawia się konkretny problem
v
kontekst decyzji sygnał
+ właściwe encje
+ metryki i ich pochodzenie
+ historia poprzednich decyzji
+ reguły operatora
+ dozwolone działania
|
v
model językowy rozumuje nad tym, co dostał
Warstwa danych rozstrzyga wcześniej, skąd pochodzi koszt, skąd zapas i czym jest dany produkt. Model dostaje przygotowany kontekst i rozumuje nad nim — nie chodzi po systemach sklepu i nie odkrywa ich układu przy każdym pytaniu.
Detektory
Luden nie czeka, aż operator zada właściwe pytanie.
Detektory obserwują model sklepu i emitują sygnały. Marża poniżej polityki, rosnący zapas przy spadającej sprzedaży, produkt bez sprzedaży, zmiana poziomu zwrotów, kampania pod progiem rentowności, anomalia w produkcie albo kategorii.
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.
Detektory liczące te wartości są deterministyczne: te same dane dają ten sam wynik, dziś i za rok. Obok nich pracują detektory wspierane przez model — tam, gdzie wzorzec wymaga interpretacji, a nie arytmetyki.
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.
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 wybiera z listy, której nie umie rozszerzyć, i dobiera parametry w dozwolonym zakresie.
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-fable-5
- 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.
Bezpieczeństwo
Luden zakłada, że model może się pomylić.
Bezpieczeństwo nie zależy od tego, czy model okaże się grzeczny. Poza modelem stoi kilka niezależnych warstw, z których każda działa także wtedy, gdy zawiodą pozostałe.
- Słownik akcji
- Zamknięty i policzalny. Model wybiera z listy, której nie umie 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.
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.
Dlatego wartość bez wskazanego pochodzenia nie jest w Ludenie poprawnym obiektem — pilnuje tego bramka odpalana jako test, nie dobra praktyka.
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.