Working design proposition — 5 October 2026

The project is now moving from broad technology exploration into a specific system architecture: wrist-worn biosensing + contextual interpretation + AI/app interaction + optional bone-conduction audio support. This is a design direction to prototype and evaluate, not a claim that the system can clinically detect sensory overload.

From research question to design loop

The project asks how shared airport accessibility might respond more effectively to the individual and changing sensory needs of autistic adults travelling independently. The emerging answer is not a device that decides what somebody is feeling. It is a user-led support loop that notices physiological change, checks context, asks the traveller whether support would be useful, and then responds only if they choose it.

The central design principle is:

physiological change + movement/context + airport information → cautious interpretation → transparent prompt → user choice → optional support

The loop deliberately separates sensing, interpretation and response. A change in the body is treated as information worth checking, rather than proof of stress, anxiety or sensory overload.

1. Sensing — what the wearable measures

The wrist-worn sensor provides four main inputs:

• EDA — electrodermal activity: changes in skin conductance associated with sympathetic arousal.
• PPG / pulse: optical pulse measurement used to follow pulse-rate change over time.
• HRV — heart-rate variability: variation in the timing between beats, used here as another indicator of changing autonomic state rather than as a direct emotional label.
• Accelerometry: movement and activity information that helps show whether the person is walking, rushing, standing still or otherwise physically active.

These streams should be considered together rather than treated as four independent “answers”.

The system is looking for meaningful within-person change relative to a personal baseline. This is important because wearable data is affected by individual physiology, movement, posture, context, sensor noise and other confounders.

Design constraint: the wearable does not detect “autistic sensory overload”. It measures physiological and movement signals. The meaning of those signals still has to be interpreted cautiously.

2. Interpretation — change, not diagnosis

The interpretation stage asks a narrower question:

Has something changed enough from this person’s usual pattern that checking in might be useful?

The system can compare current signals with the traveller’s own baseline and look for combined patterns such as:

• rising EDA;
• changing pulse rate;
• altered HRV;
• increased movement;
• sustained change rather than a single spike.

The output of this stage should remain deliberately cautious. It might be represented internally as “meaningful physiological change detected”, not “the user is stressed”.

This keeps the design consistent with the evidence: body signals contain useful information, but they can be changed by physical exertion, cognitive demand, excitement, environmental conditions and ordinary individual variation.

3. Context check — what is happening around the signal?

Before prompting the traveller, the system checks whether the signal makes sense in context.

Useful contextual information could include:

• movement: walking, rushing, standing, sitting;
• airport stage: check-in, security, queue, gate, boarding;
• environment: crowd level, noise, announcements, waiting;
• time and recent history: time of day, previous prompts, previous choices;
• device context: signal quality and whether motion may be distorting the measurement.

This stage is essential because a raised pulse while running to a gate should not be treated the same way as a physiological change while standing still in an unexpectedly crowded security queue.

The system therefore uses sensing as one input within a contextual decision, not as the sole trigger.

4. Prompt — a low-friction check-in

If the combined evidence suggests that checking in could be useful, the system offers a prompt.

The traveller can receive this through:

• the AI via the bone-conduction headphones; and/or
• the companion app.

A prompt should be transparent and non-diagnostic. For example:

“You might be experiencing a bit more sensory input right now. Would you like some support?”

The prompt should not force an intervention. It should simply create an opportunity for the user to decide whether anything is needed.

Bone conduction is being explored because it allows audio support without fully blocking the ears, which may help preserve awareness of announcements and the surrounding airport environment. Whether this is comfortable or desirable for individual autistic users still needs to be tested.

5. User decision — voice or app

The user remains the final interpreter.

They can respond by speaking to the AI through the headphones or by using the app.

Example voice responses:

• “Not now.”
• “Yes — please give me option 1.”
• “Snooze for 30 minutes.”
• “Can you explain what’s happening?”

The app can offer the same choices visually:

• Option 1 — chosen support response;
• Option 2 — an alternative support response;
• More information — explain why the prompt appeared;
• Snooze — delay future prompting;
• Not now — dismiss the prompt.

This is a critical autonomy feature. The system can notice and suggest, but the person chooses whether support happens.

6. Response — support follows the user’s choice

Only after the user accepts support does the system respond.

Possible responses within the current audio/app direction include:

• brief grounding or breathing audio;
• reassurance or simplified information;
• guidance to the next airport step;
• directions towards a quieter route or area where airport information is available;
• explanation of what is happening and why the system prompted;
• reduced or changed prompt frequency if the user asks for less interruption.

The response should remain optional, stoppable and adjustable.

The aim is not to “calm” every autistic traveller in the same way. The system should offer configurable support and allow users to decide which responses are useful to them.

7. Learning and adaptation

The loop closes through the user’s choices.

Over time, the system could learn from:

• prompts that were accepted;
• prompts dismissed as “not now”;
• preferred support options;
• snooze behaviour;
• repeated contexts in which support was or was not useful.

This could allow thresholds, timing and prompt type to become more personal.

However, this creates an important design question around privacy: what needs to be stored in order to personalise the experience, and what can remain local or temporary? Personalisation should not automatically justify retaining detailed physiological histories.

Why this architecture is supported by the recent reading

The loop is a design synthesis across several papers, rather than a system already validated for autistic adults in airports.

Neupane et al. (2024) provides a useful precedent for physiological event → prompt → user interpretation. Their 100-day field study triggered self-report prompts following wearable-detected physiological events rather than assuming the sensor could identify the stressor itself.

Phipps et al. (2024) strengthens the need for personal baseline, context and caution, showing how inter- and intra-person variability, confounders, sensor noise and imperfect labels complicate wearable inference.

Rahman et al. (2026) provides a useful architecture for context-aware prompt timing, including separate opportunity detection and delivery filtering so prompts can be suppressed in unsuitable moments. Its improved model was post-hoc and involved only 18 participants, so it is architectural precedent rather than direct validation for this project.

Heng and Yavari (2026) supports combining physiological information with movement and environmental context in free-living conditions, while also showing how difficult reliable state classification becomes outside controlled environments.

Brandebusemeyer, Georgi and Arnrich (2026) found that wearables captured pronounced physiological changes more reliably than subtle cognitive-load differences, and showed that movement affects signal reliability. This supports designing around uncertainty rather than pretending subtle states can always be cleanly identified.

Em and Teoh (2026) provides a particularly useful methodological warning: wearable signals can reflect responses to context without directly measuring the context or internal state itself, and naive modelling can substantially overstate performance when person-specific information leaks into evaluation.

Together, these papers support the following inference for this design project:

Wearable physiology may be useful for noticing change and improving the timing of a check-in, but the system should use context and personalisation, communicate uncertainty, and return interpretation and control to the user.

What this system is not claiming

• It does not diagnose sensory overload, stress, anxiety or dysregulation.
• It does not assume EDA, pulse, HRV or any other single signal has one fixed meaning.
• It does not automatically intervene because the body changed.
• It does not assume bone-conduction audio is suitable for every autistic traveller.
• It does not replace accessible airport environments, staff, information or services.
• It does not yet demonstrate that sensing is better than a simpler manual support system.

This remains a design research proposition to prototype and test.

What changed at this point in the project

Previous position: sensing, response modality and wearable form were still being compared.

Current working decision: move forward with a prototype architecture built around:

EDA + PPG / pulse + HRV + accelerometry → contextual interpretation → AI/app prompt → user decision → optional bone-conduction audio support

Why the position changed: the recent literature has clarified enough of the sensing limitations and interaction principles to stop treating every possible technology as equally open and begin testing one coherent proposition.

What has not changed: the evidence still does not justify claiming that the system detects overload or that this combination will be effective for autistic airport users.

Prototype questions

The next phase should test the experience and logic of the loop, rather than trying to medically validate the sensors.

1. Does the user understand why the system has prompted them?
2. Is speaking to the AI easier, harder or simply different from using the app?
3. Are Not now, Snooze and manual support easy to access?
4. How many support options can be offered without adding cognitive load?
5. Does bone-conduction audio feel discreet and useful, or does it become another sensory demand?
6. What happens after a false prompt?
7. Can the user trigger the same support manually without waiting for sensing?
8. Does biosensing add enough value to justify its complexity compared with a manual-only pathway?

Next design task: prototype one complete airport scenario through the whole loop — signal change, context check, prompt, user reply, support and override — then compare the sensing-informed version with a manual/user-triggered version.