How it works
Tiers, the read and write split, and why the evaluator owns a claim's status rather than the note.
Nothing is required, everything is detected
Most tools of this shape hand you a prerequisites list: a model runner, a vector database, a VPN, a server, a domain. You are five installs deep before anything responds.
Brainlyy inverts that. Every dependency is probed, never assumed and never read from config. Config says what you would like; detection says what is actually there. A capability asserted from config is a prerequisite wearing a disguise: it turns a missing dependency into a runtime crash instead of an absent feature.
Tiers
| Tier | You have | You get |
|---|---|---|
| 0 | Python | notes, file search, code graphs, MCP server |
| 1 | + a local model runner | ask your own models |
| 2 | + a vector store | embedding search over your notes |
| 3 | + an SSH host | a scheduled agent fleet |
| 4 | + a domain | reachable from phone and web assistants |
Tiers describe your machine to you. They gate nothing. A missing dependency is a capability that is absent, never an error, never a crash, and never a surprise at 3am.
Two servers, not one
Most MCP servers expose reads and writes behind one credential, so a leaked token is total.
Brainlyy runs two. The read server binds your private mesh address. The write server binds loopback, and the process refuses to start on anything else. That is an exit code, not a policy. They hold different tokens.
Every argument these tools receive began as model output, and model output can be steered by anything the model has read. A read tool talked into misbehaving returns a wrong answer. A write tool talked into misbehaving acts.
The evaluator owns the status, not the note
A note declares a claim and the evidence it rests on. It does not get to say how
it is doing. Write status: VERIFIED in frontmatter and it is ignored, and
the note is flagged as having tried to certify itself.
| State | Means |
|---|---|
VERIFIED |
every piece of evidence passed a check, recently |
UNVERIFIED |
the claim is checkable, and something failed or expired |
ASSERTED |
nothing here is machine-checkable, which is legitimate and common |
Evidence is named, and the names resolve only to checks you put in config. A note is untrusted input, because your assistant writes notes, so a name can never become a command.
This rule exists because of a real bug in this project: the dashboard used to call a note VERIFIED because the text contained the word, and drew a green badge for it. Nothing verified anything, in the one tool whose premise is catching claims that carry no check. See Claims.
It tells you when it is lying
brainlyy doctor reconciles what the system claims against what is true:
whether every agent is still writing to its log, whether each agent's stated
schedule matches its actual jobs, whether the knowledge base contains any
claim on your forbidden list, what is overdue. Silent when healthy.
That exists because of two real failures. A knowledge base asserted a regulatory status that was false and fed it into daily reports for thirteen days. And a context file that said "loaded by all agents on every run" was loaded by nothing at all. Every correction made to it was inert, with no error to say so.
Confident wrongness is the failure mode of systems like this.
Closed sets, not filters
repos and agents in your config are allowlists, because their values
arrive as model output and become filesystem paths and executables. A closed
set is a security control, not a convenience list.
Honest caveats
- The vector store, agent fleet and public edge are tiers you stand up. Brainlyy detects and drives them; it does not install them.
- Tier 0 note search is lexical ranking over markdown. It is slower and dumber than embeddings. It is also the reason the tool does something useful thirty seconds after install.
brainlyy doctorreconciles what it can observe. It cannot tell you that a claim is wrong, only that it is unmarked, stale, or contradicts your forbidden list.- The web UI binds loopback by default. Reaching it from a phone means serving HTML on your mesh address. See Security.