Core Concepts

These are the concepts you will meet everywhere in CORE-M. Each builds on the one before it, so reading top to bottom is the fastest way in. Where a concept has a section of its own, follow the link for the full treatment.

Tenant

A tenant is an isolated customer account. Every record in CORE-M — devices, telemetry, rules, proofs — is scoped to a tenant_id, and isolation is enforced at every layer, from the auth service down to the storage keys. One CORE-M deployment serves many tenants without their data ever mixing. See Authentication & Tenancy.

Device

A device is a registered piece of hardware (or software agent) that sends telemetry. The device-registry holds its record — name, status, firmware version, groups, tags, and configuration — and a device authenticates with an API key, a PSK, or an X.509 certificate. See Connecting Devices.

device_id vs hardware_id

These are deliberately separate.

• device_id is CORE-M’s own identifier for a device — the key you use in the API, in telemetry, and in proofs. It is stable across the device’s life in the platform.
• hardware_id is the device’s physical identity (a serial number, MAC, or IMEI) recorded as metadata.

Keeping them distinct means you can replace or re-provision hardware without breaking the historical record tied to a device_id, and you can look a device up by either its platform identity or its physical one. See Device Identity.

Telemetry point and metric

A telemetry point is one reading from one device at one timestamp. It carries the device_id, the tenant_id, a timestamp, and a set of named values — numeric or string. Each named value is a metric (for example temperature or status). A single point can therefore report several metrics measured at the same instant.

Caution

When a point is hashed for anchoring, its timestamp is truncated to whole seconds. Nanoseconds are discarded so that a third-party verifier — who may only have second precision — can reproduce the exact same hash. Keep this in mind whenever you compute a hash to verify against.

See Sending Telemetry.

Anchor batch

Anchoring one point per blockchain transaction would be slow and expensive, so CORE-M groups them. An anchor batch is a collection of telemetry-point hashes accumulated over a short window. The whole batch is committed to the chain in a single transaction, amortizing the cost across every point in it. See Anchoring.

Merkle proof

The hashes in a batch are arranged into a Merkle tree, whose single root hash summarizes the entire batch. Only that 32-byte root goes on-chain. A Merkle proof (or Merkle path) is the short list of sibling hashes that lets anyone recompute the root from a single data point — proving that this exact point was part of that anchored batch, without needing the other points. See Merkle Proofs.

Finality

A broadcast anchoring transaction is not instantly permanent. A proof is treated as confirmed once its transaction reaches 1 block confirmation — there is no separate Final state, no configurable confirmation threshold. Before that first confirmation a point is anchored but still provisional; the chain-anchor service tracks confirmations and handles the rare case of a chain reorg that would invalidate a not-yet-confirmed transaction. See Finality & Reorgs.

Proof lifecycle

Every accepted telemetry point moves through an explicit proof lifecycle, and the platform records its state at each step:

A proof has two states, determined by whether its confirmed_at field is null or set:

1. Anchored — included in a batch whose transaction has been broadcast to the blockchain network; confirmed_at is null.
2. Confirmed — the transaction has been mined into a block (1 confirmation); confirmed_at is set, and the proof is archived in PostgreSQL and can be exported as a portable bundle.

The underlying batch moves through its own states: accumulating, ready, broadcast, confirmed, failed.

This lifecycle is the backbone of the integrity guarantee: a point is only considered fully provable once it is confirmed. See Proof Lifecycle and Verification.