Monitor Judicial — Plataforma Multi-cliente
Reads the official gazettes of 91 courts every night and delivers to each client only what is theirs — as a PDF, shielded against false positives.
- publications read per day
- 1,1 mi+
- courts monitored
- 91
- briefs delivered to clients
- 1.800+
From pain to result
Before
Over a million publications a day across more than 90 courts — and one generic company name is enough to send a client a case that is not theirs.
Tracking the court publications of dozens of companies across more than 90 courts, every day, is impossible by hand: there are over a million publications a day.
Company names are ambiguous. A generic alias matches someone else’s case, and the client receives a brief that is not theirs — the worst possible error here.
And the source changes without notice. One day a field stopped coming and the run finished "OK", with no error in the log, delivering 2 briefs instead of about 70.
How · 1/3
I built a single engine, parameterised per client, that streams the day’s gazettes, identifies cases by the registered aliases and consolidates one brief per case — with tables, recipients and mail server isolated per client.
How · 2/3
Matching goes through a cascading shield (deny list, allow list, minimum length, generic terms), and the dashboard dry-runs each alias before enabling it, showing why each occurrence would be rejected.
How · 3/3
Around the engine, an API and a web dashboard: client, company and alias setup, its own scheduler, runs with a live log, brief re-sending and regeneration, audit trail and access profiles.
After
Every night the platform reads the gazettes, separates what belongs to each client and delivers one brief per case, as a PDF, to each client’s email.
- 1,1 mi+
- publications read per day
- 91
- courts monitored
- 1.800+
- briefs delivered to clients
Reading the diagram
The scheduler triggers collection at night and the probe holds the run while the source is down. Gazettes are streamed in; matching uses each client’s aliases; the brief is consolidated per case, completed with metadata when that source responds, and emailed through the client’s own mail server. The dashboard sets up, dry-runs and re-sends. The single database drawn here keeps each client’s data in isolated tables.
Technical highlights
- 1 Streaming reads: a 300 MB gazette that needed 1.3 GB of memory now fits in 2.5 MB — giant public notices no longer bring collection down.
- 2 "Not attempted" is not "failed": a source outage becomes a state of its own, retried automatically every 30 minutes, instead of a run that writes zero and says OK.
- 3 When a field stopped coming from the source, the case number started being derived from its own digits — never invented —, and reprocessing 114 matches unlocked 74 briefs in 8 minutes, without stopping the run in progress.
- 4 New case or new movement? The decision checks three sources and, when in doubt, treats it as already known: better not to announce as news what the client already knows.
- 5 Enrichment is a complement: if the metadata source fails, the brief goes out without it rather than not at all. The paid monitoring source has a spending cap and is never named in the delivered document.
- 6 One client never sees another: the engine refuses to run if one client’s configuration points at another’s tables.