How it works

A claim declares its evidence. Something else decides whether it holds.

Brainlyy stores plain markdown, resolves the evidence a claim names against checks you configured, and computes a status on a schedule you set. Your assistant reaches all of it over MCP.

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.

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.

A note declares a claim. It does not grade itself.

A note names the 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.

In the note

claim.md

---
claim: KYC is complete for onboarding path B
evidence: [kyc_mode, sanctions_clear, approver_recorded]
recheck: 1d
---

evidence holds names, never commands, URLs or paths.

In your config

config.yaml

checks:
  kyc_mode:
    kind: http
    url: http://127.0.0.1:9000/health/kyc
    contains: fail_closed

Names resolve only to checks you put here yourself. A note is untrusted input, because your assistant writes notes, so a name can never become a command.

Kind	Passes when
file	the path exists, and contains the string if contains is set
http	the response is under 400, and contains the string if set
cmd	the command exits 0, and its output contains the string if set

A cmd check takes an argv list, never a string, and never runs through a shell. It also can't be created from the dashboard at all: config is the only place allowed to define something executable, and the dashboard is a network-reachable surface.

Three states, all computed.

VERIFIED

Every piece of evidence passed a check, within the recheck window. It expires, because an old pass is not a pass.

UNVERIFIED

The claim is checkable, and something failed, is missing, or expired. The reason is named, never hidden.

ASSERTED

Nothing here is machine-checkable, so no check will ever run. Judgement calls and decisions live here honestly, with no badge pretending otherwise.

ASSERTED is not a failure. Most of what a knowledge base holds is legitimately in it: judgements, decisions, context, things that are true but not mechanically testable. Pretending otherwise is how you get a system that lies more confidently than the notes did.

What counts as checkable.

All three have to hold:

the subject resolves to an artifact: a file, an endpoint, a record, a command's output
the predicate is true or false without judgement
it is falsifiable now, not eventually

“The sanctions screen returned clear on this account” qualifies. “Our approach to onboarding is sound” doesn't, and never will. Declare the second one anyway. It just stays ASSERTED.

Running it, and the number that matters.

Every run appends to an evidence log that is never rewritten, so you can reconstruct what supported a claim on a given date.

brainlyy verify reports how long the longest-lived false claim read VERIFIED before a run caught it. That number is the point of the whole thing.

Claims, checks and evidence in full

shell

$brainlyy verify
$brainlyy verify --strict