Lex Sentinel: what I learned taking an AI legal monitor from its first client to its second
How Lex Sentinel monitors public legal sources, why its AI is selective, and what broke when it stopped serving a single client Lex Sentinel, the legal monitoring service I build, now serves judges' associations in two
How Lex Sentinel monitors public legal sources, why its AI is selective, and what broke when it stopped serving a single client

Lex Sentinel, the legal monitoring service I build, now serves judges' associations in two Brazilian states, Rio de Janeiro and São Paulo. The São Paulo deployment was the first that required adapting the platform to a set of sources different from the one it was born with.
This post is not the announcement. It is the product from the inside: the problem, the architecture decisions, and what changed when it stopped serving a single client.
The problem
Judges' associations need to know, ahead of time, what is going to be judged, voted on or published that affects their members. That information is scattered across courts, judicial councils and legislative houses, each with its own format, calendar and publishing rhythm.
Done by hand, it is a daily routine of opening websites, comparing against what has already been seen, and hoping not to miss an extraordinary session agenda or a late amendment.
The flow at a high level
Four principles shape the design:
1. Only what is new triggers an alert. The value of the service lies in what has changed. Re-sending what the recipient already got trains people to ignore alerts, and an ignored alert is worse than no alert.
2. Silence also has to be proven. If nothing arrived, was it because nothing changed or because the monitor broke? That is why there is an end-of-day report confirming each source was checked, with or without news, plus a public status page.
3. You don't own the source. Public websites change structure, go offline and publish late without notice. The system has to treat this as the normal state, not as an exception: detect the break, flag it, and make it quick to adapt the monitor.
4. A managed service, not a tool. The association operates nothing. It receives information. All configuration lives on the operator's side.
The most counterintuitive decision: when not to use AI
The temptation in an AI product is to run everything through the model. Testing with real sources, the result was clear:
- Session agendas and orders of the day benefit a lot. The AI identifies the cases, summarizes what each judgment is about, and highlights points of attention. It turns a document into a fast decision.
- Full official gazettes don't. They are long, cumulative documents. The model produces a generic summary that helps no one decide, and cost grows with document size.
So pre-processing is selective, decided source by source. A gazette becomes an alert with a direct link; an agenda becomes an alert with analysis. Less AI in the right place delivered more value than AI everywhere.
What changed after the first client
Lex Sentinel was born inside one association's routine. The second deployment exposed what was coupled without my noticing:
- Sources per instance. The set of sources, the delivery type for each one, and the recipients became per-association configuration, not assumptions in the code.
- New sources, new formats. Each new source brought a different publishing structure. That reinforced the split between a source-specific collector and the rest of the pipeline, which is shared.
- Configuration as a deliverable. Deployment became a stage of its own: configure monitors, sources and channels, validate against real data, and only then go live.
The good side effect: the platform became more robust for the third association than it was for the second.
Cognitive infrastructure
The way I think about Lex Sentinel is as a layer of cognitive infrastructure: something that continuously watches sources, organizes signals, and delivers information ready for whoever has to decide. The AI does not replace the professional who interprets the agenda. It takes away the digging.
If you work on public-source monitoring, resilient scraping, or selective use of LLMs in pipelines, I'd like to hear how you handle "proven silence" and source breakage. Let me know in the comments.
Learn more: lexsentinel.allrox.com.br
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.
