Insolvenční rejstřík
Každá pohledávka v ISIR, po celý její životní cyklus
Progresus ISIR průběžně zrcadlí insolvenční rejstřík a rekonstruuje z něj to, co v metadatech není: kolik věřitel přihlásil, kolik mu bylo popřeno, komu pohledávku postoupil a kolik nakonec dostal. Každý údaj nese odkaz na zdrojový dokument a stránku.
Stav: pilot. Příjem událostí z WS ISIR do repliky, stahování dokumentů a vytěžování přihlášek (OCR + LLM, každá hodnota ověřená citací v dokumentu) běží. Ověřené pohledávky jsou v aplikaci — přehled a průzkum pohledávek, jen pro čtení a s přihlášením. Zprávy o přezkumu, databáze věřitelů a účetní závěrky zatím ne. Přesný stav po oblastech je na roadmapě.
Problém: data v rejstříku nejsou strukturovaná
Webová služba ISIR publikuje neměnný, číselně uspořádaný proud událostí od roku 2008 — ale nese jen metadata: spisovou značku, typ události, typ dokumentu a odkaz na PDF. Výše pohledávek, zajištění, výsledky přezkumu i identita věřitele leží uvnitř dokumentů, převážně skenů. Z toho plyne celý návrh systému.
%% title: Cesta údaje od rejstříku k analytikovi
%% caption: Příjem metadat a zpracování dokumentů běží ve dvou oddělených frontách. Do projekce se zapíše jen hodnota, která prošla validací a prahem spolehlivosti; ostatní jde k člověku. Schéma popisuje návrh, stav po oblastech drží roadmapa.
flowchart LR
subgraph SRC["Zdroj"]
WS[("WS ISIR<br/>proud akcí")]
end
subgraph ING["Příjem"]
POL["Poller<br/>jeden zapisovatel"] --> REP[("Replika<br/>append-only log")]
end
subgraph DOC["Dokumentová pipeline"]
DL["Stažení PDF"] --> EX["OCR + LLM<br/>extrakce do schématu"] --> VAL{"Validace<br/>a práh"}
end
subgraph OUT["Čtení"]
PRJ[("Projekce<br/>odvozená")] --> API["Čtecí API<br/>a aplikace"]
end
WS --> POL
REP -- "akce s dokumentem" --> DL
REP --> PRJ
VAL -- "jisté" --> PRJ
VAL -- "nejisté" --> Q["Fronta<br/>lidské kontroly"]
Q -- "rozhodnutí je událost" --> PRJ
click WS href "/docs/semantika-zdroje" "Sémantika zdroje ISIR"
click POL href "/architecture/jeden-zapisovatel-mnoho-ctenaru" "Jeden zapisovatel, mnoho čtenářů"
click REP href "/architecture/event-sourcing-protoze-zdroj-je-event-stream" "Event sourcing"
click DL href "/architecture/oddelena-dokumentova-pipeline" "Oddělená dokumentová pipeline"
click EX href "/architecture/ocr-a-llm-extrakce-do-schematu" "OCR + LLM extrakce do schématu"
click VAL href "/architecture/confidence-je-plnohodnotne-pole" "Confidence je plnohodnotné pole"
click Q href "/roadmap/fronta-lidske-kontroly" "Fronta lidské kontroly"
click PRJ href "/about/log-je-pravda-projekce-je-odvozena" "Log je pravda, projekce je odvozená"
click API href "/api" "Přehled API"
class Q st-in_progress
Barva uzlu je stav položky na roadmapě: Rozpracováno
Event sourcing, protože zdroj je event stream
Systém je konzumentem oficiálního proudu událostí. Z něj staví lokální append-only repliku a z ní přehrává projekci aktuálního stavu. Oprava chyby v interpretaci znamená přehrát log, ne znovu stahovat rejstřík.
Detail
OCR + LLM extrakce do schématu
Klasické OCR na formulářích přihlášek selhává. Pipeline kombinuje OCR a multimodální extrakci do deklarovaného JSON schématu, výsledek validuje a teprve pak zapisuje.
Detail
Confidence je plnohodnotné pole, ne řádek v logu
Každá vytěžená hodnota nese skóre spolehlivosti, použitou metodu a stránku dokumentu. Pod prahem nejde do projekce, ale do fronty lidské kontroly — u vysokých nominálů je práh přísnější.
Detail
Tři moduly
Modul 1: Databáze pohledávek
RozpracovánoStavový automat na úrovni dílčí pohledávky: přihlášena → přezkoumána → popřena či zjištěna → incidenční spor → postoupena → uspokojena → řízení skončeno. S kompletní historií přechodů a zdrojovým dokumentem u každého z nich.
Detail
Modul 2: Databáze věřitelů
RozpracovánoIdentifikace proti ARES, segmentace a agregáty napříč celým rejstříkem: přihlášený nominál, míra popření, realizovaná výtěžnost a aktivita na sekundárním trhu podle §18.
Detail
Modul 3: Účetní závěrky věřitelů
PlánovánoZávěrky ze Sbírky listin pro cílový segment, OCR a validace bilančními rovnicemi, ukazatele likvidity a zadluženosti. Vstup do skóre motivace věřitele prodat.
Detail
%% title: Tři moduly a k čemu vedou
%% caption: Rozsah podle zadání APS-200. Moduly staví na sobě: pohledávky dávají věřitele, věřitelé cílový segment pro účetní závěrky, a všechno dohromady investiční pohled.
flowchart LR
ISIR[("Insolvenční rejstřík<br/>WS ISIR")] --> M1["Modul 1<br/>Databáze pohledávek"]
ARES[("ARES")] --> M2
M1 --> M2["Modul 2<br/>Databáze věřitelů"]
SL[("Sbírka listin")] --> M3
M2 -- "cílový segment" --> M3["Modul 3<br/>Účetní závěrky věřitelů"]
M1 --> I{{"Investiční inteligence<br/>co koupit, kdo prodá, jaká výtěžnost"}}
M2 --> I
M3 -- "motivace k prodeji" --> I
click M1 href "/product/databaze-pohledavek" "Modul 1: Databáze pohledávek"
click M2 href "/product/databaze-veritelu" "Modul 2: Databáze věřitelů"
click M3 href "/product/ucetni-zaverky-veritelu" "Modul 3: Účetní závěrky věřitelů"
click ISIR href "/docs/semantika-zdroje" "Sémantika zdroje ISIR"
click ARES href "/docs/identifikace-veritelu" "Identifikace věřitelů"
click I href "/product" "Co systém dělá"
class M1 st-in_progress
class M2 st-in_progress
class M3 st-planned
Barva uzlu je stav položky na roadmapě: Rozpracováno Plánováno
K čemu to je
Investiční inteligence pro trh s pohledávkami. Věřitel s napjatou likviditou, který drží nezajištěnou zjištěnou pohledávku v konkursu s očekávanou výtěžností v jednotkách procent a horizontem let, je kandidát na odkup. Systém takové situace hledá — a u každého čísla umí ukázat, ze kterého dokumentu a z které stránky pochází.
Číslo bez zdroje není údaj
Každá vytěžená hodnota je dohledatelná ke konkrétnímu dokumentu a stránce. Bez toho nelze odpovědět na žádost subjektu údajů, na spor o částku ani na otázku, proč se metrika změnila. Provenience proto podmiňuje samotný zápis.
Detail
Rozsah je etické rozhodnutí
Systém záměrně nesbírá oddlužení nepodnikajících fyzických osob: největší objem, nejnižší hodnota a nejvyšší citlivost. Nesbírá je proto, že je nepotřebuje.
Detail