The Generalization Stack: Why HAR Robustness Is a Pipeline Property

TL;DR for operators

A smartphone activity-recognition model can perform well during development and then degrade when deployed on a different dataset, user population, or sensor position. The natural response is to search for a domain-generalization technique that performs best across these changes.

A 410,400-experiment benchmark suggests that this is the wrong unit of comparison. No individual objective, initialization strategy, or architectural modification wins consistently. Yet compatible combinations can produce materially larger gains: the best aggregate joint configurations improve accuracy by about 2.9 percentage points under cross-dataset shift and 4.9 points under cross-position shift.

The second problem appears after training. Source-domain validation does not always select the checkpoint that generalizes best. With three domain-generalization dimensions active, source-only selection captures about 53% of the available oracle gain in cross-dataset evaluation and only 26% in cross-position evaluation.

For teams building smartphone sensing systems, the decision is therefore not simply which DG method to adopt. It is which complete pipeline—backbone, initialization, architectural modification, objective, and checkpoint-selection rule—survives the deployment shift that actually matters.

A model can work until the phone moves

Suppose an activity-recognition system has been trained on accelerometer and gyroscope data collected from known users under known acquisition conditions. Development accuracy looks acceptable. Deployment then changes one part of the environment: a new dataset is used, the population changes, or the phone moves from one body position to another.

The model has to operate in a domain whose labeled examples were unavailable during development. That is the practical problem addressed by domain generalization.

Napoli and Borin examine this problem through smartphone-based human activity recognition in a controlled benchmark spanning four backbones, multiple initialization strategies, architectural modifications, training objectives, held-out target domains, hyperparameters, and three random seeds.¹ Their full-factorial study contains 410,400 training and evaluation experiments.

The scale matters because it allows a question that smaller method-by-method comparisons struggle to answer: does generalization belong to a particular algorithm, or to the configuration in which that algorithm operates?

The evidence points toward the latter.

Standalone performance is a weak guide to the complete pipeline

The benchmark separates three intervention points: how the representation is initialized, whether the architecture is modified for generalization, and which supervised objective is used.

Taken individually, the gains are modest and conditional.

Among objective-based alternatives to ordinary empirical risk minimization, ERM++ is the most competitive overall, but even it produces a pooled mean gain of roughly zero percentage points across the full hyperparameter space, with 52.9% of runs outperforming plain ERM. Several alternatives have negative pooled mean differences.

Initialization shows a similar pattern. TF-C with source-only leave-one-domain-out pretraining is the most reliable variant evaluated, but its pooled mean improvement is only 0.4 percentage points. Its effect is clearer under cross-position shift, where the mean gain reaches 1.5 points.

Architectural modification produces the strongest standalone result. Dynamic Domain Generalization, or DDG, is the only evaluated architectural modification with positive mean gains in both shift scenarios: about 1.2 points in cross-dataset evaluation and 1.1 in cross-position, with 57.5% of pooled runs beating the unmodified reference.

Those numbers make DDG noteworthy within this benchmark. They do not establish a universal ranking. The effect changes with backbone and shift type, and standalone strength does not reliably predict what happens after components are combined.

Compatibility can matter more than component strength

The joint experiments change the interpretation.

The best aggregate configuration in cross-dataset evaluation reaches a 2.9-point improvement over plain ERM. In cross-position evaluation, the leading configuration gains 4.9 points. Both use DDG, but the surrounding components differ.

More revealingly, five of eight model-and-shift pairs show empirical super-additivity in the component-attribution analysis. In those cases, the full combination gains more than the isolated component results would lead a reader to expect.

This is not evidence that adding more machinery always helps. Some combinations are redundant, and others interfere with one another. Three-component configurations can also saturate or underperform stronger two-component pipelines under source-based selection.

The relevant design variable is therefore compatibility. A component that looks weak alone can participate in a strong pipeline; a component that looks strong alone can lose value when paired with a different backbone or intervention.

For an ML platform team, this changes experimental design. Comparing objectives while freezing the rest of the stack answers only a narrow question. A deployment decision requires testing the interactions among the components that will actually ship together.

Sensor position is a deployment shift worth testing explicitly

The benchmark distinguishes moving across dataset domains from changing sensor position within the RealWorld dataset.

The measured domain separability is higher for position changes. Mean normalized Proxy A-Distance is 0.912 for same-family, different-position pairs, versus 0.781 for different-family pairs that approximately preserve position. Higher values mean that the domains are easier to distinguish from their sensor representations.

This does not prove that every position change will be more damaging than every dataset change. It does show that sensor placement is not a secondary nuisance in this benchmark.

For a smartphone sensing product, placement therefore belongs in deployment validation whenever real users may carry the device differently from the training protocol. Testing only across datasets can miss a shift that is at least as structurally significant in the measured feature space.

The class-level analysis reinforces this point. Successful configurations do not improve all activities uniformly. Their largest gains concentrate around difficult locomotion and stair-related boundaries, including stair ascent, stair descent, and confusions involving walking and running. Aggregate accuracy can therefore conceal where robustness actually improves—and where it does not.

Training can find a good checkpoint that validation discards

The benchmark exposes a second control point after the training recipe itself: checkpoint selection.

Training produces a sequence of model states. In a deployable workflow, the researchers choose among them using source-domain validation only, because target labels are unavailable. For diagnosis, they also identify the checkpoint along the same trajectory that would have maximized target accuracy if target labels had been visible.

That oracle is not a deployable method. It measures unrealized headroom.

At three active DG dimensions, source-selected configurations gain 2.31 percentage points in cross-dataset evaluation, compared with 4.31 points under oracle selection. In cross-position evaluation, the gap is larger: 2.00 points from source selection versus 7.61 points under oracle selection.

Put differently, source-only selection recovers about 53% of the available oracle gain in the first scenario and 26% in the second.

The model may already pass through a substantially better-generalizing state during training. The operational system simply lacks a source-only signal that identifies it.

That separates two engineering questions that are easy to collapse: whether training can produce a robust model, and whether the validation process can recognize one without seeing the future domain.

What teams should validate

The business interpretation is narrower than “use more domain generalization.” For teams deploying smartphone sensing models, the benchmark supports moving experimental effort toward end-to-end configuration testing under realistic held-out shifts. It also gives model-governance teams a reason to track checkpoint-selection quality as a distinct source of deployment loss.

Where the evidence stops

This is a controlled comparative benchmark, not a general law of representation learning.

It covers four model architectures, twelve objective-based alternatives to ERM, three architectural modifications, five initialization strategies, and two shift scenarios. The data are smartphone inertial signals. Larger foundation models, other sensing modalities, generative approaches, test-time adaptation, continual learning, and online adaptation are outside the study.

The oracle analysis also should not be mistaken for a production recipe. It deliberately uses held-out target labels to estimate what the training trajectory contained but source-only validation failed to select.

What the benchmark establishes more strongly is methodological: under these conditions, robustness cannot be assigned cleanly to one DG technique. It emerges from interactions across the learning pipeline, and part of the remaining loss occurs after optimization, when a checkpoint must be chosen without target information.

Validate the recipe, not the ingredient

A team searching for “the best domain-generalization method” may be optimizing a convenient abstraction rather than the system that reaches production.

In this benchmark, objectives, initialization, architecture, backbone choice, deployment shift, and checkpoint selection all change the result. Compatible combinations can create gains that isolated tests do not predict, while source validation can discard better-generalizing checkpoints that training has already produced.

For smartphone HAR, that makes the complete training-and-selection pipeline the more defensible unit of evaluation.

Cognaptus: Automate the Present, Incubate the Future.