Evidence-driven review brief

This review brief summarizes the project's current evidence, unresolved scientific decisions, and immediate execution constraints for advisor and committee discussion. It distinguishes completed experiments, unsupported candidate claims, retained failed outcomes, frozen protocols, blocked hardware work, and proposed contributions.

Research problem and provisional gap

Electronic-nose sensors drift through aging, contamination, and environmental variation. Chronological evaluation tests future-batch degradation directly; random splits can mix future characteristics into training and give an overly favourable deployment estimate.

The literature reviewed so far has not identified a study that unifies chronological e-nose drift evaluation, quantitatively assessed explanation fidelity and stability, and physically measured TinyML deployment cost in one traceable evidence chain. This remains a provisional literature finding rather than a claim of exhaustive novelty.

Research design

FIXED_ORIGIN is the primary prospective protocol; EXPANDING_WINDOW is secondary adaptation analysis; IID_DIAGNOSTIC is diagnostic only. Preprocessing is training-only and four frozen model families underpin the current results. configs/chronological_protocol.yaml

Current evidence

Executed 16Protocol frozen 2Failed 2Blocked 6Running 1

Counts are derived from the declared pipeline registry, not a progress percentage. Negative outcomes remain distinct from unexecuted work.

AreaStatusBoundary
10 — Fidelity evaluationExecutedEXP-XAI-FIDELITY-001; method-specific global, local, sensor-group, family, matched-random, and bootstrap evidence. Local ablation is labelled ABLATION_CONSISTENCY because its perturbation evaluation is partly circular.
11 — Explanation stability evaluationExecutedEXP-XAI-STABILITY-001; global chronological, physical sensor/family, natural-neighbor, matched cross-sectional, relative, and fidelity-linkage evidence. No universal stability score.
12 — Controlled host-side XAI computational costExecutedEXP-XAI-LATENCY-001 measured controlled single-thread workstation cost with raw nanosecond timings and hardware-independent operation counts. Global and local scopes remain separate. Host latency is not an estimate of nRF52840 latency or energy; MCU latency, physical energy, Flash, and SRAM remain NOT_MEASURED/BLOCKED. Stage 13 did not execute.
13 — Embedded architecture and export protocol freezeProtocol frozenGATE-EMBED-EXPORT-001 architecture and numerical-equivalence protocol frozen. This is not an executed model export or performance experiment. Export, quantization, firmware, compiled Flash/SRAM, MCU timing, and energy remain NOT_EXECUTED/NOT_MEASURED.
14 — Standalone FP32 export equivalenceFailedEXP-EMBED-FP32-EQUIV-001 completed with scientific outcome FAILED. C1 and C4 passed score, probability, normalization, golden decision, and boundary decision checks but failed frozen preprocessing criteria. Host-compiled validation only; quantization and MCU work remain unexecuted.
14R — C1 explicit FP32 preprocessing repairFailedEXP-EMBED-C1-PREPROC-REPAIR-001 completed with outcome FAILED. P0 baseline reproduced; P1-P4 all failed unchanged universal preprocessing criteria. C4 remained frozen failed, and quantization, firmware, MCU measurement, and hardware resource claims remain unexecuted.
15 — nRF52840 deploymentHardware blockedEXP-MCU-C1-FP32-PORT-001 is BLOCKED_HARDWARE. No physical Nordic/J-Link/CMSIS-DAP device was detected, so no target was guessed, no toolchain was changed, and no build, flash, physical correctness, linked ROM, or linked static-RAM evidence was produced.

Findings requiring interpretation

Stage 10 fidelity and Stage 11 stability experiments were executed, but their tested candidate claims were unsupported. These retained results may indicate weak explanation behaviour, limitations in the tested definitions, or both; this branch does not alter metrics or rerun experiments. results/xai/stage10_fidelity_summary.csv results/xai/stage11_stability_summary.csv

Stages 14 and 14R retain failed export/preprocessing outcomes; later host equivalence does not establish physical deployment.

Hardware constraint

Prerequisite detection was executed, but no supported nRF52840 board or debug interface was detected. Board identity was not guessed. Physical deployment, Flash/SRAM, MCU latency, and PPK2 energy remain unmeasured.

PLANNED CONNECTION — NOT PHYSICALLY EXECUTED
Planned computer, PPK2, and nRF52840 DK measurement topologyA computer connects to a Power Profiler Kit II over USB. The PPK2 planned VOUT and ground path supplies or measures an nRF52840 development kit through its dedicated measurement header. An optional GPIO trigger marks inference windows. Current traces return to the computer and are exported as files.ComputernRF Connect for DesktopPower Profiler appraw trace + exportsPower Profiler Kit IISMU or ampere modeUSB + digital inputVOUT · GND · triggernRF52840 DKP22 / SB40 pathoptional GPIO triggernormal USB power off*USBVOUT + GNDoptional GPIO markerraw current tracehardware/ppk2_logs/exported trace destination
Planned physical measurement topology. The PPK2 communicates with the Power Profiler application through USB and supplies or measures the nRF52840 DK through its dedicated current-measurement path. An optional GPIO trigger can mark inference and explanation windows. This diagram documents the proposed setup and is not evidence that physical measurement has occurred.* P22/SB40 preparation, measurement mode, and removal of normal DK USB power depend on the verified DK revision and official Nordic procedure; no board modification is instructed or recorded here.
  1. 1Model exportHost artifact available
  2. 2Firmware buildBlocked by hardware
  3. 3Board programmingBlocked by hardware
  4. 4Functional validationBlocked by hardware
  5. 5Repeated inferenceBlocked by hardware
  6. 6PPK2 trace captureBlocked by hardware
  7. 7Trigger-window extractionBlocked by hardware
  8. 8Energy integrationBlocked by hardware
  9. 9Evidence registrationBlocked by hardware
After real traces exist, inference and explanation windows will be integrated separately using E = ∫ V(t)I(t)dt. No post-detection step is shown as completed.
MeasurementUnitCurrent state
Linked ROM / FlashKBNot measured
Static / peak SRAMKBNot measured
MCU inference latencymsNot measured
MCU explanation latencymsNot measured
PPK2 inference energyµJNot measured
PPK2 explanation energyµJNot measured
Linked ROM / FlashKB
Not measured
Static / peak SRAMKB
Not measured
MCU inference latencyms
Not measured
MCU explanation latencyms
Not measured
PPK2 inference energyµJ
Not measured
PPK2 explanation energyµJ
Not measured

Hardware record · TinyML record · results/embedded/stage15_hardware_detection.json

Proposed systems contribution

A reproducible systems-level study connecting chronological drift evaluation, resource-aware explanation analysis, numerical equivalence, and physical deployment cost. It is not necessarily a new learning algorithm, and final scope depends on remaining hardware work.

Discussion priorities

1

Evaluation hierarchy and model scope

Whether FIXED_ORIGIN should remain primary, EXPANDING_WINDOW secondary, IID_DIAGNOSTIC diagnostic only, and whether a compact deep model is scientifically necessary.

2

Interpretation of explanation evidence

Stages 10–11 were executed but their tested candidate claims were unsupported. Guidance is requested on whether this reflects weak explanation behaviour, definitions requiring refinement, or a need for sensitivity analysis.

3

Publication evidence bar

Advice is requested on venue positioning, physical nRF52840/PPK2 requirements, an additional e-nose dataset, and whether a systems contribution is sufficient without a new algorithm.

Evidence and collaboration notices

Evidence last exported 2026-08-14T21:21:27Z from commit d4c1b0b37dd4 on main. Reviewer uploads and comments are collaborative material, not validated scientific evidence, unless separately reviewed and registered through the evidence pipeline.

Shared documents

Approved public documents will appear here after moderator review. Private submissions, storage paths, reviewer emails, and moderation notes are never public.

Discussion

Published discussion will appear here. Reviewer comments represent contributor perspectives, not verified project findings; they become evidence only through the separate evidence pipeline.