Local feature processing

Architecture

A local processor would transform short signal windows into quality-controlled features. Compact temporal models could then be compared with interpretable baselines.

Responsible operation

Record missing data, confidence and failure states. Encrypt retained data and restrict access. Local processing reduces transmission requirements but does not guarantee anonymity or clinical safety.

A proposed separation of responsibilities

The acquisition layer would handle timestamps and device configuration. A processing layer would calculate signal representations and quality indicators. A model layer would produce a research estimate together with uncertainty or an abstention. A reporting layer would preserve the context needed to interpret that estimate.

Failure should be observable

Missing frames, clock drift, stale models and interrupted connectivity should produce explicit states. A system that cannot observe a room must not present that period as evidence of inactivity. Health checks should describe the condition of the software and sensor, rather than claim that a person is safe.

Reproducibility requirements

Record the preprocessing version, model identifier, feature definitions and evaluation partition. Where sharing data is inappropriate, consider publishing configuration examples, synthetic fixtures and evaluation scripts that do not reveal participant information.

Security questions for future prototypes

How are devices provisioned? Which identities can update a model? How are stored features encrypted and deleted? What happens after a device is lost or decommissioned? These questions belong in the design before collecting personal movement data.