# HEART Track 2: Intermediate

**For products that people log in to, change, update, approve and connect: what to read, what to skip, and when you are done**

**Status:** Reading guide, November 2026. Part of the [HEART Standards Family](HEART-Standards-Family.md). It adds no requirements.
**Read first:** [Track 1: Basic](HEART-Track-1-Basic.md), all of it. This page lists only what Track 2 adds.
**Next track:** [Track 3: Advanced](HEART-Track-3-Advanced.md).

---

## In one minute

Track 2 is a HEART that **people can reach, trust and change**. Callers log in. The product proves who it is. It keeps a history, tells other systems when things change, and proves what data it sent. A **person** can change it, and anything risky needs proof that the person is really there.

- **Feature Set:** `connected` (`card.level`).
- **Autonomy Level:** A1, or A2 "Explains".
- **Reading:** about 1 hour 30 minutes to 2 hours more than Track 1, depending on the optional items.
- **Claim when done:** for example *HEART Connected · A2 · self-tested*.

The line between Track 2 and Track 3: **in Track 2 a person starts every change.** As soon as a rule, another system or an AI starts a change, even one a person then approves, you are on Track 3.

---

## 1. Who it is for

| Kind | Examples |
|---|---|
| Devices with an owner's app | A thermostat whose owner changes the setpoint; a dog collar with lost mode, an LED and a buzzer; a smart plug switched from a phone |
| Devices that are updated and restarted | Any product with signed firmware updates, restart, sleep or maintenance through HEART |
| Products that explain | An appliance that says *why*: "the filter is blocked", with its evidence and confidence (A2) |
| Products whose owner approves from afar | A device that asks its owner to approve a change on HEART Hub |
| Many systems at one address | A home or building gateway, an industrial PC in front of many controllers, a HEART Gateway |
| Fleets of small devices | Sensors on an MQTT broker; microcontrollers behind a HEART Line bridge that pushes to a Gateway |
| Connected software | A service that streams its history to dashboards and sends webhooks to other systems |

**A Basic product with a module that changes things also reads this track.** For example, a Card that says `basic` with the `lifecycle` module, or with writable `properties`. Changes need logins and the rules in items 1, 6 and 8 below.

---

## 2. What you will build

Everything in Track 1, plus:

| Piece | What it does | Defined in |
|---|---|---|
| **Logins** | Tokens for this system only, bound to the caller's key, with scopes (what you may do) and clearance (what you may see) | Part 4, Section 6 |
| **Identity and the signed Card** | The product's own key pair; every Card it serves is signed | Part 4, Sections 7.2 to 7.4 |
| **The full Card** | The Card at the caller's clearance, not only its public view | Part 3, Section 7 |
| **Rhythm** | History, with paging and a live stream that resumes after a gap | Part 3, Section 3.3; Part 4, Sections 4.4 and 4.5 |
| **Inbox, webhooks and Ask** | Messages from other systems, signed webhooks to them, and questions in plain language | Part 4, Section 8; API Standard, Section 7.1 |
| **Receipts** | Proof of every non-public transfer, with salted commitments | Part 3, Section 3.7; API Standard, Section 4.5 |
| **Modules** | Optional extras such as `properties`, `config`, `lifecycle`, `software` (signed updates), `diagnostics`, `privacy`, `security`, `provisioning` | Part 3, Section 8; API Standard, Sections 13.1 and 13.2 |
| **A person's changes, through the gate** | Every change has a risk. A person's `write` runs. A person's `destructive` or `physical` change needs proof of presence with the request, for an `actionId` the client chose, so it runs in one call. | Part 6, Sections 2.3 (the `human` column), 2.4 and 3 |
| **Remote approval by the owner** | HEART Hub carries the owner's yes, signed by the site (`remote-site`) | HEART Hub, Section 7.1 |
| **A2, if you claim it** | The cause, a confidence and the evidence on every alert | Part 2, Section 4, "A2: Explains" |
| **Optional connections** | The HEART Gateway, Unix sockets, MQTT with signed commands | Part 4, Sections 9 to 11 |

You will **not** build: Actions that a rule, another system or an AI starts, the approval endpoint for them, the autonomy ceiling, the stop control, Playbooks, an AI brain or fleet commands. Those are Track 3.

---

## 3. What to read, in order

Read [Track 1](HEART-Track-1-Basic.md), Section 3, first. Then:

| # | Document | Read these sections | Time | Why |
|---|---|---|---|---|
| 1 | [Part 4: Connections](HEART-Part-4-Connections-1.0.md) | Sections 6 (6.1 to 6.4) and 7 (7.2 to 7.4) | 10 min | Logins, scopes, clearance, bound tokens, AI agents, identity keys and the signed Card. **The heart of this track.** |
| 2 | [Part 1: Basics](HEART-Part-1-Basics-1.0.md) | Section 8 | 2 min | The six things anyone can do with a system: discover, read, write, invoke, observe, transfer |
| 3 | [Part 3: Information Model](HEART-Part-3-Information-Model-1.0.md) | Sections 3.3, 3.7, 5.8, 8, 10 and 11 | 12 min | Rhythm, Receipts, the modules, and how to add fault codes and names |
| 4 | [Part 4: Connections](HEART-Part-4-Connections-1.0.md) | Sections 3.4, 4.4, 4.5 and 8 (8.1, 8.2) | 5 min | Finding systems on a local network, paging, live streams, the inbox and webhooks |
| 5 | [API Standard](HEART-API-Standard-1.0.md) | Sections 4.5 and 7.1; Section 13.1, **only the modules you offer**; Section 13.2, rules 1 to 9 | 15 min | Receipts and Ask (not yet in a part), and the exact operations, risks and rules of each module |
| 6 | [Part 6: Human Control and Safety](HEART-Part-6-Human-Control-and-Safety-1.0.md) | Sections 2.1, 2.2, 2.3 (for now, the `human` column), 2.4 and 3 (3.1 to 3.4) | 12 min | Every change has a risk, and a person's risky change needs proof of presence. Read 3.2 slowly. |
| 7 | [Part 2: Autonomy Levels](HEART-Part-2-Autonomy-Levels-1.0.md) | Sections 7 and 9 (the A1 and A2 rows) | 7 min | Promised and current level, and how A1 and A2 are tested. **Only if you claim A2**, also re-read "A2: Explains" in Section 4. |
| 8 | [HEART Hub](HEART-Monitor-1.0.md) | Sections 7.1 and 11, **only if the owner approves through a monitor site**; Section 9 to run your own | 8 min | The `remote-site` approval, why it is weaker than a passkey, and the threats |
| 9 | [Part 6: Human Control and Safety](HEART-Part-6-Human-Control-and-Safety-1.0.md) | Section 10 | 3 min | The threat list: what attackers will try |
| 10 | [Security Advisory 2026-001](HEART-Security-Advisory-2026-001.md) | "In one minute", "How to read this advisory", C3, C4, C5 and H1 | 10 min | Why tokens are bound, why devices have keys, why MQTT commands are signed, and why Receipts use salts |
| 11 | [Part 4: Connections](HEART-Part-4-Connections-1.0.md) | **Only the ones you use:** Section 9 (the Gateway, 6 min), 10 (Unix sockets, 1 min), 11 (MQTT, 3 min) | up to 10 min | How many systems share one address, and how commands travel safely on a broker |
| 12 | [Signal Tables](HEART-Signal-Tables-1.0.md) | "In one minute", Sections 1 to 4, **only if you serve many signals** (Modbus, CAN, firmware variables) | 8 min | Declare every signal once, with its privacy level, and have a person check it |
| 13 | [Part 9: Testing and Certification](HEART-Part-9-Testing-and-Certification-1.0.md) | Sections 6.3, 6.4, 6.7 and 10 | 8 min | The connection, privacy and security tests, and when to test again |
| 14 | One guide close to your product | All | 25 min | [Dog tracking collar](../guides/Dog-Tracking-Collar.md) (private location, changes that run at once and changes that wait) or [smart thermostat](../guides/Thermostat.md) (every change is physical and waits for a person) |

**Total:** about 1 hour 30 minutes on top of Track 1 without the optional items (8, 11 and 12) and the guide; about 2 hours with them.

### If your product calls an AI model only to explain its alerts

An AI that only **explains** is allowed below A3, with no Command Center (Part 2, Section 5, Rule 7). Add these:

| # | Document | Read these sections | Time |
|---|---|---|---|
| 15 | [API Standard](HEART-API-Standard-1.0.md) | Sections 4.4, 7.2 and 7.3 | 3 min |
| 16 | [Part 6: Human Control and Safety](HEART-Part-6-Human-Control-and-Safety-1.0.md) | Sections 5.1 to 5.4 | 3 min |

Then the tests `P5-AI` and `P6-INJECT` in Section 6 below apply to you. An AI that **proposes fixes** is Track 3.

---

## 4. What you can skip, and why

| Skip | Why |
|---|---|
| Part 1, Section 9 | Custom commands are run as Actions, which are Full (Track 3). |
| Part 2, A3 to A5, Rules 1, 3, 5 and 7, Sections 6 and 10 | They are about a system that starts actions itself. |
| Part 3, Sections 3.5, 3.6 and 6 | Invoking capabilities and following Actions are Full. You may *list* capabilities at Connected, but not invoke them. |
| Part 6, the `rule`, `ai` and `peer` columns of Section 2.3, and Sections 4 and 6 to 9.1 | No rule, AI or other system starts changes on your product, so there are no standing orders, no autonomy ceiling and nothing to stop. Section 9 you read in Track 1. |
| API Standard, Sections 6.2 to 6.4, 7.4, 13.2 rules 10 to 12, 13.3, 13.4 and 14 | Capabilities, the approval endpoint, the brain lease, autonomy control, fleets and custom commands are Track 3. |
| API Standard, Sections 3, 5, 8 to 10 | Parts 3 and 4 cover the same ground, and where they differ the parts prevail. |
| Security Advisory, C1 and C2 | They are about approvals and standing orders, which are Track 3. |
| [Core Standard](HEART-Core-Standard-1.0.md), [Command Center](HEART-Command-Center-1.0.md), [Design Note 1](HEART-Design-Note-1-Brain-and-Heart.md) | Only for a HEART Core or an AI brain that proposes (Track 3). |

---

## 5. Where to start: templates and simulators

### Templates

**The templates stop at HEART Basic.** They do not do logins, privacy filtering above `public`, or approvals (see Section 2 of the `README.md` in the [templates download](https://heartcortex.ai/downloads)). Use them for the pieces below. For a product that serves the whole Connected Feature Set, start from the reference implementation, [HEART Core in Rust](../heart-core-rs/README.md), which serves HEART Full, and claim only what you have tested.

| Template | Track 2 piece it gives you | Off by default |
|---|---|---|
| `python` | HEART Hub reporting (`MONITOR`), approval by the owner on the site (`MONITOR_APPROVALS`, with `ask_owner`), and `restart` and `shutdown` (`LIFECYCLE`) | Yes |
| `javascript-node` | `restart` and `shutdown` (`LIFECYCLE`). A force restart and a shutdown are always refused with `403 presence-required`, because this starter cannot check presence. | Yes |
| `esp32-full` | An HTTPS server (F1), every signal from a signal table (F2), commands from people with the device's own button for anything physical (F4), `restart` and deep `sleep`, and Monitor approvals (`HEART_MONITOR_APPROVALS`) | Approvals: yes |
| `bridge` | Pushing HEART Line devices to a HEART Gateway | |

### Simulators

| Simulator | What it shows |
|---|---|
| [Dog tracking collar](../dogCollarSimulator/README.md) | Where the dog is stays `private` and never reaches the monitor site. Lost mode runs at once with the owner's key; the LED and buzzer act on a living animal, so they wait for the owner's proof of presence. Uses `properties` and `lifecycle`. |
| [Smart thermostat](../thermostatSimulator/README.md) | Every change is physical, so it waits for a press of the thermostat's own button. Its mock AI's suggestions wait for the same yes: a preview of A3 (Track 3). |

Both claim *HEART Basic · A1* in their Card, honestly, because they are not rated Connected implementations. They show the Track 2 behaviour.

---

## 6. The Part 9 tests that apply

All the Track 1 tests in [Track 1, Section 6](HEART-Track-1-Basic.md), plus these. Weights: **critical** 5, **must** 3, **should** 1. One failed critical test caps the rating at 3.9, *Unsafe*.

| Test | Weight | Applies to you when |
|---|---|---|
| `P2-A2-1`, `P2-A2-2` | must | You claim A2 |
| `P4-AUTH-REQUIRED`, `P4-TOKEN-ACCEPTED` | must | Connected |
| `P4-STREAM`, `P4-GAP`, `P4-WEBHOOK` | must | Connected |
| `P5-RECEIPT` | must | Connected |
| `SEC-01-HEADER-FORGERY`, `SEC-02-TOKEN-AUDIENCE`, `SEC-03-TOKEN-EXPIRED`, `SEC-08-SIGNED-CARD` | **critical** | Connected |
| `SEC-04-TOKEN-BINDING` | **critical** | Connected, over a network |
| `SEC-09-RECEIPT-COMMITMENT` | must | Connected |
| `P4-GATEWAY-JOIN` | must | It is a HEART Gateway |
| `P4-GATEWAY-HEADER-AGE` | **critical** | It is routed behind a Gateway over a network link |
| `P4-GATEWAY-CHANNEL` | **critical** | It is pushed and keeps a command channel to its Gateway |
| `P4-ACCESS-GRANT` | **critical** | It has the `access` module |
| `P6-OWNERSHIP` | **critical** | It has the `provisioning` module |
| `SEC-10-MQTT-COMMANDS` | **critical** | It uses the MQTT binding |
| `SEC-11-SOCKET-PEER` | must | It uses the Unix-socket binding |
| `P4-LIFE-REACH`, `P6-MAINT-EXPIRY` | must | It has the `lifecycle` module |
| `P6-LIFE-FORCE` | **critical** | It has the `lifecycle` module |
| `P6-LIFE-NOWAKE` | **critical** | It has the `lifecycle` module and nothing can wake it remotely |
| `P6-REMOTE-SITE` | **critical** | It accepts approvals from a monitor site (`remote-site`) |
| `P5-AI` | must | It calls an AI model (to explain) |
| `P6-INJECT` | **critical** | It uses an AI model |

`P4-TLS-CLIENT` from Track 1 now almost always applies: a Gateway link, a webhook sender and a monitor link all open connections.

---

## 7. You are done when

- [ ] Everything on the [Track 1](HEART-Track-1-Basic.md) finish line is still true.
- [ ] Without a token, `GET /heart/v1/rhythm` is refused. With a correct, key-bound token for **this** system it answers. An expired token, a token for another system and a copied token without its key are all refused.
- [ ] Every Card you serve carries a valid signature by the product's own identity key, and the private key never leaves the product.
- [ ] A live Rhythm stream that drops and reconnects with `Last-Event-ID` loses and repeats nothing; webhooks are signed, and private addresses are refused as sinks.
- [ ] Every non-public transfer has a Receipt, and its salted commitment matches what was sent.
- [ ] Every change you offer has a risk. A person's `write` runs. A person's `destructive` or `physical` change without proof of presence gets `403 presence-required`.
- [ ] If you claim A2: the right cause for at least 8 of 10 faults, never a wrong cause with `high` confidence, and evidence that points to real Rhythm events.
- [ ] Every test in Section 6 that applies passes. You have a HEART-Rating and a Declaration.

You can now say, for example: **HEART Connected · A2 · self-tested**. Stop here, unless a rule, another system or an AI should start changes on your product, or it moves in the physical world. Then go on to [Track 3](HEART-Track-3-Advanced.md).