Aplikacyjny KMS

Aplikacyjny KMS to warstwa wiedzy żyjąca wewnątrz produktu — ograniczona do dziedziny produktu, wystawiana przez UI produktu, regulowana umowami produktu z użytkownikami. Jest najsurowszą z trzech warstw, bo każda zła odpowiedź staje się bugiem produktu.

Czym jest ta warstwa

Warstwa wiedzy, z którą użytkownik końcowy aplikacji wchodzi w interakcję przez UI aplikacji. KMS jest niewidoczny dla użytkownika jako „system wiedzy" — doświadcza go jako produkt, który wie pewne rzeczy, pamięta kontekst i z czasem staje się mądrzejszy.

Przykłady: aplikacja pomagająca użytkownikom budować katalog dostawców; aplikacja przyjmująca komunikację z klientami i wynosząca na wierzch istotną historię; aplikacja utrzymująca tracker projektu z automatycznie wyciąganymi decyzjami.

Zaufanie jest asymetryczne. Właściciel produktu ufa systemowi bardziej niż użytkownik końcowy. Użytkownik końcowy ocenia po tym, co widzi w UI — więc widoczne pomyłki mają nieproporcjonalny koszt.

Jakich zasad używa

Wszystkich ośmiu, z następującymi korektami:

• Kieruj, nie porządkuj — tak samo, ale reguły routingu są wpieczone w aplikację, nie edytowalne przez użytkowników.
• Rozdzielaj stan / wiedzę / interfejs — tak samo, z tą różnicą, że warstwa interfejsu jest UI produktu, a nie rozmową.
• Automatyczna kompilacja — bardziej konserwatywna niż w wersji osobistej; skompilowana treść widoczna dla użytkownika potrzebuje recenzji przed wyświetleniem, często przez krok promocji w UI.
• Bramkarz–Promotor — surowy; bramkarz chroni UX produktu, a nie skarbiec użytkownika.
• Projektuj pod zaniedbanie — sam system nie jest zaniedbywany (działa na produkcji), ale indywidualni tenanci użytkowników tak; system musi pozostać użyteczny, gdy pojedynczy użytkownik odłączy się na miesiące.
• Kontekst encji — schemat jest ustalony przez produkt; użytkownicy nie mogą wprowadzać nowych typów encji.
• Fala i sprzeczność — biegnie, ale jest ograniczona do tenanta użytkownika; fala między tenantami jest zakazana.
• Hybrydowe autorstwo — najbardziej restrykcyjne z trzech warstw. Treść wyprowadzona przez LLM, która pojawia się w UI, musi być oznaczona, zaźródłowiona i najlepiej regenerowalna.

Rozbieżności specyficzne dla warstwy

• Niezmienność źródeł. Źródła dostarczone przez użytkownika (uploady, integracje) nigdy nie są mutowane przez system. Kompilacja produkuje pochodne artefakty; źródło pozostaje nietknięte.
• Przyjazność ręcznemu śledzeniu. Nawet jeśli system potrafi auto-kompilować, UI musi sprawić, że ręczny przegląd i edycja są trywialne. Użytkownicy chcą systemu, który wykonuje pracę i pozwala ją poprawiać.
• Mniejsza autonomia. Agent nie podejmuje destrukcyjnych akcji bez potwierdzenia. Żadnych cichych nadpisań, żadnych auto-archiwizacji bez odzyskiwania, żadnych nieodwracalnych decyzji.
• Izolacja tenantów. Dane każdego użytkownika żyją w jego własnym tenancie; pobieranie między tenantami jest niemożliwe.
• Wersjonowana kompilacja. Gdy kompilacja się zmienia (bo zmieniło się źródło lub zmieniły się reguły), poprzednia wersja jest zachowywana z diffem. Użytkownicy widzą, dlaczego widok systemu na ich dane się przesunął.

Czym to NIE jest

• CRM. CRM-y to płaskie magazyny rekordów; aplikacyjny KMS syntetyzuje między rekordami.
• Chatbot przykręcony do produktu. Chatbot odpowiada; aplikacyjny KMS pamięta i propaguje.
• Ficzer SaaS. To wybór architektoniczny dotykający całego produktu, a nie moduł.

Referencyjne implementacje

Trzy żywe przykłady z projektów, przy których pracuję:

• KMS pipeline'u BD — aplikacyjny KMS do pracy nad dealami przed podpisaniem, gdzie każdy deal jest śledzoną encją z notatkami, decyzjami i sygnałami.
• KMS „drugi mózg" — bramkarz/promotor jako aplikacyjny KMS dla użytkowników osobistego mózgu, filtrujący surowe wejście, zanim wejdzie do magazynu.
• KMS badań inwestycyjnych — aplikacyjny KMS do budowania tez inwestycyjnych, gdzie niezmienność źródeł i proweniencja są nienegocjowalne.