HEART Part 9: Testing and Certification#

How to prove a product meets the standard

Author: Milind K. Patil, Syncaissa Systems Inc. Status: Working draft 1, November 2026. Part of the HEART Standards Family. Version: 1.0 (draft) Read first: Part 1: Basics. This part tests the rules in Part 2, Part 3 and the other parts. Track: Basic: "In one minute", Sections 2, 3.1, 5.1, 5.2, 7 and 8. Intermediate adds 6.3, 6.4, 6.7 and 10. Advanced adds 5.3, 6.1, 6.5 and 6.6. Each track page lists its tests.

In one minute#

A claim like "this air conditioner is HEART A4" is worthless if anyone can say it without checking. This part makes every claim checkable.

It works in three steps:

1. Test. Run the official HEART tests on the product.
2. Declare. Publish a short Declaration saying exactly what was claimed, what passed, and what did not.
3. Get checked (optional). Have an independent lab repeat the tests. Later, this can lead to a certification mark, as with the Wi-Fi and Bluetooth logos.

There are three levels of trust:

One rule matters more than any other:

You may claim only what you have passed. If a single required test fails, you may not make that claim. Claim something smaller instead, and say what is missing.

1. Why testing matters#

Imagine two thermostats. Both boxes say "HEART A4". One really fixes known problems by itself. The other only shows a warning light. If buyers cannot tell them apart, the label means nothing, and honest makers lose out.

Successful standards solve this with testing:

• Wi-Fi: the Wi-Fi Alliance tests products before they may use the Wi-Fi CERTIFIED logo.
• Bluetooth: a product must be qualified before it may use the Bluetooth name.
• USB: the USB logos are licensed only for products that pass compliance testing.

HEART follows the same path, starting small:

1. Now: clear tests that anyone can run, and honest self-declarations.
2. Next: independent labs, and events where different makers test their products together.
3. Later: a certification programme with a mark, run by HEART's neutral home (see the Standards Family).

Every rule in every HEART part is written so that it can be tested. This is one of the house rules of the standard: if Part 9 cannot test a rule, the rule must be rewritten.

2. What you can claim#

A claim is a precise statement of what a product does. It has up to six pieces:

The short form of a claim, for a website or a box:

HEART Full · A2 (A4 for connectivity and storage) · hvac · self-tested

The long form is the Declaration (Section 7).

Rules:

1. Every piece claimed MUST be tested. Nothing is assumed.
2. A claim MUST name the part versions it was tested against. A product tested against Part 2 version 1.0 does not automatically meet version 1.1.
3. Every product MUST at least claim a Feature Set and an Autonomy Level of A1 or above. Below that, it is not a HEART.

3. The three levels of trust#

3.1 Self-tested#

The maker runs the official tests and publishes the results.

• Cost: free.
• Good for: early products, open-source projects, software apps, and anyone starting out.
• Wording: the claim MUST end with "self-tested".

Self-testing is honest only if the results are public. A self-tested claim MUST come with a public Declaration (Section 7), including the full test results.

3.2 Verified#

An independent lab repeats the tests and signs the results.

• Independent means the lab is not owned by the maker and is not paid according to the result.
• Wording: "verified by" followed by the lab's name.
• The lab MUST publish, or allow the maker to publish, its signed results.

3.3 Certified#

A lab approved by the HEART certification programme tests the product, and the programme registers it.

• The product appears in a public list of certified products.
• The maker may use the HEART Certified mark.
• The programme may withdraw certification if a product is shown not to meet its claim (Section 11).

The certification programme does not exist yet. It needs a neutral organisation to run it (Section 13). Until then, only self-tested and verified claims are possible. Nobody may use the words "HEART Certified" yet.

4. The HEART test kit#

HEART provides the tools for testing. Everyone uses the same tools, so the same product gets the same result wherever it is tested.

The test suite tests the product from the outside, through the same API any consumer uses. It does not need the product's source code. This is called black-box testing. It means HEART can be tested the same way whether the product is written in Rust, C, Python or anything else.

5. How a test run works#

5.1 Before testing: the test sheet#

The maker fills in a short test sheet. It tells the tester what is being claimed, and how to cause each fault.

5.2 The steps#

5.3 Causing faults safely#

To test Autonomy Levels, the tester must cause real faults. There are three safe ways:

A test mode is powerful, so it is also risky. If it were left on, an attacker could use it to fake faults. Therefore:

• A test mode MUST be off in products as shipped.
• Turning it on MUST need physical access to the device, or the owner's explicit approval with proof of presence (Part 6).
• While it is on, the product's Pulse MUST show it. Every alert it causes MUST be marked as a test.
• A test mode fakes faults only. It MUST NOT weaken any check: not the approval gate, not proof of presence, not the Valve, not token checks, and not certificate checks.

Certificate checks are separate from test mode. A shipped product MUST NOT have any setting, flag or hidden switch that turns TLS certificate checks off (Part 4). A test bench that needs to talk to a product with a self-signed certificate does so by giving the product the bench's own authority in the normal way: by claiming it, or by recording the bench's key as the owner would. A build in which certificate checks can be turned off is a development build. It MUST NOT be shipped, it MUST NOT be tested for a claim, and its Pulse MUST show that it is a development build.

A safety function MUST NOT be disabled to run any HEART test. (Part 6.)

6. The test groups#

Tests are grouped by the part they check. Each test has an ID made of the part number and a short name, such as P2-A1-1. This section is the complete list. The HEART-Rating metrics file (Section 8.1) holds exactly these IDs, with exactly these weights.

Each test has a weight: critical, must, should or may (Section 8.1). Applies to says when a test is run. Where it does not apply, the result is not applicable, with the reason. Auto means the test suite runs it by itself; hands-on means a tester runs it and records the result.

6.1 P2: Autonomy Levels#

These are the tests listed in Part 2, Section 9, run with the fault set for the product's profile. A test for level A*n* applies when the product claims A*n* or higher, in the areas where it claims it.

Part 2's test ALL-2 (the product survives the HEART being killed) is run once, as P6-SURVIVE.

The tests are run in every area where a level is claimed. A product claiming "A4 for connectivity and storage" is tested with connectivity faults and storage faults at A4, and with every other fault in the set at its headline level.

6.2 P3: Information Model#

6.3 P4: Connections#

6.4 P5: Privacy#

6.5 P6: Human Control and Safety#

6.6 P7: HEART Core#

Run only if a Core class is claimed.

6.7 SEC: Security corrections#

These tests check the fixes in Security Advisory HEART-2026-001. Each one rests on a MUST in Part 4, Part 6 or the API Standard.

6.8 P8: Profiles#

Each profile (Part 8) adds its own tests: its standard names, its fault codes, its fault set, and any ceiling on Autonomy Levels. For example, a medical profile that allows at most A3 would test that the product never acts without approval. No profile is published yet, so there are no P8 tests in this version.

7. The Declaration#

The Declaration is the published result of testing. It is short, honest and public. A buyer, a regulator or another maker can read it and know exactly what the product does.

7.1 What it contains#

1. The product: name, version and system ID.
2. The claim, in short form (Section 2).
3. The trust level: self-tested, verified or certified, and by whom.
4. The date, and the version of the test kit used.
5. The results: every test, with pass, fail or not applicable.
6. Known gaps: every SHOULD test that failed, and anything else a buyer should know.
7. The full results file, attached or linked.

7.2 An example#

HEART DECLARATION

Product:       CoolAir AC Controller 0.1.0
System ID:     com.example.cool-air.ac-controller
Claim:         HEART Full · A2 (A4 for connectivity and storage) · hvac · Core-M
Parts:         Part 2 v1.0, Part 3 v1.0, Part 4 v1.0, Part 5 v1.0, Part 6 v1.0, Part 7 v1.0
Trust level:   Self-tested
Date:          2026-11-08
Test kit:      1.0.0

Results:       74 passed, 1 failed (P4-CACHE, a SHOULD test), 27 not applicable
HEART-Rating:  9.9 Excellent (metrics 2026.11.3)
Known gaps:    P4-CACHE: the Card has no ETag (SHOULD)
Full results:  https://coolair.example/heart/declaration-0.1.0.json

7.3 Where it is published#

• The Declaration MUST be published where buyers can find it, such as the product's website.
• The product's Card SHOULD link to it in a declaration box, so any tool can find it from the product itself.
• A machine-readable copy, heart-declaration.json, SHOULD be published next to it, so tools can compare products automatically.

8. The result words#

Every test ends with one of four results.

How results become a claim#

• MUST tests: every one MUST pass. A single failure blocks that piece of the claim.
• SHOULD tests: a failure does not block the claim, but MUST be listed under Known gaps.
• MAY tests: optional. Results are reported if the feature is offered.

If a piece fails, the maker claims less, rather than claiming nothing. For example, a product that fails one A4 test can still claim A3, provided every A3 test passed.

8.1 The HEART-Rating: one number from 0 to 10#

A Declaration lists every test. That is complete, but long. The HEART-Rating sums it up in one number that anyone can understand.

Unsafe is not a band. It is the label of any rating where a critical test failed, and such a rating is always 3.9 or less (the first cap below). A rating of 3.9 or less with no critical failure is Poor, not Unsafe.

How it is calculated. Each test has a weight, based on how important it is:

1. Add up the weights of the tests that passed.
2. Divide by the weights of all tests that were run (passed or failed). Tests that do not apply are left out.
3. Multiply by 10. That is the score.
4. Then apply three caps. The rating can never be higher than:
   • 3.9 if any critical test failed. The label is then Unsafe, whatever the score.
   • 6.9 if any must test failed.
   • 8.9 if any critical or must test was not run. The rating is then marked provisional.
5. Round down to one decimal place.

An example. A product runs 20 tests: 4 critical, 12 must and 4 should. It passes everything except one should test.

Score = 10 × (4×5 + 12×3 + 3×1) ÷ (4×5 + 12×3 + 4×1) = 10 × 59 ÷ 60 = 9.83. No caps apply. HEART-Rating 9.8, Excellent.

If the same product had also failed one critical test, its score would still be around 9, but the cap would make it 3.9, Unsafe. A product cannot be "very good" while it has a critical security hole.

The caps are the most important part. They make sure a high rating can never hide a serious failure: no amount of passed tests makes up for one critical security flaw.

The metrics change, so a rating names its version. The list of tests, their weights and the caps are published together as a versioned metrics file, such as 2026.11.2. The metrics file holds exactly the test IDs and weights listed in Section 6; if the two ever differ, that is a defect in the metrics file. A published metrics version is never changed: a correction is a new version. New tests are added as the standard and its threats change. A rating MUST always be quoted with its metrics version, for example "HEART-Rating 8.4 (metrics 2026.11.2)". A rating from older metrics says nothing about newer tests.

The tool. The HEART-Rating service publishes the latest metrics and the rating client. A tester downloads the client, which fetches the latest metrics, runs the tests against the product from the tester's own network, and prints the rating. The service never contacts the product and stores no results. See heart-rating/README.md in this repository.

Ratings and Declarations. A self-tested Declaration (Section 7) SHOULD include the HEART-Rating and its metrics version. The rating does not replace the Declaration: buyers and regulators may still need to see every result.

9. A real example: the reference implementation#

The HEART reference implementation, heartd 0.1.0, already publishes an honest statement: heart-core-rs/CONFORMANCE.md. It claims Full, and openly lists three gaps where a MUST requirement is not yet met:

Under the rules in this part, heartd 0.1.0 could not yet claim Full or a HEART Core class. The third gap is a Full requirement, and the first two are HEART Core requirements. Its honest claim today would be:

HEART Connected, with the modules it offers · self-tested · Full and Core-M pending three gaps

This is not a failure of the reference implementation. It shows the rules working. The gaps are known, written down and tracked. When they are closed and the tests pass, the claim goes up.

10. When to test again#

A Declaration describes one version of a product. It MUST be redone when:

1. the product's HEART behaviour changes: a new capability, Playbook, AI model or Autonomy Level,
2. the maker wants to claim a newer version of a HEART part,
3. a major version of the product is released, or
4. a test that previously passed is found to fail.

Bug-fix releases that do not change HEART behaviour MAY keep the existing Declaration. The maker SHOULD still run the automatic tests on every release, which is cheap once the test suite exists.

Certified products will also be re-checked on a regular schedule, set by the certification programme.

11. When a claim is wrong#

Sometimes a product will claim more than it does, by mistake or not.

• Anyone may report a claim they believe is wrong, with evidence: which test, and what happened.
• Self-tested and verified claims: the maker SHOULD respond publicly, and either fix the product or lower the claim.
• Certified claims: the certification programme investigates. If the claim is wrong and not fixed in time, certification is withdrawn and the product is removed from the public list.

Lowering a claim is always allowed and never shameful. Hiding a known failure is not allowed.

12. Testing together: plugfests#

A product can pass every test alone and still fail to work with another maker's product. Interoperability is tested by bringing products together.

A plugfest is an event where makers bring their products and test them against each other. The IETF, the Wi-Fi Alliance and the OPC Foundation all run events like this.

HEART plugfests will test, for example:

• Can one maker's dashboard read every other maker's Card, Pulse and alerts?
• Can one maker's Gateway host another maker's devices?
• Do fault codes mean the same thing in practice?

Standards bodies often ask for two independent implementations that work together before a standard is called final. HEART will use the same rule: no part becomes final (1.0) until two independent implementations pass its tests and work together.

13. The certification programme (future)#

This section describes what is planned. None of it exists yet.

14. Changes needed in other files#

15. Open items#