# HEART Design Note 1: The Brain and the Heart

**How an embedded HEART should use a brain in the cloud, safely**

**Author:** M. K. Patil
**Status:** Design note, November 2026. Not normative. The rules it leads to are in the [HEART Core Standard](HEART-Core-Standard-1.0.md), Sections 7.1 to 7.7. The decisions in Section 5 and the new tagline (Section 7) were **confirmed by the author on 12 November 2026**.
**Track:** Advanced (Stop 3B): Sections 1 to 5. Sections 6 and 7 are background.

---

## 1. The idea, and the question

A HEART lives inside a system and sees every signal in it. When something goes wrong, it can send what it sees to the cloud, get an answer back, and act on it, for example by changing a setting.

> *The brain lives in the cloud. The heart lives in every system.* (the original tagline)

Is this still the right picture? Mostly yes. But "send everything up, do whatever comes back" has four weak points.

| Weak point | What can go wrong |
|---|---|
| **Safety** | A bad sensor reading or a wrong model answer sets a heater to a dangerous value. |
| **Offline** | The network is down exactly when the device needs help. |
| **Speed** | A motor stall needs an answer in milliseconds. A round trip to the cloud takes hundreds. |
| **Privacy** | Raw signals reveal when people are home, what they do, and how a product works inside. |

## 2. A better picture: a whole body

A heart and a brain are not enough. A body also has reflexes, memory and a sense of its own limits.

| Layer | In a body | In HEART | Where it lives |
|---|---|---|---|
| **Reflexes** | Spinal cord | Playbooks and thresholds: instant, no network | Inside the device |
| **Heart** | Heart | Awareness, guarding, acting, checking, undoing | Inside the device |
| **Nearby brain** | | A small model on a Gateway, phone or hub | Near the device |
| **Brain** | Brain | A large model: diagnosis, explanation, new fixes | The cloud |
| **Shared knowledge** | What a species learns | A fleet service that learns from many devices' outcomes | The cloud, outside the standard |
| **Muscle memory** | Skills | Learned Playbooks: a fix that worked becomes a reflex | Inside the device |

The last row is where the **Evolving** in HEART comes from. Every fix that works becomes a reflex, so a system needs its brain less as it gets older.

## 3. The rule that makes it safe

> **The brain proposes. The heart decides.**

A brain never sends a command. It sends a **Proposal**: what to change, what should happen, and when to undo it. The HEART then checks it against the facts, the device's limits, the guards and the approval rules. Only then does it try the change, in small steps, watching, and undoing it if things get worse.

This is not new. It is the Core Standard's third design rule ("Models propose, the Core checks") and Part 6's "Models suggest, systems decide", applied to fixing things. What was missing was the shape of the conversation: what goes up, what comes back, and how a change is tried and undone.

## 4. Example: a temperature that overshoots

An air conditioner overshoots its target temperature by 12% for three cycles in hot weather. Its own controller runs the real-time loop; the HEART may only change supervisory settings, such as how fast the target temperature is ramped.

1. **Detect.** A threshold raises `process.overshoot`.
2. **Reflex first.** No Playbook covers it.
3. **Summarise.** The HEART sends a Consultation: "overshoot 12%, 3 cycles, ambient 31 °C, current ramp rate 2.0 °C per minute, allowed range 1.0 to 3.0, largest step 0.2". It sends no raw readings and nothing about the people in the room.
4. **Propose.** The cloud answers: "ramp rate 2.0 to 1.6 in two steps, 10 minutes apart. Expect overshoot below 5% within 3 cycles. Undo if overshoot goes above 15% or any new alert appears. Basis: on this model, a gentler ramp overshoots less in hot weather."
5. **Check.** The target exists, the value is in range, and the steps fit the envelope. The change affects a physical process, so a person must approve it, and the HEART Hub asks the owner: "Your air conditioner wants to ramp its temperature more gently: 2.0 to 1.6 °C per minute, in two steps, and to go back to 2.0 if it gets worse. Approve?" One approval covers both steps and the undo.
6. **Try.** Ramp rate 1.8, wait 10 minutes, check. Ramp rate 1.6, check.
7. **Verify.** Overshoot is now 4%: the change is kept. Had it reached 15%, the HEART would have put back 2.0 by itself.
8. **Remember.** The HEART proposes a Playbook: "when overshoot reaches 5%, set the ramp rate to 1.6 again, staying between 1.6 and 2.0 and moving at most 0.2 at a time, and undo it as before if it does not help". The owner adopts it, confirming that it changes a physical process. Next summer, if the ramp rate has been put back to 2.0, the device fixes this on its own, in seconds, with no network.

## 5. Decisions (confirmed 12 November 2026)

**Decision 1: may the cloud change a value with no person?**
*Decided:* only for a `write` that the owner has put on the AI allowlist, only inside an envelope (minimum, maximum, largest step, changes per day), and only at Autonomy Level A5. **Never for a physical change.** Physical changes always need a person, as Part 6 already requires. The way to make a physical fix automatic is to adopt it as a Playbook after a person has approved it once. This keeps every rule in Parts 2 and 6 unchanged: it only adds envelopes, which make the allowlist stricter.

**Decision 2: is the fleet brain part of the standard?**
*Decided:* the standard defines the **formats** (Consultation, Proposal, Outcome) and the rule that a fleet's suggestion reaches each device as an ordinary Proposal. The fleet service itself, which learns that one fix works on 500 units, is a product built on top. Sharing outcomes needs the owner's permission and passes the Valve.

**Decision 3: are learned rules a formal feature?**
*Decided:* yes. A learned Playbook records where it came from, needs a person to adopt it, expires after a year unless renewed, and is suspended automatically if its fix is undone twice in a row.

## 6. Other options considered

| Option | Verdict |
|---|---|
| **Send raw signal streams to the cloud** | Rejected as a default: privacy, cost and bandwidth. Features computed on the device carry what a diagnosis needs. |
| **Let the cloud write values directly** | Rejected: it breaks the one-door and the propose-and-check rules. |
| **Digital twin**: the cloud tries a fix on a simulated copy first | Good, and compatible: a brain may test before it proposes. It does not replace the Trial on the real device. |
| **Federated learning**: devices improve a shared model without sending their data | Good for fleets, and compatible with Outcomes. It is outside the standard. |
| **A local model on a Gateway** | Already covered: the Local tier and the Gateway. Same formats as the cloud. |
| **Approval through HEART Hub** | Recommended. It turns the Monitor from a status page into the place where an owner approves fixes. |
| **Trusted brains only** | Recommended when a brain is reached over a network: the device accepts Proposals only on a token with scope `heart.propose` issued to a brain the owner registered (Part 4). |

## 7. The tagline

> **The brain can live anywhere. The heart lives in every system.**

Chosen on 12 November 2026. The original, "The brain lives in the cloud. The heart lives in every system.", was memorable, but it suggested HEART needs the cloud, and the standard says it does not. The options considered were:

1. Keep it as it is.
2. **"The brain can live anywhere. The heart lives in every system."** Chosen: true for local, Gateway and cloud brains.
3. "Thinks in the cloud. Cares in every system."
4. Keep it, and add: "And when the cloud is gone, the heart still keeps it alive."