About

Confident wrongness is the failure mode of systems like this.

Brainlyy was extracted from a working deployment, and every boundary in it exists because something went quietly wrong first.

A false fact fed daily reports for thirteen days.

In the deployment Brainlyy was extracted from, a knowledge base asserted a regulatory status that was false. It went into the daily report, every day, for thirteen days. Nothing caught it, because nothing was checking.

Nothing in a plain note tells you “true” from “was true” from “never checked.” It all reads identically, and an assistant repeats any of it with the same confidence.

So Brainlyy makes the distinction mechanical: a claim declares its evidence, the evidence gets checked, and the status gets computed on a schedule you set, not on a hope you have.

A context file loaded by nothing at all.

The second failure was quieter. A context file said it was “loaded by all agents on every run.” It was loaded by nothing. Every correction anyone made to it was inert, and no error ever said so.

That is why brainlyy doctor reconciles what the system claims against what is observable: whether every agent is still writing to its log, whether a stated schedule matches actual jobs, what is overdue. It's silent when healthy, which is the only way a check like that stays worth reading.

We shipped the exact bug this tool exists to catch.

Early on, Brainlyy's own dashboard decided a note was VERIFIED by checking whether its text literally contained the word “VERIFIED,” then drew a green badge for it. In the one tool built to catch claims with no real check behind them.

We found it, fixed it, and wrote it up at the top of the changelog. The fix demoted most existing notes. That was the correct outcome, because the badges had been wrong.

That is the standard here. When we miss it again, you will read about it in the same place.

What that buys you, and what it does not.

Brainlyy can tell you a claim is unmarked, stale, or contradicts a list you set. It can't tell you a claim is wrong. Detecting a claim that has become false with no check covering it is the harder problem, and it isn't built yet.

A claim is also only ever as good as its check. Proving a file exists is not proving its contents mean what you think. Those limits are written down in the documentation rather than left for you to discover.

How it works, in full

Open, and staying that way.

MIT licensed, developed in the open, with the property suite shipped inside the install so an instance can check itself rather than take our word for it.