ThoxMesh-Head-C6

ThoxMesh-Head-C6 — v3.0.0 (4-head slot predictor)

int8 LiteRT-Micro head for the Seeed XIAO ESP32-C6. 9,848 bytes — 26× under the 256 KB budget.

No base_model: trained from scratch. There is no upstream checkpoint.

⚠️ Status: three of six model gates FAIL. Read before integrating.

The event head is production-quality and improves on v2. The three action slots are not. If you need triage only — the v2 job — v3's event head is strictly better. Do not ship the ACT path on these weights.

What v3 changes

v2 classified events but could not act: it emitted an argmax over 8 classes with no way to produce ACT <target> <cmd> [arg]. v3 widens the trunk into four heads and assembles the action from enumerated slots:

features(16) → trunk(32,32) → event(8) | target(17) | cmd(9) | arg(17)

A language model was deliberately NOT used: the C6 has ~512 KB SRAM with no working PSRAM path, and the smallest Microprocessor tier is 1.11 MB at INT4.

Grammar adherence is structural — and that number is not a capability claim

Because the line is assembled from enumerated slots rather than decoded, it cannot be malformed. Proven exhaustively offline over 124,848 slot combinations — 0 grammar failures, 0 property failures — validated against grammars/act.gbnf using the microprocessor repo's own validator, so both ends of the RV1103↔C6 link check against one artifact.

grammar_failures: 0 therefore carries no information about correctness. It confirms the assembler and nothing else. A well-formed ACT lamp_1 on naming the wrong lamp is still wrong. The lane's parallel finding on the 8M was the same: constrained decoding gave "valid but not correct".

attr_id_norm earned its place

v3's feature 12 (ZCL attribute id) was added specifically to separate motion from sensor_alert, where v2's error concentrated. It worked:

Why the three action gates fail — a design question, not a tuning gap

Two generator bugs were found and fixed during this build; a third issue is architectural and is not resolved.

Fixed: the first v3 run scored target 0.2323 (chance) because the label was drawn at random — not a function of any input, so unlearnable by construction. arg was nan because no event produced set/dim, leaving the metric with empty support. Both are corrected; the numbers above are from the corrected run.

Unresolved — what does target mean? The remaining error is not capacity. It is that the task is ambiguous:

• If target is the device that reported the event, the C6 already knows it from the radio frame header. Predicting it from features is solving a problem that does not exist, and any accuracy below 1.0 is pure loss.
• If target is a paired actuator (motion on sensor_3 → turn on lamp_1), it is a pairing/policy lookup that the 16-feature vector does not carry. No amount of training fixes a label the inputs cannot determine.

arg at 0.4519 has the same shape: 16 buckets decoded from a single normalised scalar, under int8 input quantisation. It is far above chance (0.0625) but exact bucket match is the wrong metric if adjacent buckets are operationally equivalent — an off-by-one dim level is not a failure the way a wrong device is.

These are questions for the architecture owner, and tuning the numbers to clear a gate without answering them would be measuring the wrong thing.

⚠️ Training data is SYNTHETIC

Grounded in published ZCL cluster ids (0x0006 OnOff, 0x0500 IAS Zone, 0x0406 Occupancy) and attribute ids, plus real dBm ranges — but not captured from hardware.

missed_wakeups: 0 / false_wakeups: 0 again. As in v2, zero in both directions is evidence that the generator makes ignore linearly separable, not that the head is perfect. Per the design doc: if v3 repeats the perfect separation, the generator is the finding, not the model. It did. It is.

What would make this real: a labelled capture from a C6 on a populated mesh.

Contract

16 features (v2's 10 unchanged, in order, plus 6 appended), 8 event classes, 17 target slots (0 = TARGET_NONE), 9 commands (0 = CMD_NONE → NOACT), 17 arg buckets (0 = none). meta.json is the single machine-readable source of truth — generate the firmware header from it, never hand-code the orders.

model_data.cc is generated from the exact .tflite described by meta.json, and meta.json carries its model_sha256. Verify that at build time: it is the mechanical check that makes v1's two-model defect impossible to reintroduce.

Firmware must still clamp arguments regardless of prediction (dim 0–100, set 5–35), and the C6 never executes an action — it emits a line the RV1103 validates against policy and the live roster.

<!-- THOX-STANDARD:BEGIN -->

Files

Use with ThoxOS

This is an INT8 TFLite / LiteRT-Micro classifier, not a language model. Flash it with the firmware toolchain described above:

hf download Thox-ai/ThoxMesh-Head-C6 --local-dir ./ThoxMesh-Head-C6

Use with MeshStack

The head runs on the mesh node itself and emits events/slot predictions to the MeshStack coordinator; it is not served through llama.cpp or Ollama.

Device fit (by file size only)

• thoxmesh_head_c6_int8.tflite (9.85 KB): Tiny (<50 MB): runs on any host; also small enough for constrained edge targets that have a GGUF-capable runtime.

RAM needed ≈ file size + context (KV cache) + runtime overhead. These tiers are derived from file size alone; no throughput, TOPS or battery figures are claimed here.

Licence and attribution

Trained by THOX.ai LLC; Apache-2.0.

Out of scope

• Medical, legal, financial, safety-critical or other high-stakes decisions without human review.
• Unattended control of physical devices or actuators without a confirmation step.
• Any use prohibited by the upstream licence or acceptable-use policy.

Limitations and bias

• Small and quantized models make factual mistakes and can produce confident but wrong output; verify important answers.
• Behaviour and bias reflect the training data, which is mostly English web/instruction text; quality in other languages is lower unless stated above.
• Quantization trades accuracy for size; lower-bit files degrade more.

---

THOX.ai LLC — Your AI. Your Data. Your Rules.™ · thox.ai · Contact: [email protected]

<!-- THOX-STANDARD:END -->