Appearance

HLM-Nano — The Ultra-Edge Tier ​

HLM-Nano is Qriton's smallest polynomial-Hopfield variant — designed for hardware where HLM-Micro doesn't fit. Arduino Uno, nRF52, RP2040, STM32 low-power Cortex-M. Kilobyte-scale deployable footprint; sub-milliwatt power envelopes.

Status

v0 validated internally. Weights and deployment artefacts available via Early Access or commercial engagement.

Three tiers of one architecture ​

HLM3HLM-MicroHLM-Nano
Target hardwareGPU cluster / SBCESP32-S3 / Alif / K230Arduino / nRF52 / RP2040 / STM32
Param range30M – 1B1 – 5Msingle-digit KB
Flashmulti-GBMBtens of KB
SRAMmany GBhundreds of KBsingle-digit KB
Active power50 – 400 Whundreds of mWsub-mW
Modalities per checkpointmanyseveral via tag1
On-device audit chainyesyesno — done at gateway

Why a third tier is needed ​

"Edge" spans two fundamentally different hardware classes:

  • Capable MCUs (ESP32-S3 / Alif / K230) — fits HLM-Micro natively
  • Constrained MCUs (8-bit AVR, low-power Cortex-M0+, nRF52, RP2040) — HLM-Micro's parameter count won't fit; smaller architecture needed

The second class is where high-volume deployments live — disposable sensors, always-on wake-word detectors, coin-cell-powered wearables, smart-dust industrial beacons, defence unattended ground sensors.

What HLM-Nano gives up vs HLM-Micro ​

Explicit tradeoffs, no hidden surprises:

  • Multimodal single-checkpoint is gone. Each Nano device does one task on one sensor.
  • On-device audit chain is gone. Hash-chain compute / SRAM too expensive at this envelope — audit happens at the gateway that aggregates Nano detections. Detection stream still carries a tamper-evident chain; individual nodes don't.
  • Basin surgery as a live-deployment mechanism is gone. Field-reflash is the expected update path.
  • Runtime T dial is reduced — fewer iteration budget at this scale.

What HLM-Nano preserves ​

  • Polynomial d=3 multi-basin dynamics — the architectural invariant shared with HLM3 and HLM-Micro
  • Runtime T dial (in reduced form)
  • Basin-routed classification — still addressable, still interpretable
  • Gateway-side audit chain — the aggregated detection stream is fully audit-chained
  • Same training recipe — the same operator + data approach as HLM-Micro, just smaller

Target use cases ​

HLM-Nano is a fixed-function classifier with basin-routed structure. Realistic deployments:

  • Binary or ternary wake-word detection (2–3 classes)
  • Simple anomaly / event detection on a single sensor
  • Small-vocabulary gesture on a single accelerometer
  • Activity-class wearable monitoring (stationary / walking / running)
  • Coarse cardiac-rhythm band classification (wellness, not medical)

Where HLM-Nano beats HLM-Micro ​

  • BOM cost: cents-to-a-euro per device (vs several €/device for Micro)
  • Power: sub-milliwatt (vs hundreds of mW for Micro)
  • Deployability density: hundreds per system vs dozens
  • Battery lifetime: months–years on a coin cell vs days–weeks

Where HLM-Nano loses to HLM-Micro ​

  • Single modality (no fused reasoning across audio + vibration)
  • Coarser class structure (typically 2–4 classes vs 6+)
  • No on-device audit trail
  • Lower accuracy ceiling on hard tasks

When to use which ​

Use HLM-Nano when:

  • Target SRAM is tight (sub-100 KB)
  • Target flash is tight (sub-32 KB)
  • Power budget is sub-10 mW sustained
  • Single-modality classification is sufficient
  • Gateway-side audit is acceptable
  • BOM pressure is below ~€1/device

Use HLM-Micro when:

  • Target is ESP32-S3 class or larger
  • Multimodal fusion on one device is needed
  • On-device audit chain is required
  • Power budget tolerates hundreds of mW
  • BOM tolerates a few euros per device

Commercial engagement ​

HLM-Nano is the right pitch for:

  • High-volume disposable-sensor products
  • Coin-cell-powered wearables (months-to-years battery life)
  • Defense unattended ground sensors (field-replacement cost drives Nano)
  • Industrial smart-beacons / mesh deployments (density wins)

Contact us for pilot partnerships.