HEART Command Center#

A switch for AI: give a device its brain on a lease, and take it away at once

Author: Milind K. Patil, Syncaissa Systems Inc. Status: Working draft 1, November 2026. A profile of the API Standard (Section 7.4), built on HEART Hub, in the HEART Standards Family. Version: 1.0 (draft) Public site: https://heartcortex.ai/commandcenter · Code: heart-monitor/ (Apache-2.0) Track: Advanced only (Stop 3B): all of it, if your product uses an AI brain at A3 or above.

In one minute#

A device with a HEART may use an AI model, its brain, to explain problems, plan and propose fixes. A Command Center sits between the device and every brain it uses:

device ──renew lease──────────► Command Center ──► model provider (the keys live here only)
       ◄─signed lease or cut───
       ──request──────────────►
       ◄─signed answer──────────

1. The device asks for a brain lease every minute or two. A lease says which models it may use, for what, and until when, signed by the Command Center.
2. Every answer is signed. The device uses an answer only if the Command Center signed it, for this request, under the current lease.
3. To cut the brain, the Command Center stops renewing. Within one lease (5 minutes by default) the device is brainless, even if every message to it is blocked. A cut can also reach it at once.

The device keeps working without its brain. It still notices problems, raises alerts, runs the Playbooks its owner adopted, and does what people approve. A car, robot or pump keeps its own controller and safety system. The switch cuts the brain, never the machine.

Three rules make it safe:

1. It only lowers risk. Nothing a Command Center sends can make a device act, approve anything, raise autonomy or change a setting.
2. Cutting is easy, restoring is hard. Cutting a whole fleet needs one fewer approval than restoring it, and the global switch needs 3 of 5 named people.
3. Everything is in a public log. Every cut, restore and trip is written to a log anyone can read, with times and reasons, never device data.

Anyone can run their own Command Center: a company, a hospital, a farm or a space agency. heartcortex.ai runs the same open code as everyone else.

1. Words#

2. Joining#

A device joins a Command Center the same way it joins a monitor site: it says hello, and its owner registers it with the claim code (HEART Hub, Sections 2 to 4). At the first hello the device pins the site's Ed25519 key. That key is the Command Center key: it signs every lease, answer and signal, and the device trusts no other. The device writes it in its Card as brain.commandCenter.

On the device's page, the owner then turns on its brain and chooses:

The device must also turn auto mode on itself (PUT /heart/v1/brain/offline, with proof of presence). Both sides must agree.

3. The device's requests#

All are POST, over HTTPS, with the device key as Authorization: Bearer <key> (as for monitor reports).

Rules:

1. Renew early. The device renews when a third of the lease is left, and gives up on a renewal after 10 seconds.
2. A lease is for one system, and the Command Center never sends one for a device whose brain is off or cut. A renewal for a cut device is answered with a brain-off signal, so the device drops its lease at once instead of waiting.
3. After brainless the device sends "brainless": true. If its Card has brain.restoreNeedsOwner, it also sends "restore": true once its owner approved POST /heart/v1/brain/restore. The Command Center then marks the lease "restore": true.
4. Signing an answer. The Command Center signs only after its own checks: the request and answer are under the current lease, or the one it replaced until that one would have ended (API Standard 7.4 rule 5), for a named model and use; within budget and rate; through its injection filters; and the answer's shape and ranges fit the device's Card. The device still checks everything afterwards. The Command Center is a second check, never a replacement.
5. Privacy. What the device sends has passed its Valve: only public and internal data. The Command Center keeps requests and answers only as long as its tripwires need (default 30 days), then only their digests.
6. Only for a model on the device. /countersign and /offline-log serve a device that runs a local model (API Standard 7.4 rules 6 and 10). A device that consults only cloud models, as the reference templates do, never calls them: each of its answers comes signed from /reason.

4. Cutting#

Requiring several key holders to agree follows the M-of-N practice of key ceremonies, such as those for the DNS root keys.

1. A cut takes effect at once at the Command Center. It stops signing answers and renewing leases in that scope. Devices that renew get brain-off. A device that cannot be reached is brainless within one lease, or, in auto mode, within its offline time.
2. Approvals are by people. Each approval is one signed-in person with a code emailed to them. Two approvals of the same request by the same person count once. An approval waits 1 hour, then lapses.
3. Five key holders are named in the Command Center's settings, by account. A self-hosted Command Center names its own.
4. A restore after a global cut needs a written review, shown in the public log, before the key holders can approve it.

5. Tripwires#

The Command Center sees every request and answer, so it MUST cut automatically, at the narrowest scope that covers the problem:

A trip emails the owners, says why, and is written to the public log. A person reviews it before the brain is restored. Restoring after a trip follows Section 4.

6. The public log#

The log is hash-chained and public, after Certificate Transparency (RFC 9162).

GET /commandcenter/log (a page) and GET /cc/v1/log (JSON) list every lease policy change, cut, restore, trip and key holder approval, newest first. Each entry has seq, at, kind, scope, reason, by (owner, operator, key-holders, tripwire) and prev: the SHA-256 of the previous entry. Anyone can check that no entry was changed or removed. Entries never contain device IDs, names or data. A device's entry shows only a salted hash of its ID, which its owner can match.

7. Blessed models#

GET /cc/v1/models lists the models this Command Center offers: id, version, local, sha256 for local models, the uses each is blessed for, and the date and result of its regression checks (Part 3, evolution). A new version is a new model: it is blessed on its own, after it has been watched, and a device uses it only once its owner chooses it.

8. How fast a cut reaches a device#

9. Running your own#

The Command Center is part of heart-monitor/, and is turned on with the COMMAND_CENTER setting. ownMonitorServer/ runs it in-house: requests and answers then never leave the building. Its five key holders, model list, provider keys and tripwire limits are its own.

10. All requests#

11. Threats#

12. Open items#

1. The five key holders of heartcortex.ai are not yet named.
2. Hardware-backed leases. A secure element that holds the pinned key and a monotonic counter would let a device prove it honours leases. This is planned for a later version.
3. Signals through a Gateway. The Gateway can pass POST /heart/v1/brain/signal on to its systems at once. The reference Gateway does not yet do this.