Luden OS  ·  Infrastruktura decyzyjna dla e-commerce

AI przy każdej decyzji.
Człowiek przed każdą zmianą.

Przewiń

Sześć narzędzi mówi, co się stało.

Żadne nie mówi, co zrobić.

Sklep generuje dane o sprzedaży, kosztach, cenach, zapasie, produktach, klientach, kampaniach, zwrotach i konwersji. Istniejące narzędzia dobrze je pokazują i liczą.

Brakującą warstwą jest praca pomiędzy „coś się wydarzyło” a „oto konkretna decyzja gotowa do zatwierdzenia”. Tę pracę ktoś musi wykonać: połączyć właściwe fakty, rozpoznać sytuację wymagającą uwagi, sprawdzić kontekst, uwzględnić reguły sklepu, przygotować propozycję, pokazać dowód i doprowadzić zaakceptowaną zmianę do wykonania i wyniku.

Luden bierze tę pracę na siebie. Operator nie traci władzy nad zmianą — przestaje składać każdą decyzję od zera.

Problem

Trzy wycieki, które widać dopiero w księgowości.
Jeśli w ogóle.

Wyciek 01

ROAS, który kłamie

Panel reklamowy raportuje przychód z kampanii — kosztu towaru nie zna i znać nie może. Nikt go nie odejmuje, więc kampania z ROAS 600% potrafi dokładać do interesu, a raport wygląda na sukces.

Luden

Breakeven-ROAS liczony per kampania z kosztów zakupu i przychodu z własnego taga. Kampania pod progiem dostaje propozycję cięcia — z liczbą, nie z przeczuciem.

Wyciek 02

Cena, która została w tyle

Koszt zakupu poszedł w górę, cena i promocja zostały stare. Produkt sprzedaje się pod progiem rentowności tygodniami, bo nikt nie przelicza marży pozycja po pozycji.

Luden

Marża liczona z realnych kosztów przy każdym syncu. Sygnał idzie tego samego dnia, nie w miesięcznym raporcie.

Wyciek 03

Spadek zauważony ostatni

Konwersja osuwa się tydzień po tygodniu. Widać to dopiero w wyniku miesiąca — wtedy, gdy pieniądze już wyciekły i nie ma czego ratować.

Luden

Baseline z własnej historii sklepu. Odchylenie staje się sygnałem, zanim domknie się miesiąc.

Te decyzje i tak zapadają codziennie. Dziś ręcznie, po omacku i bez pamięci.

Jak Luden wykrywa te trzy sytuacje i skąd bierze liczby

Rozmowa

Proste pytanie.
Analiza, której nie da się zrobić w arkuszu.

Dashboard odpowiada na „co się stało”. Operator potrzebuje odpowiedzi na „kiedy to zrobić” — a ta wymaga przeczytania zamówień, kosztów, sygnałów, wykonanych decyzji i reguł naraz. Luden pyta o to wszystko sam i odpowiada terminem, nie ogólnikiem — także wtedy, gdy ten termin wypada później, niż operator chciał.

luden · rozmowa zapis z demo

Operator

kiedy przecenić fotele gamingowe, żeby nie zjeść marży?

Luden

Po 22 sierpnia i na 31 z 48 modeli. Wtedy wygasa promocja dostawcy, koszt zakupu wraca do 682,40 zł, a reszta kategorii wraca nad próg 22,0%, który operator wpisał do pamięci.7

Dlaczego nie dziś i nie na całej kategorii
  • 17 z 48 modeli stoi dziś pod progiem 22,0% — przecena zepchnęłaby je głębiej, zamiast domknąć wyciek.12
  • Najgłębiej Vantar RX: koszt zakupu wzrósł 11 lipca o 38,00 zł i nie odbił się ani w cenie, ani w promocji.3
  • Pozostałe 31 modeli ma zapas — mediana marży 29,4%, więc przecena o 10% mieści się nad progiem.45
  • Ruch w kategorii jest stabilny, więc spadku marży nie tłumaczy popyt, tylko koszt zakupu.6

Przeczytane

1 240
zamówień
48
modeli w kategorii
18
pozycji kosztów
7
pytań do modelu sklepu
3
reguły pamięci
41 812
wpisów audytu
0
danych osobowych

Rozmowa niczego nie zmienia. Żeby coś zmieniło się w sklepie, operator musi zatwierdzić propozycję.

Model sklepu, na którym stoi ta odpowiedź

AI

Najlepszy dostępny model.
Zero władzy wykonawczej.

Luden OS pracuje na frontierowych modelach językowych — dziś Claude, z konstrukcji wymiennie. Dostawca i wersja modelu są zapisane w odcisku każdej decyzji. Gdy pojawia się lepszy model, system go wynajmuje. Infrastruktura nie starzeje się razem z żadnym dostawcą.

Model nie dostaje streszczenia sklepu — dostaje do niego klucze i sam decyduje, o co zapytać: o marżę tego produktu, o to, co operator odrzucił pół roku temu, o to, czy podobna zmiana już kiedyś zadziałała i z jakim skutkiem. Pełna powierzchnia pytań, nie gotowa paczka kontekstu.

Nie definiuje swoich uprawnień. Nie ustala swoich granic. Nie wykonuje zmiany. Model może być świetny w myśleniu — Luden nie opiera się na tym, że sam z siebie będzie przestrzegał zasad. Zasady egzekwuje system, poza modelem.

Rachunek nie zależy od tokenów.

Model jest kosztem Luden, nie sklepu — stąd wolna ręka w sięganiu po najlepszy dostępny, zamiast po najtańszy. Sklep płaci stałą stawkę miesięczną za działający system, a nie za zużycie.

Faktura nie rośnie od tego, ile razy model przeczytał historię sklepu, ile propozycji odrzucił operator ani ile razy detektory przeliczyły marżę. Rośnie to, co system zdążył policzyć i rozliczyć — nie to, co pobrał od dostawcy modelu.

Granice
Każdy parametr z modelu przechodzi deterministyczną walidację granic. Odrzucenie, nigdy cicha poprawka.
Dane osobowe
Nazwisko, e-mail, adres, IP i identyfikatory reklamowe wypadają przed każdym promptem. Model nie dostaje nawet identyfikatora sklepu.
Limit
Sufit wydatku na model, liczony osobno dla każdego sklepu. Po jego przekroczeniu warstwa AI milknie, a deterministyczna pętla biegnie dalej.
Wyłącznik
Operator wyłącza warstwę AI dla swojego sklepu jedną decyzją i nie musi jej z nikim uzgadniać.
Osiem warstw, które stoją poza modelem

Model proponuje każdą z tych decyzji.

Nie wykonuje żadnej z nich.

Pełna władza poznawcza · Zerowa władza wykonawcza

Platforma — jedna pętla

Jedna decyzja przechodzi sześć stacji.

  1. 01

    Sygnał

    Fakt liczy kod — deterministycznie, te same dane dają ten sam wynik. O tym, czy fakt jest ważny, orzeka model.

    Skąd bierze się sygnał 
    detektor   margin_leak
okno       28 dni
podstawa   zamówienia + koszty zakupu
wynik      3 SKU pod progiem marży
  2. 02

    Dowód

    Każda propozycja niesie liczby i ich pochodzenie. Skąd, z jakiego okresu, ile.

    Od sygnału do gotowej propozycji 
    marża      24,1% -> 19,8%   −4,3 pp
okres      2026-07-11 .. 2026-08-07
źródło     zamówienia 142 · koszty 18
kontrola   dane sklepu, nie benchmark
  3. 03

    Zgoda

    Żadna zmiana nie dotyka sklepu bez zatwierdzenia operatora. To architektura, nie ustawienie.

    Skrzynka decyzji i dry-run 
    propozycja -> operator -> sklep
              ________
              jedyne wejście do sklepu
model         nie ma tej ścieżki
  4. 04

    Wykonanie

    Zapis przechodzi przez zamknięty rejestr bramek. Odcięcie działa w sekundy.

    Porty, guard_write i kill switch 
    guard_write  ENV          ok
             kill-switch  off
             RLS          ok
port         price.prestashop
  5. 05

    Pomiar

    Każda wykonana decyzja dostaje scorecard. Skutki w przedziałach, oznaczone uczciwie.

    Scorecard i uczciwy odczyt wyniku 
    marża      +2,1 pp   CI [+0,4; +3,8]
przychód   +1 240 zł CI [−310; +2 790]
odczyt     korelacyjny, nie przyczynowy
  6. 06

    Pamięć

    Zaakceptowane reguły stają się prawem systemu. Egzekwowane bez wyjątków.

    Pamięć i prawo weta reguły 
    reguła     minimalna marża 22,0%
status     egzekwowana
skutek     propozycja −11,0% ODRZUCONA

Zasady

Cztery zdania, które ograniczają Luden OS mocniej niż jakikolwiek regulamin. Każde z nich ma swój test w kodzie i psuje wdrożenie, gdy przestaje być prawdą.

Łańcuch dowodowy, wpis po wpisie
  1. Art. 1

    Model językowy proponuje. Nigdy nie wykonuje.

  2. Art. 2

    Każde zdarzenie AI ma odcisk i ślad w łańcuchu.

  3. Art. 3

    Reguły operatora mają prawo weta wobec każdej propozycji.

  4. Art. 4

    Gdy system nie zna liczby, mówi „nie wiem”.

Nihil novi sine communi consensu · 1505

Pokaż nam decyzję, którą dziś podejmujecie ręcznie.

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. Jeśli Luden może tę drogę skrócić i ustrukturyzować, od tego zaczyna się wdrożenie. Tę rozmowę otwiera jedna wiadomość: opis decyzji wystarczy za całe zapytanie, a odpowiedź wraca w jeden dzień roboczy.

kontakt@luden.pl