Proposals

Requires brAIn 1.44, and 1.46 for three of the five producers

1.42 shipped the tab and half the lifecycle. The Proposals store, the replay and the routine miner all landed there — but pressing Try it for a week set a status and an end date and nothing ever looked at the week, and pressing Enable it recorded a status without creating an automation. Both are real in 1.44: the trial is graded on every checks pass, and an accept writes the automation, reloads Home Assistant and checks it is running before the row leaves the list.

1.45 added emergency playbooks, and 1.46 the other three producers: the condition an over-ridden automation is missing, one-off intents and the scene designer.

People automate less than a tenth of what they do by hand. Not because the rest is hard — because writing an automation means deciding the trigger, the condition and the edge cases up front, for something you have never watched yourself do.

Your logbook already recorded every one of those manual presses, with who made it and when. brAIn reads that and offers the automation.

The fifth kind of knowledge

brAIn keeps its knowledge in separate stores on purpose, because mixing them makes each one worse:

	The question it answers	Where it lives
Memory	What is true of this home?	A document
Guesses	What might brAIn have wrong?	Findings tab
Findings	What is broken?	Findings tab
Activity	What happened?	Activity tab
Proposals	What could be better?	Proposals tab

A proposal gets its own tab rather than joining the work list. A list of things you might want, sitting beside a list of things that are broken, makes both worse — the broken things stop looking urgent and the nice-to-haves start to.

The lifecycle

proposed  →  trialling  →  accepted
    ↓
 declined

Proposed. brAIn has found a pattern and written the automation. Nothing is enabled. You see what it would do, and the replay against your own last month.

Trialling. You press Try it for a week. Nothing is created, nothing is called and nothing subscribes to your events. The trial is a replay of the week as you live it: every checks pass, brAIn replays the proposed automation over the days since you started it and grades each firing against the ledger of changes you made by hand. The card fills in as the week goes on rather than staying blank until Sunday —

It would have fired 6 times. On 5 of those you did the same thing by hand.

Accepted. It becomes a real automation in your automations.yaml, and it is yours — edit it, disable it, delete it, like any other. See Saying yes, and taking it back.

Declined. It goes away, and you can say why in a sentence. That sentence is the half that teaches, exactly as a finding’s Wrong does: “the hall light stays on because my partner works nights” is a fact brAIn did not have, and it stops the same proposal coming back in different words next month.

A declined proposal is remembered by the change it described, not by the sentence describing it — so a miner that rewords its own explanation is still offering something you have already answered, and it will not come back.

Nothing brAIn proposes is ever enabled on its own

The trial changes nothing and calls nothing, and the automation only exists once you press Enable it or Keep it. You can press it straight away without trialling — nothing stops you — but then it is a suggestion you liked rather than one you watched, and an automation you accepted after seeing it be right five times out of six is a different object from one you accepted because it sounded reasonable.

The three verdicts

Every firing the replay finds lands in exactly one bucket, decided by the nearest press, so a verdict never depends on the order the ledger happens to be in:

Agreed — you put the same thing in the same state within a quarter of an hour of the moment it would have fired.
Nothing happened — weak evidence either way, and it is named for what it is rather than counted against the change.
You did the opposite — you put the entity to the opposite state inside that window. You would have undone it, which is the one answer worth having, and it is deliberately not folded into the second.

A press that puts the entity somewhere else entirely is not evidence about a proposal to turn it on, so it leaves that firing unanswered rather than counting against it.

When the week is up the row stays where it is with its report attached. Ending a trial is your press, not brAIn’s — there is no seventh-day deadline that quietly decides for you.

What a trial cannot grade

Two silences, and they are not the same one. “It would never have fired” is about the automation; “brAIn cannot replay this” is about brAIn, and the trial says which rather than reporting a confident zero. The replay’s own limits are carried through verbatim.

There is a third: an action that is not one entity going to one state — a scene, a script, three service calls in a row — has nothing single to grade your press against, and guessing which of them counts is how a confident wrong number gets made. Those trials report that instead of a score.

Saying yes, and taking it back

Accept writes a real automation. It is appended to automations.yaml with an id of brain_<proposal id>, the proposal’s title as its alias, and a description saying where it came from. Your file is not reformatted: the automation goes on the end and everything above it is left byte-for-byte as you wrote it, comments, ordering and quoting included.

Two of the five producers write something else. A scene set carries four moods rather than one automation and lands in scenes.yaml, checked against the scene: !include scenes.yaml line and reloaded with scene.reload — the same five steps against a different file. And a condition proposal changes an automation you already have rather than adding one beside it: brAIn splices exactly the bytes of that one entry and every other byte of the file is identical afterwards. The card carries an Edits your rule pill so you know which of the two you are agreeing to before you press, and the toast afterwards says changed rather than added, because a toast claiming an addition would send you looking for a second automation that is not there.

Then three things have to be true before the row leaves the list, and they are three different claims that were being reported as one:

The file was written.
Home Assistant read it — automation.reload.
The automation exists — the new automation.<name> entity actually turns up.

Only the third is what you meant by pressing the button. A mode: Core does not recognise, a trigger from a custom integration that has not loaded, a read-only /config — each of those leaves a file on disk and a reload that returns quite happily with no automation behind it.

If any of the three fails, brAIn puts the file back, reloads again, and tells you what it tried in a sentence. A yes it could not honour is not a yes it records: the proposal is exactly where it was, with no memory line and no settled entry, ready to press again once the reason is fixed.

When it works, the settled entry keeps the automation_id and the entity_id — “accepted” and “accepted, and here is what it became” are different claims, and only the second can be checked against the house six months later. You also get a notification about it, worded as a change you asked for rather than as a problem brAIn found, and it is sent rather than held for quiet hours: it answers a press you made seconds ago.

Undo

The toast carries an Undo for five minutes, and it reverses all three effects or says which one it could not. The automation is removed, Home Assistant is reloaded, and the proposal comes back on the list under its own id — along with the memory line the accept had queued. A trial that was still running when you accepted it comes back as a proposal rather than as a trial whose week has since passed, because try it for a week is a promise about the next seven days.

If the file cannot be put back it says so rather than claiming a success, because the automation is still running and an undo that lied about that would be worse than one that reported the failure.

automations.yaml is snapshotted into the same edit journal that records Claude’s own edits before it is touched, so brain undo in the terminal reverts an accepted proposal exactly as it reverts anything else brAIn changed — there is no second undo mechanism to keep true. See the CLI.

Four things stop an accept, each in a sentence

A protected entity. Anything in the add-on’s protected_entities option — locks, alarms, whatever you listed. That rule is enforced in the MCP server, at the chokepoint every Claude path to your house goes through, and a YAML file the panel writes is not one of its callers — so this path asks the same question the same way. An action naming an area or a device rather than named entities is refused outright while the list is not empty, because resolving one needs registries this does not have, and a protected entity reached through its area is the bypass.
No automation: !include automations.yaml. With packages, a split config or automation manual:, your automations live somewhere brAIn cannot find, and appending to a file Home Assistant does not read is a change that silently does nothing. The refusal names the line it looked for rather than guessing at another file.
An automations.yaml that is not a list of automations. That is your config in a shape brAIn does not understand. (An empty or missing file it will create, exactly as Home Assistant does.)
A duplicate id or name. Two automations with one id is a config Core refuses to load; two with one alias is a house where nobody can tell which is which.

The habit miner drops a protected entity too, one layer earlier — the writer has to refuse one, being the last gate before /config, but a card offering something brAIn will not do is a wasted no.

What gets proposed

Five producers file here, and two of them you can start yourself. The ask bar on the Insights tab routes a sentence that opens with a moment — when…, once…, the next time…, tell me when… — to a one-off intent, and one that asks for scenes and names a room to the scene designer. Everything else on this page is offered on a house-checks pass, off evidence brAIn already had.

Routines you already have

“You have turned the hall lamp on yourself on 10 of the last 10 weekday evenings, at 18:40 give or take 4 minutes. Nothing in Home Assistant does it for you.”

brAIn keeps the changes a person caused — and only those. An automation moving a light says nothing about a habit, and a wall switch reaches Home Assistant with no record of who pressed it, which brAIn reports as unattributed rather than guessing at. Two months are kept, in the domains a timer can sensibly act on.

What it writes is a plain time trigger, with a weekday or weekend condition when the habit has one — and never a condition it did not measure. The ledger knows when you did something; it does not know what else was true at the time, so a trigger inventing a condition would be brAIn guessing in the one place you cannot check it.

The floors that keep this from being noise, each one tested against a house with no habit in it before it is tested against one that has:

Six separate days, not six presses. Twelve presses on one Monday is one Monday.
A share of the days it could have happened on. Six times in a fortnight is a habit; six times in two months is a coincidence — and a count with no denominator reports both identically. Weekdays and weekends are counted apart, so a weekday habit is graded against weekdays rather than being marked down for the two days it was never going to happen on.
A time, not a stretch of evening. The times are averaged around the clock — half past eleven and half past midnight are forty minutes apart, and a plain average of them is noon — and anything looser than about three quarters of an hour is not a time of day.
It has to be still happening. A habit you dropped two months ago has a beautiful shape in the history and is not a proposal.
Nothing must already do it. A second automation moving the same thing to the same state is not a helpful duplicate; it is two rules that will disagree the first time their triggers land in the wrong order.

Every day has to be earned twice, once on each half of the week. A habit on ten weekdays and one Sunday clears the whole-window share comfortably, and calling it daily would build a trigger that fires on two mornings you are asleep — so a genuinely daily habit reads as weekdays for its first three weeks, until six weekend days have accrued. That is the cheaper mistake of the two.

A pass offers at most three, strongest first. The rest are still in the ledger next time.

Emergency playbooks

Since 1.45: the automation you would want on a bad night — smoke or CO, a water leak, a freeze with the heating stopped — written from your own registries. brAIn never runs one; Home Assistant does, once you have accepted it. Emergency playbooks covers what each one does and what none of them will ever do.

The card is the same card with four differences, because the evidence for a playbook is not a replay:

A Playbook pill in the head, so it does not read as a habit brAIn spotted.
The list of what it would act on, grouped by what happens to each group and counted — “Every light to full brightness (12)” — with anything on your protected_entities list shown as Skipped: protected rather than quietly left out. Seeing that brAIn knows the valve is there and knows it may not touch it is the point of showing it.
Rehearse it, a disclosure that reads the house right now and renders every call against each target’s current state, changing nothing. It fetches when you open it, not with the card — it reads every state in the house, and a tab of five playbooks would ask five times before anybody looked at one.
No trial button, and the reason where the button would have been. A trial replays the week you have just lived, and that week had no emergency in it.

The card also carries the sentence saying what this one will never do — on the smoke playbook, that it will not unlock any door and will not disarm the alarm, because that is where somebody decides.

Accepting one goes down the path above, unchanged. There is no separate switch.

The condition it is missing

When brAIn has watched you put the same automation back, at about the same time of day, on enough separate days, it can say more than “you keep undoing this”. The finding reports the fight; this is the change that ends it.

Stand Evening lights down between 21:00 and 23:00 on weekdays

The case on the card is a pair of numbers, because one alone is a fact about an automation rather than an argument for changing it:

Over the last 30 days it ran 30 times. With this condition it would have run 22 — 8 fewer, in the hours you keep putting it back.

If the two numbers come out the same the card says so in as many words, rather than dressing it up: over the window the recorder can answer for, the change would have made no difference, and that is worth knowing before you say yes.

One condition, and it is negated

What gets written is a single time condition inside a not. That is not decoration, and the obvious shape is wrong in the direction that breaks a working house.

A time condition is a conjunction: it passes only when the clock is inside its window and the day is in its weekday list. Add one directly and the automation stands down every Saturday and Sunday as well, at every hour — which is not remotely what you have been telling brAIn by undoing it on weekday evenings. Wrapped in a not, it says the narrow thing the evidence actually supports.

It is added to whichever spelling of the key your entry already uses (condition: or conditions:), because rewriting one as the other would be brAIn deciding how your file is spelled.

The evidence is the ledger’s, and is never re-derived

The hours and the days come straight from the override ledger, which already carries every floor that makes a band mean anything: at least four overrides, on at least three separate days, the most recent one inside the last week, and at least three quarters of them inside the band — which is reported as the hours actually occupied rather than as the window that found them. Asking those questions again here would be a second answer to “is this a pattern”, and the second answer is the one nobody can see.

A pattern with no weekday or weekend shape to it is not offered at all. Whenever is not a condition, and one that stood an automation down at every hour of every day it was ever undone would be a switch somebody else has to go and find.

Four things stop it, and they are not cards

The automation has no id. Home Assistant’s own editor cannot change one either — there is nothing stable to address it by. Open it in the automation editor and save it once.
It already stands down over those hours. You wrote the condition; a second copy of it is noise.
Its existing time condition names an entity — an input_datetime, say — rather than a clock. brAIn cannot read what that already forbids, and “I could not tell” may not be read as “there is nothing there”, so it will not add a second condition beside it.
It acts on a protected entity.

None of those becomes a card, because every card on this tab is something you can answer and that one is not. They are named in ⚙ Diagnostics instead, with the automation each is about — “brAIn found nothing” and “brAIn found this and named the thing to change” are different reports, and an empty tab reads the same either way.

A pass offers at most three, strongest evidence first.

One-off intents

Since 1.46, the ask bar has a third verb. A sentence that opens with a moment — “turn the porch light off when the guests leave”, “tell me when the tumble dryer finishes” — never becomes an insight card. It becomes one automation that runs once and switches itself off, and it arrives here with your sentence, what brAIn understood, and a replay of the trigger.

brain.intent is the same thing from a voice command or an automation, through the same request file.

Accepted one-offs then sit above the proposals with their own pill — Armed, It fired, Not armed — because a one-off is waiting on the house where a proposal is waiting on you. That is also why the tab’s badge never counts them. One-off intents covers the arming, the fortnight, the Remove and every sentence brAIn will refuse.

Four scenes for a room

The fourth producer, and the only one you address by name: “design my evening for the living room”, or the Design scenes for picker at the top of this tab.

Its card is the one exception to the shape of everything else here. There is no replay and no trial button, because nothing in the last month set these scenes and there is no week to grade them against — the evidence is a swatch per light per mood instead, with the bulbs named underneath and anything protected shown as skipped. Accepting writes four scenes to scenes.yaml, and once they really exist brAIn offers a second proposal — the schedule that moves between them, which is an ordinary automation and can be tried for a week. The scene designer covers the moods, the capabilities and the two refusals.

Where to see it

The Proposals tab in the panel.
GET /api/proposals — the store as JSON.
Declines are recorded with their note, so the scorecard can show which producers earn their place. A proposal source that gets declined nine times out of ten stops proposing.