I built an OSINT bot for counterparty due diligence, and it nearly defamed a real company on its first serious run.

The idea is simple. Feed it a company name, it pulls from open sources (corporate registries, Companies House, GLEIF, sanctions and PEP lists, WHOIS, social profiles) and spits out a report: risk score, red flags, a timeline, and a PASS / REVIEW / FAIL call.

I tested it on a real target. Came back MEDIUM to HIGH risk. Scary timeline, several red flags, looked solid.

Then I checked what the score was actually resting on.

Almost all of it came from one thing: a real court ruling about some business in the same county. Real case, real verdict. The problem was that the company I was checking wasn't named in that source at all. The bot connected the two because they sat in the same area, around the same time, in the same industry. That was enough for it to drop someone else's scandal into this company's file.

What surprised me is that the real danger in OSINT isn't fabricated information at all. It's accurate information attached to the wrong company. Whether an event actually happened tells you nothing about whether the link to your target is real. And letting the model "just work it out" isn't a design choice, it's you gambling with legal exposure.

So I rebuilt the logic.

Every link now gets tagged CONFIRMED, PROBABLE or UNVERIFIED. CONFIRMED means the target is named directly in a primary source, or at least two independent strong identifiers line up (registration number, full street address, a named director or owner).

Only CONFIRMED evidence can move the risk score or show up as a red flag. Everything weaker goes into a separate "unverified adjacent signals" box, tagged with which weak signal caused the guess and the one identifier that would settle it. That box has zero effect on the verdict.

Not finding a company in a registry is now a data gap, not a red flag. Plenty of businesses trade under a different entity or as sole traders.

And on top of all that, a guard step: if any red flag comes through as anything other than CONFIRMED, the whole report build fails. The scoring can no longer take the model's word for it.

None of this is exciting to build, but it's the part that matters. Automating due diligence isn't really about a model reaching conclusions for you. Most of the actual work is writing evidence rules that the code enforces whether the model likes it or not. A hedge buried in a paragraph won't protect you. If an unverified signal can shift the verdict even slightly, sooner or later it will smear the wrong company on its own.

This is going into Quantum Prism. Next job is writing test cases the validator is supposed to fail on, because a tool that checks everyone else should survive being checked itself.