Monitoring Rejestr360

Nie pytaj „czy był refresh?”. Zobacz, co się zmieniło i co z tym zrobić.

Decision Inbox łączy trwałe różnice z Monitoring Core z odpowiedzią biznesową: co się zmieniło, dlaczego to ma znaczenie, jak pilna jest zmiana i jaki jest następny krok. Monitoring Readiness pokazuje dodatkowo, czy cały łańcuch faktycznie jest gotowy — bez deklarowania kanałów, których jeszcze nie uruchomiliśmy.

Zasada produktu

Pierwszy odczyt tworzy baseline. Dopiero kolejna semantyczna różnica może zostać alertem. Jeśli źródło nie podaje daty prawnej, Rejestr360 pokazuje wyłącznie okno detekcji.

Różnica, nie polling

Alert powstaje ze zmiany fingerprintu stanu KRS, CRBR, relacji lub sprawozdań.

Następny krok

Zmiana reprezentacji, UBO, statusu czy finansów prowadzi od razu do właściwej warstwy profilu.

Prywatna capability

Token watchlisty pozostaje w HttpOnly cookie; baza produktu przechowuje tylko jego SHA-256.

Jeden subject na KRS

Wielu obserwujących nie mnoży wywołań oficjalnych źródeł ani obciążenia Company Core.

Monitoring Readiness

Silnik gotowy — czeka na pierwszą firmę

Warstwy detekcji, schedulera i Decision Inbox są gotowe. Dodanie KRS tworzy prywatny subject monitoringu; pierwszy poprawny cykl buduje baseline bez fałszywego alertu.

In-app: aktywneEmail / webhook: nieaktywne

Źródła i snapshoty

gotowe

Warstwa produktu może korzystać z Monitoring Core i utrwalać kolejne stany spółki.

Polish Company Data Core pozostaje źródłowym, server-only backendem; browser nie dostaje surowych snapshotów ani service-role.

Cykliczny refresh

gotowe

Scheduler monitoringu ma aktywną konfigurację uruchomień.

Health produktu potwierdza obecność runtime secretu schedulera bez ujawniania jego wartości.

Detekcja semantyczna

gotowe

Alert powstaje dopiero po trwałej zmianie fingerprintu i semantycznej różnicy Było → Jest.

Pierwszy stan jest baseline. Sam refresh bez zmiany nie tworzy alertu.

Decision Inbox

gotowe

Inbox ma operacyjny kontrakt alertu: materialność, znaczenie, rekomendowany krok i provenance.

Warstwa prezentacyjna przechowuje tylko minimalny payload alertu, a nie pełny stan źródłowy.

Twoja watchlista

oczekuje

Mechanizm jest gotowy; dodanie pierwszego KRS uruchamia prywatny monitoring dla tej watchlisty.

Token watchlisty pozostaje w HttpOnly cookie, a baza produktu przechowuje wyłącznie jego SHA-256.

Dostarczenie alertu

gotowe

Alerty są dostępne w prywatnym Decision Inbox po zalogowaniu capability watchlisty.

Email, SMS i webhook nie są obecnie deklarowane jako aktywne kanały. Brak kanału zewnętrznego jest jawny, nie symulowany.

Granica bezpieczeństwa

gotowe

Core i prywatna baza produktu pozostają rozdzielone.

Service-role Core jest używany wyłącznie po stronie serwera; klient otrzymuje tylko przetworzony wynik produktu.

Decision Inbox

Dodaj pierwszą firmę i zbuduj prywatny monitoring.

Inbox pokazuje tylko trwałe różnice wykryte pomiędzy snapshotami. Zwykły refresh źródła nie jest alertem, a pierwszy snapshot służy wyłącznie jako baseline.

Nieprzeczytane

Krytyczne

Istotne

Health

subjectów z błędem

Dodaj firmę do monitoringu

Wklej KRS. Jeden podmiot jest odświeżany raz niezależnie od liczby obserwujących.

prywatna watchlista

Obserwowane firmy

0 firm · 0 nieprzeczytanych zmian

Watchlista jest pusta. Dodaj pierwszy KRS powyżej.

Inbox zmian

Alert = konkretne Było → Jest + znaczenie + rekomendowany następny krok + provenance.

Brak wykrytych zmian. Pierwszy snapshot jest baseline’em i nie tworzy alertu.

Bez fałszywej daty

Gdy źródło nie podaje daty prawnej, pokazujemy okno detekcji zamiast ją zgadywać.

Bez alertu za refresh

Zmiana powstaje z różnicy fingerprintów stanu, a nie z samego pobrania danych.

Bez surowego snapshotu

Inbox przechowuje tylko kompaktowe etykiety Było/Jest. Pełny stan źródłowy pozostaje w server-only Company Core.

Granica danych

Produkt obserwuje Core. Nie miesza się z Core.

Polish Company Data Core pozostaje neutralnym, server-only backendem źródeł i historii. Prywatne watchlisty, stan przeczytania oraz fan-out alertów należą do osobnej bazy Rejestr360. Browser nie dostaje service-role ani sekretu Core; widzi wyłącznie wynik przez warstwę serwerową Rejestr360. Monitoring Readiness nie ujawnia też prywatnych liczników użytkowników ani sekretów runtime.