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. It adds no requirements. Read first: Track 1: Basic, all of it. This page lists only what Track 2 adds. Next track: Track 3: Advanced.
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, Section 3, first. Then:
| # | Document | Read these sections | Time | Why |
|---|---|---|---|---|
| 1 | Part 4: Connections | 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 | Section 8 | 2 min | The six things anyone can do with a system: discover, read, write, invoke, observe, transfer |
| 3 | Part 3: Information Model | 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 | 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 | 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 | 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 | 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 | 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 | Section 10 | 3 min | The threat list: what attackers will try |
| 10 | Security Advisory 2026-001 | "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 | 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 | "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 | 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 (private location, changes that run at once and changes that wait) or smart thermostat (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 | Sections 4.4, 7.2 and 7.3 | 3 min |
| 16 | Part 6: Human Control and Safety | 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, Command Center, Design Note 1 | 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). 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, 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 | 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 | 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, 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 finish line is still true.
- Without a token,
GET /heart/v1/rhythmis 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-IDloses 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
writeruns. A person'sdestructiveorphysicalchange without proof of presence gets403 presence-required. - If you claim A2: the right cause for at least 8 of 10 faults, never a wrong cause with
highconfidence, 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.