TrustMint domain ownership and data model¶
TrustMint is split by business authority. A service may project another service’s identifier, but it must not become a second writer for that domain. This page is the compact map for integrators deciding where data belongs.
Ownership map¶
Owner service |
Sole authority for |
Important references |
|---|---|---|
ThingMake |
Device models, registrars, factory services, provisioning runs, manufacturing lifecycle |
model ID, registrar ID, thing ID |
ThingHub |
Repositories, scopes, thing placement, cross-account scope grants |
thing ID, repository ID, scope ID |
ThingFeed |
Ingestion adapters, normalized streams, stream schema and health |
adapter ID, stream ID |
ThingIO |
Telemetry records, desired/reported twins, device attributes and attribute audit |
thing ID, scope ID |
ThingLogic |
Processing DAGs, rules (threshold + deadman), rule→sink bindings, alarm lifecycle and transitions |
stream ID, sink ID, pipeline ID, thing/scope ID |
ThingBand |
Data sinks and their pipeline bindings |
sink ID, pipeline ID |
ThingLab |
Virtual thing templates, sensor/software profiles, fleet configurations, emulation runs |
template/profile/fleet/run IDs |
ThingMint |
Certificate authorities, certificate issuance/revocation, licenses and signing |
certificate serial, CA generation, license ID |
Three distinctions are non-negotiable:
A device model is defined by ThingMake, not ThingHub.
A certificate or license is issued by ThingMint, not ThingMake.
Telemetry and twin state belong to ThingIO; ThingHub owns registry placement, not the device message plane.
ThingMake¶
Device model¶
A model is a public manufacturing descriptor. The current console/API shape
contains a product identifier (pid), device class, optional hardware revision,
display metadata, provisioning method, and method-specific configuration. Things
reference the model by ID; ThingHub may project that ID but does not edit the
descriptor.
Registrar and factory service¶
A registrar is the manufacturing authority for enrolled things. A factory service is a non-human integration bound to a registrar, model, role, and endpoint. Its AK/SK credential is revealed once and is not a human identity or workload identity.
Thing and provisioning run¶
A manufacturing thing records serial/manufacturing identity, registrar/model references, lifecycle state, trust status, and audit events. Lifecycle mutations run as idempotent sagas and expose a provisioning-run record so partial work can be inspected without guessing from the final state.
ThingHub¶
Repository¶
A repository is an account-owned placement boundary. It has a stable path and placement filter. A thing can be placed or moved only through ThingHub’s rules; other services consume the placement result.
Scope¶
A scope is an account-owned selection of things. Downstream queries and processing may reference the scope ID, but the scope definition remains in ThingHub.
Access grant¶
An access grant shares one owned scope with a grantee account and a bounded verb
set (telemetry-read, attribute-read, attribute-write, command-send).
Platform overrides use the same conceptual resource but are performed and audited
through DeckLoad.
ThingFeed¶
Adapter¶
An adapter describes a source type and source configuration. Built-in adapters may be read-only; tenant-created adapters can be removable. An adapter emits a normalized stream.
Stream¶
A stream has a normalized schema, flow-health projection, and consumer projection. ThingLogic references the stream as a pipeline source. ThingFeed does not own the pipeline or its destination.
ThingIO¶
Telemetry record¶
Telemetry records are time-series observations with timestamp, thing/account context, optional scope context, and an opaque payload. Query filters include thing, scope, time range, and limit.
Digital twin¶
A twin separates desired and reported state and versions each side. Desired-state writes use optimistic concurrency; a stale expected version must fail rather than overwrite a newer change. Version-history rows identify actor, time, change type, and summary.
Attribute¶
Attributes are bucketed as SERVER, SHARED, or CLIENT. Authorized humans/workloads can write SERVER or SHARED values. CLIENT values are device-reported. Attribute audit records old/new value, version, actor, source, and time.
ThingLogic and ThingBand¶
A ThingLogic pipeline is a DAG with source/processing/sink nodes and edges. It references a real ThingFeed stream and an active ThingBand sink, compiles to runtime rules, and moves through draft/validated/deployed/stopped states.
ThingLogic has one model: a rule matches, and its match is routed to the
ThingBand sinks it is bound to. A rule carries its kind, its match predicate,
and a pipeline_id sink-routing key (equal to the rule ID for a hand-authored
rule, or the owning pipeline for a compiled one). Two kinds exist: a threshold
rule (metric, operator, threshold, target scope, severity, cooldown, auto-clear,
optional window) and a deadman rule (fires when no telemetry arrives in a scope
for stale_after_seconds, clears when it resumes). There is no separate “alarm”
mechanism: an alarm is a rule bound to the alarm-lifecycle sink, and only such a
rule gets an operator lifecycle. A resulting alarm records device, rule, value,
severity, state, and acknowledge/shelve/resolve times.
A ThingBand sink records destination type, configuration, input requirements, status, and pipeline bindings. The sink owns delivery configuration; the pipeline owns processing topology.
ThingLab¶
A thing template defines virtual hardware/manufacturing identity.
A sensor profile defines generated telemetry and attributes.
A software profile defines applet/version behavior and generated data.
A fleet configuration composes gateway groups from a template and profiles, with device totals, interval, and duration.
An emulation run is an immutable execution record with status, owner, timing, totals, error/stop reason, and certificate-pool release state.
ThingLab creates simulation resources only. It does not create real registrars, models, or manufacturing identities in place of ThingMake.
Identity, tenancy, and events¶
All account-owned rows carry account/tenant context derived from the authenticated session or workload token; callers do not get to widen it with an arbitrary query parameter. Authorization is delegated to the DotID PDP and fails closed.
Domain events carry stable owner identifiers so consumers can build read models. An event consumer may cache or project data, but writes go back to the owner service. This prevents model, scope, twin, and certificate state from drifting between services.