HEART Part 2: Autonomy Levels#

How much does a system do on its own?

Author: Milind K. Patil, Syncaissa Systems Inc. Status: Working draft 1, November 2026. Part of the HEART Standards Family. Version: 1.0 (draft) Track: Basic: "In one minute", Sections 2 and 3, A0 to A2 in Section 4, Rules 2, 4 and 6, and Section 8. Intermediate adds Sections 7 and 9. Advanced adds A3 to A5, Rules 1, 3, 5 and 7, and Sections 6 and 10.

In one minute#

Every HEART-Embedded System has an Autonomy Level from A0 to A5. The level says how much the system does on its own when something goes wrong.

Three rules hold at every level:

1. The stop button always works. One command stops all automatic action, at once. (A1 and A2 systems take no automatic action, so they have nothing to stop. Every system at A3 or above MUST have the stop command.)
2. Only a person can raise the level. The system may lower it, never raise it.
3. A higher level never means less safety. Risky actions always need a person to say yes.

A higher level is not "better". It means "more automatic". The right level depends on the product. A web app might be A5. A medical pump might be A2.

1. Why this part exists#

When a company says a product "has AI", nobody knows what that means. Does it only show a warning? Does it change settings by itself? Can it switch things on and off?

Cars had the same problem with "self-driving". In 2014 the engineering body SAE published six levels of driving automation, from 0 to 5. Now anyone can say "Level 2" and be understood by engineers, buyers, journalists and regulators alike.

HEART Autonomy Levels do the same for any system that looks after itself: an air conditioner, a factory machine, a photo app or a web service.

This part is deliberately short, and it can be used on its own. You do not need to know the rest of HEART to understand it.

2. The idea: four jobs#

The four jobs follow the four stages of automation of Parasuraman, Sheridan and Wickens (2000): acquiring information, analysing it, deciding, and acting. Like SAE J3016 for driving, each level then says who does each job.

When something goes wrong, four jobs have to be done:

1. Notice: realise there is a problem.
2. Understand: work out why.
3. Decide: choose what to do about it.
4. Do: carry out the fix.

The level simply says who does each job: a person, or the system.

Read the table from top to bottom. At each level, the system takes over one more job, or more of one job.

The key difference between A4 and A5:

• At A4, a person wrote the fix before the problem happened. The system only follows that instruction. These instructions are called Playbooks: "when X happens, do Y".
• At A5, the system works out a fix for a problem nobody wrote a Playbook for. This usually needs an AI model.

3. One example, all six levels#

The product: a home air conditioner with a HEART. The problem: the compressor keeps switching on and off every few minutes. This is called short cycling. It wastes power, cools badly and wears the compressor out. Here, the real cause is a temperature sensor that reads 3 °C too high.

The same levels in a software app#

The product: a photo editing app. The problem: exports keep failing.

4. The six levels in detail#

Each level includes everything in the levels below it. An A3 system also does everything an A1 and A2 system does.

A0: Unaware#

The system does not watch itself. Most products today are A0.

A0 is not HEART-conforming. It is in the scale so that "before HEART" has a name.

A1: Aware#

The system notices problems and tells someone.

An A1 system MUST:

1. Notice at least when its main job stops working. For an air conditioner, that is cooling. For a photo app, it is opening and saving photos.
2. Change its status to show it: healthy, degraded or failing.
3. Raise an alert (an Arrhythmia) when it happens.
4. Say what it means in plain language: what happened, and what it means for the user.
5. Tell a person through a route the owner chose, such as an app notification, an email or a building dashboard, when it cannot or may not fix the problem itself.
6. Do all of this offline. Points 1 to 4 MUST work without internet access and without any cloud AI model. Point 5 MUST NOT depend on an AI model. If the route the owner chose itself needs a network (an email, a phone notification), the system MUST queue the message, show the alert locally (on the Pulse, a display or a light), and deliver the message when the network returns.

This is "Minimum Tending" in the API Standard (Section 6.1). Where the two differ, this part prevails. A1 is the lowest level a HEART can claim.

A2: Explains#

The system also says why.

For each alert within its areas (Section 6), an A2 system MUST give, in the alert's cause:

1. A likely cause, in plain language (cause.text). For example: "the room sensor reads 3 °C too high".
2. Evidence: the events or readings that led to this conclusion, so a person can check it (evidence, the sequence numbers of the Rhythm events).
3. A confidence: low, medium or high (cause.confidence).

If it does not know the cause, it MUST say so: "Cause unknown". An honest "I don't know" is always allowed. A confident wrong answer is a failure.

A3: Suggests#

The system also proposes a fix, and does it once a person approves.

An A3 system MUST:

1. Offer a specific fix for every fault in its areas that the maker lists as fixable on the test sheet (Part 9, Section 5.1). For other faults it MAY offer a fix, and MUST otherwise say that it has none.
2. Say exactly what the fix will do before anyone approves it: what changes, and what does not.
3. Wait for a person to approve, with proof of presence (Part 6, Section 3). The approver MUST be a person, never a program or an AI, and never the Action's own initiator. A person on whose behalf an AI suggested the fix MAY approve it.
4. Do nothing if the person says no, or does not answer in time. The time limit is the owner's approvalTimeoutSec, 24 hours by default, and each waiting Action shows when it expires (expiresAt).
5. Report the result: did the fix work?

An A3 system runs in mode suggest (Section 7). It takes no action without a person's yes: in suggest, every Action from an AI, another system or a rule asks a person, whatever the allowlist says (Part 6, Section 2.3).

A4: Fixes known problems#

The system fixes problems a person taught it about, then reports.

An A4 system MUST:

1. Follow Playbooks: rules a person adopted in advance, in the form "when this happens, do that".
2. Run a Playbook without asking, but only if its action is on the owner's list of actions allowed to run automatically (the allowlist) for initiator rule, and every value is inside the entry's envelope (Part 6, Section 2.3). An A4 system runs in mode act.
3. Tell a person afterwards: what it noticed, what it did, and whether it worked.
4. Fall back to A3 for any problem no Playbook covers. It suggests a fix and waits. An AI-proposed fix never runs without a person at A4, even if its action is on the allowlist for ai (Part 6, Section 2.3).
5. Never adopt its own Playbooks. It may propose one, but a person must adopt it.

A4 needs no AI model. Playbooks are plain rules. This means A4 keeps working with no internet.

A5: Fixes new problems#

The system also works out fixes for problems nobody planned for.

An A5 system MUST:

1. Work out a fix for a problem no Playbook covers. This usually uses an AI model, local or in the cloud.
2. Carry it out without asking only if it is low-risk: it only reads, or it is a write on the owner's allowlist for initiator ai, with every value inside the entry's envelope. The allowlist for ai is used only while the system's current level (Pulse autonomy.current) is 5. Physical actions are never low-risk.
3. Ask a person first for everything else, exactly as at A3.
4. Tell a person afterwards what it did and why.
5. Learn safely. After a successful fix it SHOULD propose a Playbook, so the next time is an A4 fix. A person must adopt it (Part 6, Section 4.2). This is tested separately, as a SHOULD (test A5-4).
6. Stay within budget. AI costs MUST stay within the owner's limit.
7. Only use tested models. A new AI model MUST pass the system's tests before it is used (API Standard, Section 11).

If its AI model becomes unavailable, an A5 system drops to A4 and says so (Section 7).

5. Rules for every level#

These rules apply at all levels, A1 to A5, where they are relevant (Rule 1 needs something to stop, so it starts at A3). No configuration and no level may weaken them.

Rule 1: The stop button always works#

Every system at A3 or above MUST offer a stop command. In the API it is POST /heart/v1/tending/stop, or PUT /heart/v1/tending/autonomy with a max of 2 or below, which is the same Stop (API Standard 13.4). It stops automatic action, not the machine: a machine is stopped with its own halt capability.

Stop MUST:

• take effect at once,
• need no approval and no internet,
• work even when the system is unwell,
• cancel every Action that has not started yet,
• cancel every running Action whose capability supports cancelling; other running Actions finish,
• undo any running Trial (HEART Core). That undo is the only action allowed after stop, and it still passes the guards.

After stop, the system still notices and explains (A1 and A2 behaviour), but takes no action: new Actions from an AI, another system or a rule are refused with 409 autonomy-stopped (Part 6, Section 6). Only a person can turn automatic action back on.

Rule 2: Only a person raises the level#

• Raising the level, or widening its areas (Section 6), MUST be done by a person with the authority to do so.
• Lowering the level MAY be done by a person, and the system MAY lower its own level at any time. For example, it lowers itself when its AI model is unavailable.
• An AI model MUST NOT raise a level, widen an area, add to an allowlist or adopt a Playbook.

Rule 3: A higher level never means less safety#

The level decides how much the system may do on its own. It never loosens which actions need a person. The approval gate in Part 6 (Section 2.3) applies unchanged at every level:

So even at A5, an AI can never delete your data or start a motor without a person saying yes.

A Playbook (A4) can run a physical action that is on the allowlist for rule, if the person who adopted the Playbook adopted it as physical (Part 6, Section 4.2). That is allowed because a person wrote and adopted the Playbook in advance. The device's own built-in limits still apply (Part 6, Section 9).

Rule 4: Stay out of safety circuits#

At every level, a HEART MUST NOT be part of a safety function, such as an emergency stop, an overheat cut-out or a pressure trip. Those MUST keep working if the HEART crashes, is hacked or is removed. Autonomy Levels are about looking after a system, never about protecting people from it. (Part 6, Section 9.)

Rule 5: Say what you did#

Every action taken at A3, A4 or A5 MUST be recorded in the system's history (Rhythm) with:

• what was done,
• why (the alert, and the Playbook or reasoning behind it),
• who approved it, or which Playbook allowed it,
• the result.

The system MUST be able to explain any past action in plain language.

Rule 6: Be honest about the level#

A system MUST show both the level it promises and the level it can deliver right now (Section 7). It MUST NOT claim a level it has not passed the tests for (Section 9).

Rule 7: At A3 and above, the brain has a switch#

A system that may reach A3 or above with an AI model (a "brain") MUST get that brain only through a Command Center (API Standard 7.4), and MUST consult it only while it holds a brain lease. Whoever runs the Command Center, or the owner, can then cut the brain at once, and it is cut by itself when the lease runs out, even if every message to the system is blocked. Without a brain the system keeps working: it notices, raises alerts, runs the Playbooks a person adopted, and does what people approve. A system with no brain needs no Command Center. Below A3 it is optional.

Cutting the brain lowers the current level: Pulse autonomy.limitedBy becomes brain-cut, as for no-model.

6. Areas: where a level applies#

A level always comes with its areas: where it applies. It is like saying a car can drive itself on motorways: the level means nothing without the "where".

An air conditioner might be A4 for Wi-Fi and storage problems, where the fixes are well known and harmless, but only A2 for everything else.

How to state it#

• The headline level is the level the system reaches everywhere, including for its main job. It is never lower than A1.
• Higher levels MAY be claimed for named areas.

The air conditioner above is written:

HEART A2 · A4 for connectivity and storage

On a box or a website, the headline level alone is fine: HEART A2. The full form should be available in the product details.

Areas#

An area is either one of these standard areas, or the id of a component the system lists (GET /heart/v1/components, or a component named in its signal table), such as room-sensor:

Profiles may set a ceiling#

A product profile (Part 8) MAY set the highest level allowed for a kind of product, or for one area of it. For example, a medical-device profile might allow at most A3, and an industrial profile might allow at most A3 for actuators. A system MUST NOT claim more than its profile allows. Part 8 is not written yet, so no profile sets a ceiling today and this rule has nothing to check until it is.

7. Promised level and current level#

The promised level is what the system is built and tested to do. The current level is what it can actually do right now.

They can differ. For example:

The system MUST report its current level, and the reason when it is below the promised level: at Full in every Pulse, and at Basic and Connected wherever it can (see below). When the cause goes away, it MAY return to the promised level by itself, except after stop. After stop, only a person can turn automatic action back on (Rule 1).

How it is written in HEART messages#

The Card (the system's identity, published once) states the promise:

"autonomy": {
  "level": 2,
  "higher": [
    { "level": 4, "areas": ["connectivity", "storage"] }
  ]
}

The Pulse (the regular "how am I" report) states what is true now. At Full, autonomy MUST be in every Pulse; at Basic and Connected it SHOULD be. Its privacy level is internal, so it is in the view of any logged-in caller with internal clearance, not in the public view:

"autonomy": {
  "max": 2,
  "current": 2,
  "limitedBy": "stopped"
}

max is the ceiling a person set (below). current is a whole number from 0 to 5. limitedBy is one of stopped (a person set max below the promised level, or pressed Stop), no-model, no-network, budget, degraded or brain-cut (the brain lease ended or was cut, Rule 7). It is present exactly when current is lower than the promised level for some area, and left out otherwise. (A profile ceiling limits the promise, never only the current level, so it is not a reason here.)

The ceiling a person sets#

A Full system has one autonomy setting: the ceiling max, from 0 to 5, set with PUT /heart/v1/tending/autonomy (API Standard 13.4). The current level is the lowest of three things: max, the promised level, and what the system can deliver now (for example 4 when the brain is cut or there is no AI model). Basic and Connected systems have no ceiling, because they take no action.

• Lowering max needs no approval. Lowering it to 2 or below is Stop (Rule 1). Stop sets max to 2, or keeps it lower if it already is.
• Raising max is destructive: only a person may do it, with proof of presence or another person's approval (Rule 2).

The system also shows a mode. Nobody sets it: it is the mode that follows from the current level.

The mode is checked before the approval gate (Part 6, Section 2.3). In act, AI-proposed fixes use the allowlist only while autonomy.current is 5; otherwise they always wait for a person, which is what keeps an A4 system at A4.

8. What each level needs from the rest of HEART#

Only A5 needs an AI model. A1 to A4 work with plain rules and no internet. This is on purpose: most of the value of HEART needs no AI at all.

9. How a level is tested#

A level can be claimed only after passing its tests. Part 9 will give the full procedure. Its main tests are:

10. Common questions#

Is A5 the best level? No. A5 means "most automatic", not "best". Pick the level that fits the product and its risks. Many products should stop at A2 or A3 on purpose.

Does a higher level need a bigger AI? No. A1 to A4 need no AI model at all. Only A5 needs one, to handle problems nobody planned for.

Can a product's level go up by itself, for example after a software update? No. An update may make a higher level possible, but a person must turn it on (Rule 2). An update that changes the promised level MUST be shown to the owner.

Can a product be A4 and still ask me about things? Yes. A4 handles the problems its Playbooks cover. For everything else it suggests and asks, like A3. And destructive or physical actions started by an AI or another system always need a person.

What is the difference between A4 and A5 again? At A4, a person wrote the fix in advance. At A5, the system works out the fix itself. In both cases the same safety rules apply.

Is this the same as the SAE driving levels? It borrows the idea of six numbered levels and of an "area" where a level applies (SAE calls it the operational design domain). The content is different: SAE is about driving a car, HEART is about any system looking after itself. HEART levels say nothing about whether a car may drive itself.

What is the difference between Autonomy Levels and Basic / Connected / Full? Autonomy Levels say how much the system does on its own. Basic, Connected and Full say how much of the API it offers. They are separate scales (see the Standards Family).

Does a level prove a product is safe? No. HEART stays out of safety functions (Rule 4). Safety certification, such as IEC 61508 for industrial systems or IEC 62304 for medical software, is separate.

11. Changes needed in other files#

This draft adds things that the current schemas and the API Standard do not yet have.

12. Open items#