# HEART Part 1: Basics

**What HEART is, and what its words mean**

**Author:** Milind K. Patil, Syncaissa Systems Inc.
**Status:** Working draft 1, November 2026. Part of the [HEART Standards Family](HEART-Standards-Family.md).
**Version:** 1.0 (draft)
**Track:** Basic: "In one minute", Sections 1, 2, 4 to 7 and 10. Intermediate adds Section 8. Advanced adds Section 9. Sections 3 and 11 to 13 are background.

---

## In one minute

**HEART** is an open standard that gives any product, such as an app, an appliance or a machine, a small built-in helper that:

1. **knows** what is happening inside the product, and
2. **cares** for it: spots problems, explains them, fixes what it safely can, and asks a person about the rest.

Every HEART speaks **the same language**. So one tool can ask *any* HEART product "how are you?", "what can you do?" and "what data did you share?", and understand the answer.

HEART does **not** need an AI model to do its basic job. Most of what a product needs to know about itself is already written down, so rules and lookups do most of the work. An AI model, local or in the cloud, is an optional extra.

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

This part explains the idea and defines the words. Read it first. It takes about 15 minutes.

---

## 1. The problem HEART solves

Think about the products around you: a phone app, a washing machine, a car, a factory robot, a website.

When something goes wrong inside them, three things are usually true:

1. **They don't tell you clearly.** You find out when the product stops working, or from a cryptic error code.
2. **Each one is different.** A washing machine and a web app share no common way to say "I'm unwell". Every company invents its own.
3. **AI is being added one product at a time**, each in its own way. Nobody can easily check what an AI-powered product did, why, or what data it sent away.

HEART fixes this by giving every product the same small part, with the same language, rules and privacy controls.

### A comparison: OBD-II in cars

Since 1996, every car sold in the USA has had a standard diagnostic port, called OBD-II. Any mechanic can plug in any reader and get standard fault codes. For example, code P0300 means "engine misfire" on every car, whatever the brand.

HEART aims to do the same for **every digital and physical system**, and it goes further. A HEART does not only report its faults. It also explains them, can fix the safe ones, and proves what data it shared.

---

## 2. The big idea

### First it knows, then it cares

A HEART has two jobs, in this order:

| Job | In HEART's words | What it means |
|---|---|---|
| **Know** | Reconnaissance | Keep a live picture of everything inside the product: its parts, its state, its events, its health. |
| **Care** | Tending | Act on that picture: protect, fix, explain, and ask a person when needed. |

### It lives inside the product

The HEART is part of the product itself, not a separate service somewhere else. It runs beside the product's main program as a small, separate piece of software. Engineers call this a *sidecar*. If the HEART crashes, the product carries on normally.

### Intelligence is optional

A HEART has four ways of thinking, from simplest to smartest. It always uses the simplest one that works:

| Way | How it works | Needs |
|---|---|---|
| **Reflex** | Fixed rules: "if the disk is full, raise an alert" | Nothing |
| **Recall** | Looking things up in a built-in list of everything HEART can do | A few kilobytes |
| **Local AI** | A small AI model on the device | Some computing power |
| **Cloud AI** | A large AI model on the internet | A network connection and a budget |

The first two need no AI and no internet. This means a HEART still works when the internet is down.

---

## 3. What the name means

HEART is an acronym. Each letter is one of its five qualities:

| Letter | Word | Meaning |
|---|---|---|
| **H** | Holistic | Sees the **whole** system: every part, user, event and state. |
| **E** | Evolving | **Improves** over time: learns from what worked, and adopts better AI models safely. |
| **A** | AI | **Can reason** with AI models, from any provider, when they are available. |
| **R** | Reconnaissance | **Keeps watching**, so it always knows the system's state. |
| **T** | Tending | **Takes care**: protects, fixes, explains and asks for help. |

The name is also a picture. A body's heart is inside it, works without being told to, and has a pulse you can check. Several HEART words come from this picture: **Pulse**, **Vitals**, **Rhythm** and **Arrhythmia** (Section 5).

---

## 4. What HEART is not

Being clear about limits avoids confusion later.

| HEART is **not** | Because |
|---|---|
| **A safety system** | It MUST stay out of emergency stops, overheat cut-outs and similar protection. Those must work even if the HEART is broken or hacked. |
| **A control system** | It does not run motors or keep temperatures steady. The product's own controller does that. HEART watches, advises and acts through the product's normal commands. |
| **An AI model** | It can *use* AI models, but it works without one. |
| **A cloud service** | It runs inside the product. A cloud is optional. |
| **A replacement for other standards** | It builds on existing standards and works beside them (Section 10). |
| **A certificate of safety or legal compliance** | It can provide evidence for those, but it does not replace them. |

---

## 5. The words

These are the words used across all parts of HEART. Each is defined here once. Other parts use them with exactly these meanings.

### 5.1 Who and what

| Word | Meaning | Example |
|---|---|---|
| **System** | Any product that carries a HEART. Short for *HEART-Embedded System*. | An air conditioner, a photo app |
| **HEART** | The built-in part that knows and cares for its system. | |
| **HEART Core** | The small program that runs the HEART inside a product (Part 7). | |
| **Antaryami** | The part of the HEART Core that keeps the live picture of the system. The word is Sanskrit for "the inner witness". | |
| **Owner** | The person or organisation responsible for a system. They set its rules. | A homeowner, a factory, a software company |
| **Consumer** | Anything that talks to a HEART from outside. | A dashboard, a phone app, an AI assistant |
| **Peer** | A system talking to another system. | A building controller asking an air conditioner how it is |
| **HEART Gateway** | One address that serves many systems, so thousands of devices can share one network port (Part 4). | A building's central controller |
| **Component** | A part inside a system. | A sensor, a compressor, a database, a plug-in |

### 5.2 What a HEART says

A HEART tells the outside world about itself through a small set of message types.

| Word | Meaning | Body picture | Example |
|---|---|---|---|
| **Card** | The system's identity: what it is, what it can do and what it shares. Read once. | An ID card | *"I am the CoolAir AC Controller, version 0.1. I can recalibrate sensors."* |
| **Pulse** | A short, regular "I'm alive, and this is how I am" message. | A heartbeat | *"Status: healthy."* |
| **Vitals** | The health numbers inside a Pulse. | Blood pressure, temperature | Error rate, memory use |
| **Status** | One word for overall health: `healthy`, `degraded`, `failing` or `unknown`. | | `degraded` |
| **Rhythm** | The history of everything that happened, in order. | The heart's rhythm over time | *"10:02 compressor started. 10:05 compressor stopped."* |
| **Arrhythmia** | An alert that something is wrong. | An irregular heartbeat | *"Compressor short cycling."* |
| **Flatline** | No Pulse has arrived for more than three Pulse intervals (`intervalSec`, 60 seconds by default), so the system is treated as `unknown` (Part 4). | No heartbeat | |
| **Receipt** | A record proving what data left the system, to whom, and why. | | *"Sent a 2 KB summary to the AI provider for diagnosis."* |

### 5.3 What a HEART does

| Word | Meaning | Example |
|---|---|---|
| **Capability** | Something a system can be asked to do. | `recalibrate_sensor`, `clear_cache` |
| **Action** | One request to carry out a capability, tracked from start to finish. | *"Recalibrate the room sensor, requested at 10:15, approved at 10:16, succeeded."* |
| **Tending** | Everything the HEART does to look after its system. | Noticing a fault, fixing it, reporting it |
| **Playbook** | A rule a person adopts in advance: *"when this happens, do that."* | *"If the disk is over 95% full, clear the cache."* |
| **Approval gate** | The check every action passes before it runs. It decides whether a person must say yes (Part 6). | |
| **Initiator** | Who or what started an Action: `human` (a person), `ai` (an AI model, an AI agent, or anything interpreted from plain language), `peer` (another system) or `rule` (an adopted Playbook). It comes from the caller's login token, never from the caller's own say-so (Parts 4 and 6). | |
| **Proof of presence** | Evidence, bound to one Action's **digest** (a SHA-256 fingerprint of exactly what it will do), that a real person approved that exact Action. A login alone is not proof of presence (Part 6). | A passkey confirmation on a phone |
| **Autonomy ceiling** (`max`) | The one autonomy setting of a Full system: the highest level, 0 to 5, a person allows. Anyone allowed to Stop may lower it; only a person may raise it, with proof of presence (Part 2, Part 6). | `max: 2` after Stop |
| **Mode** | What a Full system may do, worked out from its current level and never set: `observe` (0 to 2, take no action), `suggest` (3, propose, a person approves) or `act` (4 and 5, act within the gate) (Part 2, Part 6). | |
| **Guard** | A condition the system checks just before it sends a command, whoever asked, such as "only when idle". A guard that cannot be checked counts as failed (Part 6). | `maxPerHour: 60` |
| **Envelope** | The limits an allowlist entry or a Playbook puts on automatic changes: the lowest and highest value of each argument, the largest step, and how often (Part 6, HEART Core). | Set-point between 20 and 26 °C, at most 1 °C per step |
| **Proposal** | A fix suggested by an AI model ("brain"). It changes nothing until it becomes an Action and passes the gate (HEART Core). | |
| **Trial** | A Proposal carried out in small, watched steps, with the undo agreed in advance (HEART Core). | |
| **Allowlist** | The owner's list of `write` actions that may run without asking each time. Each entry names one target, the initiator kinds it applies to (`rule`, `ai`, `peer`) and, for a target with input values, an envelope. It never holds a `destructive` action (Part 6). | `clear_cache` for `rule`; `factory_reset` can never be on it. |
| **Stop** | One command that halts all automatic action at once, by setting the ceiling to 2. It always works on any system that can act on its own (A3 and above). | |
| **Escalate** | Hand a problem to a person, because the HEART cannot or may not fix it. | A notification to the installer |

### 5.4 How risky an action is

Every action has a **risk**, so the approval gate knows how careful to be.

| Risk | Meaning | Example |
|---|---|---|
| `read` | Looks only. Changes nothing. | Read a temperature |
| `write` | Changes something that can be undone. | Change a setting, clear a cache |
| `destructive` | Hard or impossible to undo. | Delete data, reset to factory settings |

An action that affects the real world, by moving, heating, powering or switching something, is marked **physical**. When an AI or another system asks for a physical action, it is always treated as `destructive`.

### 5.5 Privacy

| Word | Meaning |
|---|---|
| **Valve** | The part of the HEART that controls what data may leave the system (Part 5; until it is written, API Standard Section 4). Like a valve in the heart, it lets things through in one direction only, and only when allowed. |
| **Privacy level** | How sensitive a piece of data is. Every piece of data has one: `public` (anyone), `internal` (the owner's own people and tools), `private` (named people, for a stated reason, with consent where it concerns a person) or `never-share` (never leaves the system). |
| **Clearance** | The highest privacy level a particular consumer is allowed to receive. |
| **Fail closed** | If the HEART is unsure how private something is, it treats it as `private`. If it is unsure whether an action is allowed, it does not run it. |

### 5.6 Levels and fit

| Word | Meaning |
|---|---|
| **Autonomy Level** | How much a system does on its own, from **A0** (nothing) to **A5** (fixes new problems within limits). See Part 2. |
| **Promised level** and **current level** | The level a system is built and tested for (in its Card), and the level it can deliver right now (in its Pulse) (Part 2). |
| **Area** | Where an Autonomy Level applies: a standard area such as `connectivity`, or a named component. For example, *"A4 for connectivity and storage"* (Part 2). |
| **Scope (permission)** | A named right carried in a login token, such as `heart.read` or `heart.approve`. It says what a caller may *do*; clearance says what it may *see* (Part 4). Not to be confused with **Area**. |
| **Feature Set** | How much of the HEART API a system offers: **Basic**, **Connected** or **Full** (Part 3). The current API Standard calls these "conformance levels" and writes them in `card.level`. |
| **Module** | An optional group of features a system may add, such as `inventory` or `software` updates. |
| **Profile** | A ready-made set of names, alerts and limits for one kind of product, such as air conditioners or medical devices (Part 8). |
| **Custom definition** | A product's own description of a special command, and how to carry it out with the device's own protocol (Part 8). |
| **Conform** | To meet every requirement for something you claim, and pass its tests (Part 9). |

### 5.7 The requirement words

All HEART parts use these words in capitals, with exact meanings taken 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. |

Part 1 itself sets no requirements beyond these definitions.

---

## 6. How it fits together

```
     PEOPLE            OTHER SYSTEMS          AI MODELS (optional)
        │                    │                       ▲
        │                    │                       │ only what the
        ▼                    ▼                       │ Valve allows
  ┌──────────────────────────────────────────────────┴───┐
  │                     THE HEART API                    │ ◄ the one door
  ├──────────────────────────────────────────────────────┤
  │                                                      │
  │   KNOW                         CARE                  │
  │   Antaryami: live picture      Tending: notice,      │
  │   of parts, state, events      explain, fix, ask     │
  │                                                      │
  │   VALVE: decides what data may leave, keeps receipts │
  │   GATE:  decides which actions need a person's yes   │
  │                                                      │
  ├──────────────────────────────────────────────────────┤
  │      THE PRODUCT: its own program, sensors, motors   │
  │      (keeps running normally if the HEART stops)     │
  └──────────────────────────────────────────────────────┘
```

Three ideas sit behind this picture:

1. **One door.** Everyone, including the HEART's own AI, goes through the same API. There is no secret back door, so every privacy and safety check always applies.
2. **Two guards.** The **Valve** guards data going *out*. The **Gate** guards actions going *in*.
3. **The product comes first.** The HEART sits on top of the product and never underneath it. If the HEART fails, the product carries on.

---

## 7. A day in the life

Here is one air conditioner with a HEART, from switch-on to a fixed fault.

| Step | What happens | HEART words |
|---|---|---|
| 1 | The installer's phone app finds the unit on the network and reads who it is and what it can do. | Discovery, **Card** |
| 2 | Every 60 seconds the unit sends *"Status: healthy"*. | **Pulse**, **Vitals** |
| 3 | Everything that happens is recorded in order: compressor on, compressor off, readings. | **Rhythm** |
| 4 | The compressor starts switching on and off too often. The HEART notices and changes its status to `degraded`. | Reconnaissance, **Status** |
| 5 | It raises an alert and explains it in plain words: *"Cooling may be weak."* | **Arrhythmia** |
| 6 | It works out the likely cause: a sensor reading 3 °C too high. | Explaining (Autonomy Level A2) |
| 7 | It offers a fix, *"Recalibrate the sensor?"*, and waits. | **Capability**, **Action**, **Approval gate** |
| 8 | The owner taps **Approve**. The unit recalibrates the sensor and reports that it worked. | **Tending** (Autonomy Level A3) |
| 9 | For a second opinion it had sent a short summary to a cloud AI. It removed private data first and kept a record of exactly what was sent. | **Valve**, **Receipt** |
| 10 | The installer adopts a rule so that next time the unit fixes this by itself. | **Playbook** (Autonomy Level A4) |

---

## 8. Six things you can do with any system

Every interaction with any HEART system, from a sensor to a server, is one of six basic kinds. Engineers call these *primitives*: the basic building blocks.

| Primitive | The question | Example |
|---|---|---|
| **Discover** | What is here, and what can it do? | Read the Card |
| **Read** | What is this value? | Read the room temperature |
| **Write** | Please change this value. | Set the target temperature to 22 °C |
| **Invoke** | Please do this. | Recalibrate the sensor |
| **Observe** | Tell me when this changes. | Send me every new alert |
| **Transfer** | Move this file. | Download the error log, install an update |

These six are not new. Other device standards have used the same set for years: W3C Web of Things has properties, actions and events, and OMA LwM2M has Read, Write, Execute and Observe. HEART uses the familiar set on purpose.

---

## 9. When the standard does not know your command

No standard can list every command every product will ever need. A 3D printer, a lift and a coffee machine will always have commands nobody here predicted.

So HEART does not try to list them all. It gives every request a route, through a **ladder** of five steps. A request uses the first step that fits.

| Step | Use it when | Works the same on every product? |
|---|---|---|
| 1. **Standard operation** | Most products need it. For example, "read the Pulse". | Yes |
| 2. **Standard name** | The action is common, but each product does it differently. For example, `restart_component`. | Yes |
| 3. **Custom definition** | Only this product has it. For example, "purge nozzle 2". | It describes itself, so any tool can discover it and call it |
| 4. **Vendor path** | The product needs its own design. | No, but it is still secured |
| 5. **Native passthrough** | Nobody has described the command yet, so the device's own protocol is used directly. | No, and only a person may use it |

Each step down is less portable. That nudges common needs up into the standard over time.

---

## 10. The principles

Every rule in every part of HEART comes from one of these seven principles. When a rule is unclear, these decide.

| # | Principle | What it means in practice |
|---|---|---|
| 1 | **Awareness lives inside.** | The HEART is part of the product. Intelligence can be remote, but knowing and caring happen locally. |
| 2 | **One language for everything.** | A washing machine and a web app answer the same questions in the same format. |
| 3 | **Works without AI or internet.** | Noticing, explaining, alerting and stopping never depend on an AI model or a network. |
| 4 | **Models suggest, systems decide.** | Nothing an AI says is ever carried out directly. It passes the same checks as any other request. |
| 5 | **Private unless allowed.** | Unclassified data is treated as private. Unapproved actions do not run. Every transfer of private data leaves a receipt. |
| 6 | **The product and people come first.** | The HEART stays out of safety functions and control loops. If it fails, the product carries on normally. |
| 7 | **Build on what exists.** | HEART reuses well-known standards wherever one fits, and only defines something new where nothing exists. |

---

## 11. HEART and other standards

HEART is not built from scratch. It uses existing standards as building blocks and works beside others.

### 11.1 Standards HEART is built on

You do not need to know these to understand HEART. They matter to engineers, because existing tools for them already work with HEART.

| Standard | What it is | What HEART uses it for |
|---|---|---|
| **HTTP** | The protocol of the web | The main way to reach a HEART |
| **JSON** and **JSON Schema** | A common data format, and a way to describe its shape | Every message, and checking messages are correct |
| **CloudEvents** | A common wrapper for event messages (CNCF) | The outer wrapper of every HEART message |
| **OpenAPI** | A standard description of web APIs | The machine-readable HEART API |
| **OAuth 2.0** | The usual way apps get permission to act for someone | Logins and permissions |
| **MQTT** | A light messaging protocol for devices | Connecting small devices |
| **W3C Trace Context** | A way to follow one request across many systems | Tracing requests |
| **RFC 9457** | A standard format for error messages | HEART error messages |

### 11.2 Standards HEART works beside

These do related jobs. HEART does not replace any of them. A system can support them and HEART together, and its Card can point to them.

| Standard | What it does | How HEART relates |
|---|---|---|
| **OpenTelemetry** | Collects detailed metrics, logs and traces for engineers | HEART's Vitals are a short summary. Detailed data stays in OpenTelemetry. |
| **MCP** (Model Context Protocol) | Lets AI assistants use tools | A HEART's capabilities can be offered as MCP tools, and still pass HEART's approval gate. |
| **A2A** (Agent2Agent) | Lets AI agents hand tasks to each other | An AI agent can carry both an A2A card and a HEART Card. |
| **W3C Web of Things** | Describes what a device offers | HEART adds health, care and privacy on top. |
| **OMA LwM2M** | Manages small connected devices | Uses the same basic actions as HEART (Section 8). |
| **OPC UA** | Connects machines in factories | Planned: HEART's information (Part 3) carried inside OPC UA. |
| **Asset Administration Shell** | The Industry 4.0 standard for digital twins | Planned: HEART's information as one section ("submodel") of a factory digital twin. |
| **Matter** | Connects smart-home devices | Possible future connection type (Part 4). |

### 11.3 Ideas HEART borrows

| Source | Idea borrowed |
|---|---|
| **Autonomic computing** (IBM, 2001 onwards) | The loop *monitor → analyse → plan → act*, sharing what the system knows |
| **OBD-II** (cars) | One standard way to ask any product what is wrong, with shared fault codes |
| **SAE J3016** (driving automation levels) | Six numbered levels, each with an operational domain, which HEART calls an Area (Part 2) |
| **The USB and Bluetooth device classes** | Ready-made profiles for each kind of product (Part 8) |
| **The Wi-Fi and Bluetooth logos** | A test and certification mark buyers can trust (Part 9) |

---

## 12. Where to go next

| If you want to know | Read |
|---|---|
| How much a product does on its own | [Part 2: Autonomy Levels](HEART-Part-2-Autonomy-Levels-1.0.md) |
| How the whole standard is organised | [The HEART Standards Family](HEART-Standards-Family.md) |
| The full details, until the other parts are written | [HEART API Standard](HEART-API-Standard-1.0.md) and [HEART Core Standard](HEART-Core-Standard-1.0.md). Where a drafted part and those documents disagree, the part prevails ([Standards Family](HEART-Standards-Family.md)). |
| How to build one | The guides for an [air conditioner](../guides/AC-Temperature-Controller.md) and a [photo app](../guides/Photo-Editing-Software.md) |

---

## 13. Open items

| Item | Why it matters |
|---|---|
| **Body words in other languages** | Words like Arrhythmia and Pulse need agreed translations, or should stay in English everywhere. |
| **Rename "conformance level" to "Feature Set"** | Needed so the word "level" means only Autonomy Levels. Affects the API Standard, schemas and the paper. |
| **Mappings to OPC UA, the Asset Administration Shell and Matter** | Listed as planned in Section 11.2. Each needs work with the group that owns that standard. |
| **A shared fault-code list** | The OBD-II comparison only holds once Part 3 publishes standard alert codes that everyone uses. |