HEART Signal Tables#

Every signal in a product, declared once, checked by a person

Author: Milind K. Patil, Syncaissa Systems Inc. Status: Working draft 1, November 2026. To become part of Part 8 (Product Fit) of the HEART Standards Family. Version: 1.0 (draft) Schema: schemas/1.0/signal-table.schema.json · Example: examples/signal-table.json Track: Intermediate: all of it, if your product serves many signals (Modbus, CAN, firmware variables).

In one minute#

A product is full of signals: temperatures, speeds, currents, switch positions, counters. A HEART that knows them can notice problems early, explain them, and give an AI model the facts it needs.

A signal table (signals.json) lists every signal the HEART may read, with its unit, range, privacy and whether it may ever be changed. Three rules make it safe:

1. Declared or invisible. A signal not in the table is never served or sent anywhere.
2. Careful by default. Nothing is writable unless a person says so. A safety signal is never writable.
3. A person checks it. A HEART MUST NOT load a table that has not been reviewed.

Nobody has to write the table by hand. The generator drafts it from files engineers already have: a Modbus register map, a CAN database, or the firmware's own variables. A person then checks the draft and seals it.

1. What a signal is#

A table MAY also carry $comment, free text for people such as a licence line. HEART ignores it.

Where signals can come from#

2. The rules#

1. Declared or invisible. A HEART MUST NOT read, serve or send a signal that is not in its table.
2. Reviewed before use. A table is usable only when it has a reviewed entry (who, and when) and no signal is still marked draft.
3. Writable only on purpose. writable defaults to false. Writing a signal passes the approval gate like any action (Part 6), and writing a physical signal counts as a physical action.
4. Safety signals are read-only. A signal marked safety MUST NOT be writable, and the schema rejects one that is. HEART watches safety signals; it never controls them (Part 6, Section 9).
5. Watching never disturbs control. A HEART reads signals at low priority, from copies or shadow registers where possible, never from inside a control loop.
6. Personal signals are private. A signal about a person, such as occupancy, location, voice or camera, MUST be private or never-share.
7. Budgets are fixed. Sampling and history have fixed limits, so watching never fills the device's memory or wears out its flash.

3. From what you have to a sealed table#

register map (CSV) ─┐
CAN database (.dbc) ├──► draft ──► a person checks ──► seal ──► use
firmware header (.h)┘    (all signals marked draft,           (reviewed: who, when)
                          nothing writable)

The generator, heart-templates/tools/heart_signals.py, has four steps:

What the generator does on its own, so the reviewer doesn't have to start from nothing:

• Every signal is a draft, and nothing is writable, even if the register map says it can be written. The reviewer is told, and decides.
• Names that suggest a person (occupancy, location, voice) are made private.
• Names that suggest a safety function (trip, interlock, emergency stop) are marked safety, so they can never be made writable.
• Names that suggest an actuator (motor, valve, setpoint) get a note: "if made writable, also set physical".
• A missing range gets a note, because without one a broken sensor cannot be noticed.

Annotating firmware variables#

The generator reads simple C declarations, with optional hints after // heart:

volatile float room_temp_c;       // heart: unit=Cel range=-40..85 title="Room temperature"
volatile uint16_t fan_rpm;        // heart: unit=rpm range=0..3000
volatile float fan_speed_target;  // heart: unit=% range=0..100 writable

writable here is only a suggestion to the reviewer. It never makes a signal writable by itself.

4. How a signal table fits the rest of HEART#

5. Open items#