# The HEART Standards Family **A map of the whole standard, in plain language** **Author:** Milind K. Patil, Syncaissa Systems Inc. **Status:** Proposal, November 2026. This document says how the standard is organised. Parts 1, 2, 3, 4, 6 and 9 are drafted; the rest of the text still lives in the API and Core Standards (see "Which text applies"). **Track:** Every track, optional: "In one minute", and the section on the two kinds of level. The rest is for people organising the standard. --- ## In one minute HEART used to be two big documents. It is now being split into **nine short parts**, like ISO 27001, OPC UA or the USB specifications. Each part answers **one question**. You read only the parts you need. | Part | Name | The one question it answers | |---|---|---| | 1 | **Basics** | What is HEART, and what do its words mean? | | 2 | **Autonomy Levels** | How much does a system do on its own? | | 3 | **Information Model** | What does a HEART tell you, and in what shape? | | 4 | **Connections** | How do I reach a HEART? | | 5 | **Privacy (the Valve)** | What data may leave, and how is it proved? | | 6 | **Human Control and Safety** | Who is in charge, and how is harm prevented? | | 7 | **HEART Core** | What runs inside the product to make all this work? | | 8 | **Product Fit** | How does HEART fit my kind of product? | | 9 | **Testing and Certification** | How do I prove my product meets the standard? | **Parts 1, 2, 3, 4, 6 and 9 are drafted:** [Part 1](HEART-Part-1-Basics-1.0.md), [Part 2](HEART-Part-2-Autonomy-Levels-1.0.md), [Part 3](HEART-Part-3-Information-Model-1.0.md), [Part 4](HEART-Part-4-Connections-1.0.md), [Part 6](HEART-Part-6-Human-Control-and-Safety-1.0.md) and [Part 9](HEART-Part-9-Testing-and-Certification-1.0.md). Three profiles are drafted too: [Signal Tables](HEART-Signal-Tables-1.0.md) (for Part 8), [HEART Hub](HEART-Monitor-1.0.md) (for Parts 4 and 5), and [HEART Command Center](HEART-Command-Center-1.0.md) (for Parts 2 and 6: the brain switch). The other parts will be made mostly by moving text that already exists (see "Where today's text goes" below). --- ## Why split it at all? Think of a car. The owner's manual, the repair manual, the safety rating and the road rules are separate documents. One giant book would be useless to everyone. HEART has the same problem. A buyer wants to know "how much does this product do on its own?" A firmware engineer wants message formats. A tester wants a checklist. Today they all have to read the same 1,500 lines. Splitting helps in four ways: 1. **Each reader reads less.** A buyer reads Part 2. A tester reads Part 9. 2. **Parts change at their own speed.** A new connection type (Part 4) does not reopen privacy (Part 5). 3. **Small things get adopted.** MQTT and USB spread because the first step was small and clear. 4. **Other standards can use one part.** An industrial group can adopt the Autonomy Levels without adopting HTTP. --- ## How the parts fit together ``` ┌───────────────────────────────┐ │ Part 1 BASICS (read first) │ └───────────────┬───────────────┘ │ ┌─────────────────────────┼─────────────────────────┐ │ │ │ WHAT IT SAYS HOW YOU REACH IT WHO IS IN CHARGE Part 3 Information Part 4 Connections Part 2 Autonomy Levels Model Part 5 Privacy Part 6 Human Control │ │ │ └─────────────────────────┼─────────────────────────┘ │ ┌───────────────┴───────────────┐ │ Part 7 HEART CORE │ what runs inside │ Part 8 PRODUCT FIT │ per kind of product └───────────────┬───────────────┘ │ ┌───────────────┴───────────────┐ │ Part 9 TESTING & CERTIFYING │ proves all of it └───────────────────────────────┘ ``` A simple way to remember it: - **Parts 3 and 4** are the *language*: what is said, and how it travels. - **Parts 2, 5 and 6** are the *rules*: how much freedom, what stays private, who decides. - **Parts 7 and 8** are the *build*: what goes inside, and how it fits your product. - **Part 9** is the *proof*. --- ## Each part, explained ### Part 1: Basics **Question:** What is HEART, and what do its words mean? The idea of HEART, the main words (system, Card, Pulse, Arrhythmia, Valve and so on) defined once, and how HEART relates to other standards such as MCP, A2A, OPC UA, Web of Things and OpenTelemetry. **Everyone reads this first.** It should take about 15 minutes. **Drafted.** See [HEART-Part-1-Basics-1.0.md](HEART-Part-1-Basics-1.0.md). ### Part 2: Autonomy Levels **Question:** How much does a system do on its own? Six levels, **A0 to A5**, from "it does nothing on its own" to "it handles new problems by itself, within limits you set". This is the part people will quote: "this washing machine is HEART A3". **Drafted.** See [HEART-Part-2-Autonomy-Levels-1.0.md](HEART-Part-2-Autonomy-Levels-1.0.md). ### Part 3: Information Model **Question:** What does a HEART tell you, and in what shape? The things every HEART can say, described without tying them to any one protocol: - **Card**: the system's identity and what it can do - **Pulse**: how it is right now - **Arrhythmia**: an alert that something is wrong - **Rhythm**: the history of what happened - **Capabilities**: things it can be asked to do It also holds the **registries**: shared lists that everyone uses, such as the standard alert codes and standard action names. This is how OBD-II works in cars: code P0300 means "engine misfire" on every car in the world. **Drafted.** See [HEART-Part-3-Information-Model-1.0.md](HEART-Part-3-Information-Model-1.0.md). Because Part 3 does not depend on HTTP, the same model can later be carried by OPC UA, Matter, LwM2M or the Asset Administration Shell. ### Part 4: Connections **Question:** How do I reach a HEART? HTTP, MQTT, local sockets, in-process use, ports 43278 and 7685, the `heart://` address, and the HEART Gateway that lets thousands of systems share one address. It also covers login and encryption on each connection. New connection types, such as CoAP for very small devices or Bluetooth, are added here without touching any other part. **Drafted.** See [HEART-Part-4-Connections-1.0.md](HEART-Part-4-Connections-1.0.md). It also makes HEART Line v1, the serial-line format for microcontrollers, part of the standard. ### Part 5: Privacy (the Valve) **Question:** What data may leave the system, and how is it proved? Every piece of data has a privacy level (public, internal, private, never-share). The Valve lets out only what the caller is allowed to see, and writes a **receipt** for what left. Receipts are how a company can prove what it shared. ### Part 6: Human Control and Safety **Question:** Who is in charge, and how is harm prevented? - The **approval gate**: which actions need a person to say yes - The **stop button**: halts all automatic action at once - The **AI rules**: models suggest, the system checks - **Model changes**: a new AI model must pass tests before it is used - **Fleet rules**: one command to many systems is rolled out in stages - **Physical safety**: HEART stays out of safety circuits and real-time control - The **security threat list** Part 2 says *how much* freedom a system has. Part 6 says *how that freedom is controlled*. **Drafted.** See [HEART-Part-6-Human-Control-and-Safety-1.0.md](HEART-Part-6-Human-Control-and-Safety-1.0.md). ### Part 7: HEART Core **Question:** What runs inside the product to make all this work? The small runtime inside the product. It understands requests using rules and lookups first, and uses an AI model only if one is available. This is today's HEART Core Standard, mostly unchanged. ### Part 8: Product Fit **Question:** How does HEART fit my kind of product? - **Profiles**: ready-made sets of names, alerts and limits for one kind of product, such as an air conditioner, an industrial machine, a vehicle, a medical device, a building or a software app. A profile can also set the **highest autonomy level allowed** for that kind of product. For example, a medical profile might allow no more than A3. - **Custom commands**: how a product describes its own special commands and maps them to protocols such as Modbus, CAN or G-code. ### Part 9: Testing and Certification **Question:** How do I prove my product meets the standard? A checklist and test tools for every requirement in Parts 2 to 8, how to declare what you passed, and later a certification mark that buyers can trust. This works the way the Wi-Fi and Bluetooth logos do. **Drafted.** See [HEART-Part-9-Testing-and-Certification-1.0.md](HEART-Part-9-Testing-and-Certification-1.0.md). --- ## Which parts do I need? | You are | Read | |---|---| | **Anyone new to HEART** | Part 1 | | **A buyer or product manager** | Parts 1 and 2 | | **Building a device or appliance** | Parts 1, 2, 3, 4, 6, 7 and your profile in Part 8 | | **Building a software app** | Parts 1, 2, 3, 4, 5 and 6 (Part 7 if you embed the Core) | | **Writing a tool that talks to HEARTs** | Parts 1, 3 and 4 | | **Responsible for privacy or compliance** | Parts 1, 2, 5 and 6 | | **Testing products** | Part 9, and the parts you are testing | --- ## Two kinds of "level": do not mix them up HEART has two separate scales. They answer different questions. | Scale | Question | Values | Lives in | |---|---|---|---| | **Autonomy Level** | How much does it do *on its own*? | A0, A1, A2, A3, A4, A5 | Part 2 | | **Feature Set** | How much of the *API* does it offer? | Basic, Connected, Full | Part 3 and Part 9 | A phone is a good comparison. Its **feature set** is which apps and ports it has. Its **autonomy** is how much it does without you tapping anything. The current API Standard calls the feature sets "conformance levels". **Proposed change:** rename them to **Feature Sets**, so the word "level" belongs only to the Autonomy Levels. --- ## Where today's text goes Almost nothing is thrown away. Most of the work is moving and simplifying. | Today | Moves to | |---|---| | API Standard 1 (Scope, principles, roles, six primitives) | Part 1 | | API Standard 2 (Conformance levels and modules) | Part 3 (Feature Sets) and Part 9 (how to claim them) | | API Standard 3 (Envelope, message types, vocabularies) | Part 3 | | API Standard 4 (Valve) | Part 5 | | API Standard 5 (HTTP API, discovery, Pulse, Rhythm, errors) | Part 3 (what is said) and Part 4 (how it travels) | | API Standard 6.1 (Minimum Tending) | Part 2 (it is Autonomy Level A1) | | API Standard 6.2, 6.4 (Capabilities, standard names) | Part 3 | | API Standard 6.3 (Approval gate) | Part 6 | | API Standard 7 (AI and the Reason format) | Part 6 (rules) and Part 7 (how it works inside) | | API Standard 8 (System to system, authentication) | Part 4 | | API Standard 9 (Ports, addresses, Gateway) | Part 4 | | API Standard 10 (Security) | Part 6 (threat list) and Part 4 (connection security) | | API Standard 11 (Evolving) | Part 6 | | API Standard 12 (Host interface) | Part 7 | | API Standard 13 (Modules) | Part 3 (data) and Part 4 (operations) | | API Standard 13.3 and 13.4 (Fleet, autonomy control) | Part 6 | | API Standard 14 (Custom requests) | Part 8 | | API Standard 15 (Physical and safety) | Part 6 | | Appendix A (Neighbouring standards) | Part 1 | | Appendix B (Open items) | Each part's own open-items list | | HEART Core Standard | Part 7 | | `openapi/`, `schemas/`, `examples/`, `core/` | Unchanged. Parts 3 and 4 point to them. | ### Which text applies Until every part is written, the API Standard and the Core Standard stay valid for everything the drafted parts do not cover. **Where a drafted part and the API Standard or the Core Standard disagree, the part prevails.** The disagreement is a defect, and the older document MUST be corrected to match. --- ## House rules for every part These rules keep the standard simple as it grows. 1. **One question per part.** If a part answers two questions, split it. 2. **Start with "In one minute".** Every part opens with a summary a newcomer can read in one minute. 3. **Plain words.** Define every term the first time it appears. Prefer short sentences. 4. **An example for every rule.** If a rule has no example, it is probably unclear. 5. **Short.** A part should be readable in one sitting. Aim for 15 pages or fewer. 6. **Few dependencies.** You should rarely need more than Part 1, Part 3 and the part itself. Where a part depends on another, it says so in its "Read first" line. 7. **Every rule is testable.** If Part 9 cannot test a rule, rewrite the rule. 8. **Never break what works.** Within one major version (1.0, 1.1, 1.2 …), a later version may add things but MUST NOT change the meaning of what is already there. Only a new major version (2.0) may change meaning (see "Versions"). The Unicode and Kubernetes projects use the same promise. ### The requirement words The parts use these words in capitals with exact meanings (from RFC 2119): | Word | Meaning | |---|---| | **MUST** / **MUST NOT** | Required. No exceptions. | | **SHOULD** / **SHOULD NOT** | Do this unless you have a good reason, and know what you lose. | | **MAY** | Allowed, but optional. | --- ## Versions Each part has its own version number, for example "Part 2, version 1.0". A product states which version of each part it follows. - **1.0 to 1.1**: adds things only. Anything that worked still works. - **1.x to 2.0**: may change things. Used rarely, and announced well in advance. --- ## Order of work | Step | What | Why first | |---|---|---| | 1 | **Part 2, Autonomy Levels** (done as a draft) | Short, easy to understand and easy to quote. Shows what HEART is for. | | 2 | **Part 1, Basics** (done as a draft) | Everyone needs the shared words. | | 3 | **Part 3, Information Model**, with the alert-code registry (done as a draft) | The core of interoperability. | | 4 | **Part 9, Testing**, starting with Part 2's checklist (done as a draft) | A claim means nothing until it can be tested. | | 5 | **Parts 4, 5 and 6** (Parts 4 and 6 done as drafts) | Mostly moving existing text. | | 6 | **Parts 7 and 8** | Part 7 already exists. Profiles need input from each industry. | --- ## Open questions | Question | Why it matters | |---|---| | **Where will HEART be governed?** | Other companies adopt a standard more readily when a neutral organisation (such as the Linux Foundation, Eclipse or OASIS) runs it, with an open patent policy. | | **Which industry goes first?** | Profiles (Part 8) and certification (Part 9) need real partners. Industrial machines, buildings, home appliances and software apps are all candidates. | | **Who keeps the registries?** | Alert codes and action names need an owner and a simple process for adding entries. | | **Should Part 3 be published as an OPC UA companion specification or an Asset Administration Shell submodel?** | It would let HEART work inside the industrial standards that factories already use. |