Findings

A finding is something wrong with your house. A dead battery. A sensor that hasn’t changed value in six days. A device stuck unavailable. An automation whose trigger entity was renamed, so it can never fire again.

brAIn files them on its own, while it was looking at something else — findings come out of the same insight runs and study sessions that fill memory. You never ask for them.

Three kinds of knowledge, and they don’t mix

	The question it answers	How it ends
Memory	What is true of this home?	It’s a document; it just gets better
Guesses	What might brAIn have wrong?	Yes or No, once
Findings	What is broken in this home?	Fixed, or dismissed

A finding is never just an observation. “The dryer used 3 kWh” is an insight. “The dryer’s energy sensor has read exactly 3 kWh for six days” is a finding — something is wrong and somebody has to do something about it.

Each one names the entity, the number and the day it started, because a work list item you can’t check is just a worry.

The stores stay separate, but the deciding happens in one place. The tab is headed “What’s waiting on you” because open guesses ride at the top of the same list with ✓ Yes / ✕ No — a broken thing and a doubted belief are different knowledge, but answering either is the same job, and the tab badge counts both. Turning down a guess offers the same reason box as calling a finding wrong.

What findings actually look like

These are the kinds of thing that show up in a real house:

• A sensor that died quietly. “sensor.back_door_battery has reported nothing since 26 July. Last reading 8% at 04:11. The door sensor still reports state, so this is the battery entity only — but your low-battery automation can no longer see it.”
• An automation that can never fire. “automation.morning_lights triggers on binary_sensor.hall_motion_old, which was renamed three weeks ago. It has not run since.”
• A device that came back wrong. “Two Aqara loft sensors have been silent since 24 July at 14:30 — the same minute your Zigbee coordinator moved from channel 15 to 20.”
• Something that contradicts itself. “automation.away_lights is gated on presence, but the living-room motion sensor keeps the house ‘occupied’ all day. It has not fired this month.”
• Tidy-up. “13 entities belong to devices that no longer exist. They show as unavailable on three dashboards.”

The same problem is never raised twice

Findings are deduplicated by meaning, not by wording. A problem reported in one run and described differently in the next is recognised and dropped, so the list stays a list of distinct things rather than a rolling feed.

Fix it

✦ Fix it sends Claude to make the change, in your actual Home Assistant. It confirms the problem is still real, finds the cause rather than the symptom, makes the smallest change that resolves it, verifies the change took, and reports back with exactly what it touched.

A real one, end to end:

A finding, fixed

FINDING   automation.morning_lights can never fire
          Its trigger references binary_sensor.hall_motion_old,
          renamed to binary_sensor.hall_motion on 8 July.
          Last run: 23 days ago.

✦ Fix it

          Read automations.yaml — trigger entity confirmed stale
          Edited the trigger to binary_sensor.hall_motion
          Validated automations.yaml — OK
          Reloaded the automation domain
          Re-read the config — trigger now resolves

FIXED     1 file changed: /config/automations.yaml

It is bounded on purpose:

• One finding per run. Anything else it notices along the way becomes its own finding rather than an edit you didn’t ask for.
• It never deletes an entity, automation, dashboard or file it didn’t create — it disables or corrects instead.
• It never restarts Home Assistant. Reloading one config domain is fine; a restart is your call.
• It never touches secrets or credentials.
• Nothing runs until you press it. brAIn will not change your house on a schedule.

Every file it writes is snapshotted first, so brain undo puts one back if a fix goes wrong.

Some things software can’t fix — a flat CR2032, a device that needs re-pairing from the loft hatch. Those are marked needs you and offered without a Fix it button, because inventing a software substitute for a dead battery is worse than saying so.

Discuss it first

💬 Discuss opens the finding as a conversation in the Terminal tab, with everything brAIn knows already in the question — the detail, the fix it had in mind, the entity, the severity. It is asked to look into the thing and say plainly whether it really is a problem in your house, and told to change nothing, because “explain this to me” and “go change my house” are different permissions.

The decisions come with you: while you’re talking it over, a strip above the message box keeps Fix it, I fixed it, Later and Wrong one press away. The strip’s ✕ Wrong opens the same reason box the card’s does — explaining it to Claude in the chat reaches that one conversation; the note reaches every future one.

The two endings

Ending a finding removes it. Which ending you pick matters, because each one teaches brAIn something different:

✓ I fixed it — it was a real problem and it’s sorted now. Memory records “Fixed by the homeowner: the back door sensor battery was replaced.” It offers an optional note, and what you type is simply more of the fact — nothing is being corrected: “Replaced the CR2032 — it’s a 3-monthly job on that one.” “I fixed it” leaves brAIn knowing a problem is over; that sentence leaves it knowing your house.

✕ Wrong — brAIn has misread your house. The sensor isn’t stuck; it’s a contact on a cupboard nobody opens. Pressing it opens a box for one sentence — “That sensor always reads on. It’s not stuck.” — and the sentence is the half that teaches. It goes two places: it’s shown verbatim under this finding in every future analysis, and it’s queued to memory as a correction. It is deliberately not treated as an instruction — brAIn is handed what you said and works out what standing fact follows from it, sometimes nothing at all — so you don’t have to phrase a correction carefully for it to be useful.

Both boxes are optional. Send Wrong empty and it simply says “never raise this again”; “not a problem here” needs no essay.

Both endings do the same three things: the answer goes into memory as a plain fact about your home, the wording is remembered so the problem is never reported at you again, and the row is deleted. There is no pile of dismissed cards to scroll past — a list of things nobody has to look at again is not a work list.

Dismiss, which is neither

⌫ Dismiss clears the row and teaches brAIn nothing. No memory line, no suppression — so the next analysis is free to find the same thing again, and probably will if it’s still there.

That’s the difference from Wrong, and it’s why both exist:

	What you’re saying	What brAIn learns
✕ Wrong	This is normal here — you’ve misread it	Never raise it again, and why
⌫ Dismiss	Not now, and I’m not promising anything	Nothing
⏰ Remind me later	Yes, but not yet	Nothing — it comes back on your date

Use Dismiss when you’re clearing the board rather than answering it.

⏰ Remind me later is the answer for “yes, but not now” — an hour, tomorrow, next week, next month. It is not a decision and settles nothing: the finding stays exactly as open as it was and simply stops asking. Use it instead of dismissing something you actually intend to deal with — a dismissed row only comes back if a later run happens to find the problem again; a snoozed one comes back on your date. While it waits it sits under Later, showing when it comes back, with a button to bring it back sooner.

After brAIn fixes something

A fixed card stays on the list and turns green, with what changed and which files were touched. That’s deliberate: brAIn altered something in your house, and news you haven’t read is not settled. ✓ Got it clears it once you have.

Where answered findings go

Nowhere, and that’s the design. Ending one writes the answer into memory and deletes the row — so memory is the record, and the tab has two filters rather than an archive: Needs you, and Later once something is waiting in it.

brAIn still remembers what you answered. A settled finding’s wording is kept in a ledger the analyst consults before reporting anything, so the same problem is never raised at you twice, however it gets reworded. That ledger isn’t a screen — it’s the reason the list stays short.

A wrong press has an Undo

Every press that takes a row off the list — both endings, Got it, Dismiss, and either answer to a guess — leaves an Undo in the toast for about five minutes. It puts back all three effects of an ending: the row, under its original timestamp; the suppression that would have stopped brAIn raising it again; and the line it queued for memory. It exists because “I fixed it” and “Wrong” sit next to each other meaning opposite things, so a mis-tap is not hypothetical — and it is deliberately “I pressed the wrong one”, not a history. Once a consolidation pass has filed the fact into the document, Undo says so rather than pretending; editing the document is the honest answer by then.

Fix it has no Undo, because it has already sent Claude at your actual house, and taking the card back would lie about what was undone. Remind me later has none either: it took nothing away, and it already has Bring it back now.

The tab, scriptable

brain findings in the terminal is the same tab as text:

brain findings                     # list open findings (and guesses waiting)
brain findings fix 1786715730      # send Claude to fix one
brain findings done 1786715730 "replaced the CR2032"
brain findings wrong 1786715730 "that sensor is meant to sit closed"
brain findings ack 1786715730      # "Got it" after an automated fix
brain findings snooze 1786715730 tomorrow    # hour | tomorrow | week | month | now

Everything goes through the panel’s own API, never the store files — so a CLI ending writes the same memory line, the same settled-ledger key and the same Undo token the tab’s buttons do. The chat’s command palette picks the subcommands up automatically.

Getting them to your phone

Findings live in the add-on’s private storage, which Home Assistant cannot see — so the add-on publishes a mirror to /config/.brain/findings_state.json on every change, and again at panel startup so a reboot never serves last week’s list. The integration builds three things on it:

• sensor.brain_open_findings — the open count, with the severity split and the finding texts as attributes, so an automation can put what’s actually broken on a lock screen.
• A brain_finding event per newly-filed finding, for automations and the logbook. It’s primed at startup, so a restart never replays the open list as news.
• A push notification, if you want one: set the findings_notify_service option to any notify.* service, and findings_notify_min_severity to what may ring your phone (info / warning / serious / critical; the default serious means batteries about to die ring, while naming nitpicks wait on the tab).

Notifications go to newly-created findings only, and the store dedupes across every status and the settled ledger — so the same problem can never ring twice, however it’s reworded. A failed delivery is a log line, never a lost finding: the row is on the list before the mirror is touched.