Context-aware Assistance: Providing Knowledge at the Right Moment

What context-aware assistance means

The underlying idea comes from research into context-aware applications. Dey describes context as information that can characterize the situation of relevant entities, and an application as context-aware if it uses such information to provide information or services relevant to the user.^[1] Operational assistance therefore requires more than displaying as much data as possible. What matters is which information is actually needed in a specific work situation.

A context model describes the relevant people, objects, activities, rules, and states. Context-aware assistance uses these relationships to select, limit, and provide support traceably. The context model thus explains the situation; assistance responds to it.

Example: Material use in an ongoing batch

In an illustrative case, a person opens the planned material withdrawal during a production task. The system knows the batch, current process step, operating area, operator's role, and material specified by the work instruction.

When a container is scanned, the system identifies that the material type is generally suitable but that the specific container is on hold. Assistance therefore does not display the entire warehouse history. It briefly shows:

• which container is affected,
• which hold status currently applies,
• since when and based on which review the hold has been in place,
• which released alternatives are available at the site, and
• which review path is provided if no alternative is available.

For this example, the process rule is that a container on hold must not be posted in a transaction. The application must check this rule when posting the transaction; a warning display alone does not enforce it. Assistance explains the reason for the hold and shows a released alternative or the designated clarification path. The decision, material change, and subsequent process should remain traceable in connection with the batch.

The example shows the three layers of assistance: context identifies the specific situation, a rule determines relevance, and the interface provides an understandable response. None of these layers is sufficient on its own.

The right information at the right time

Substantively correct information may be ineffective or disruptive if it appears too early, too late, or without reference to the current action. Brief preparation may be required before a task starts. During execution, limits, sequences, and safety conditions may become relevant. After a result, the system may request a review, justification, or subsequent decision.

Ideally, timing follows the actual process state. For example, when a material is selected, the system checks its release status. When a measurement starts, it shows the valid equipment configuration. If a recorded value exceeds a defined range, the associated review path appears. The notification is thus triggered within the substantive context rather than sent independently of the operation.

If such a notification is produced by a trained model, appropriate timing also depends on the processing time until the result is available.

Good assistance also remains restrained. Repeated notifications without new meaning encourage habituation and can diminish important signals. The system should therefore distinguish mandatory interruption, a notification requiring acknowledgment, and unobtrusive additional information.

When the material changes, the notification must change too

In the material example, the scanned container, its current hold status, the task, and the operator's authority are particularly relevant. For the notification displayed, what matters is that these details apply at the time of the action.

If another container is selected after the one on hold, the old reason for the hold must not remain attached to the new object. Nor may an intervening status change be bypassed because a view is still open. Before posting the transaction, the application needs an appropriate check of the applicable state.

A sensor measurement may require additional relationships: observation, sensor, and the object being examined are separate in the W3C/OGC model.[[2]] Which of these details assistance needs follows from its specific task.

Assistance begins with selection, not display

At any given time, an organization usually has more information available than a person can usefully absorb during a task. Master data, measurement series, batch histories, work instructions, open deviations, approvals, and experience may be substantively relevant. An interface that shows everything at once is nevertheless not automatically helpful.

Context-aware assistance therefore first answers a selection question: Which information is necessary now for this person, this object, and this work step? An employee withdrawing material needs different information from the person releasing a batch at its end. Even the same person may need different support depending on the process phase, authority, and current state.

Selection must not be based merely on personal preferences. In regulated processes, mandatory requirements, warnings, and checkpoints must be retained. Personalization can improve presentation and order, but must not hide a required control.

Assistance must be perceptible and understandable

Technically selecting suitable information is only the first half of assistance. The second half is its presentation. A notification must be presented so that its meaning, urgency, and possible follow-up action are identifiable.

On smart glasses, this presentation also involves gaze direction, posture and the position of the instruction in the field of view.

A red warning panel for every special case does not establish clear priority. Nor is unobtrusive text sufficient if a critical action requires deliberate review beforehand. Design, language, and interaction should therefore fit the risk and task. The person must be able to recognize what was observed, why the notification appears, and which options remain open.

ISO 9241-210 describes requirements and recommendations for human-centered design activities across the lifecycle of interactive systems.^[3] For context-aware assistance, this means in particular that work context and user requirements must be reviewed not only during introduction but also during changes and actual operation.

Incomplete context and uncertainty must remain visible

Context data may be missing, outdated, or contradictory. Equipment may not report a current status. A role has changed but qualification has not yet been confirmed. A measurement is available while its assignment to the batch remains unresolved. In such cases, assistance should not act as if the situation were fully understood.

The system therefore needs defined responses to uncertain context. Depending on its significance, it may request missing information, trigger a review, restrict an action, or merely indicate the uncertainty. It is important that missing evidence is not automatically treated as an unremarkable state.

Derived information should also remain identifiable. A directly measured state, manual input, and model-based forecast have different evidential value. Responsible assessment requires a traceable basis for a notification.

Assistance and work instructions serve different purposes

Digital work instructions structure the mandatory or approved steps of an activity. They specify what must be performed, recorded, or checked, and in which order. Context-aware assistance supplements this guidance with situation-specific information.

For example, a work instruction may call for equipment cleaning. Assistance may show that maintenance is pending for the specifically selected equipment, that a particular cleaning agent is not approved, or that previous use requires an additional check.

Both may appear in the same interface but should remain conceptually separate. The work instruction describes the valid process. Assistance considers the specific situation within that process. A notification must not silently replace or change the approved instruction.

From information to a responsible action option

Some assistance functions provide only information; others prepare several paths of action. For example, a system may show that a material is on hold while also identifying permissible alternatives: select another material, request a release review, or pause the task.

Decision support goes beyond an individual situation-specific notification. It brings together data, models, criteria, and options for a decision. Context-aware assistance can make such support available at the right point, but is not equivalent to the complete decision system.

This distinction is particularly important when recommendations arise from historical data or models. An appropriate display does not yet answer whether the recommendation is substantively sound, has been reviewed for the current scope, or is permissible under applicable regulations.

Assistance must not merely simulate human control

An assistance function can check, filter, remind, and prepare options. This does not mean that the system assumes substantive responsibility. Particularly with incomplete context, contradictory data, or exceptional situations, a person must be able to assess the operation.

Human in the Loop describes effective human involvement in review and decision-making. This requires more than a confirmation field. A person needs sufficient context, understandable alternatives, and a real ability to stop, reject, or request additional information.

Context-aware assistance is intended to improve this decision-making space. It must not narrow it through a seemingly unambiguous recommendation. If the system offers only one button or fails to reveal the reasoning behind a warning, human participation may remain formally present but practically weak.

Three questions for the same material notification

First, the notification must concern the correct container; second, it must explain the applicable hold status understandably; third, it must open a permissible next step. These are different checks: a correctly worded warning attached to the wrong object remains wrong.

Even a correctly assigned notification does not prove that the transaction rule is enforced. Display and transaction checks must align. This alignment must be tested against the actual workflow.

The quality of assistance becomes evident in operations

Whether assistance actually helps cannot be determined from a feature list alone. It must be tested in the actual work context. Relevant questions include:

• Does the notification appear at the right work step?
• Does it refer unambiguously to the affected object?
• Is its urgency understandable?
• Do the origin and currency of the information remain identifiable?
• Can the person respond meaningfully or deviate with justification?
• Are unnecessary repetition and contradictory notifications avoided?

Longo, Nicoletti, and Padovano investigated an industrial assistance solution combining, among other things, augmented reality content and a digital assistant. The authors emphasize both functional and nonfunctional requirements and tested learning effects in field experiments.^[4] The study does not establish the effectiveness of every assistance technology. It does show why design and assessment belong together in the application context.

What context-aware assistance does not accomplish

Context-aware assistance does not guarantee a correct decision. It can only build on the data, rules, and models available and approved for the situation. Incorrect assignments or incomplete states can lead to inappropriate notifications.

It replaces neither qualification nor substantive responsibility. Nor can it model every exception in advance. Operational reality includes novel combinations, disruptions, and conflicting objectives for which a system has no reviewed support path.

For Industry 5.0, what matters here is human-centric support for the actual work situation.[[5]] The output device alone says little about the benefit.

The notification must be usable before the affected action

For material use, hold information is required before the transaction is posted. After a container change, it must reflect the new reference; if status is missing, the person needs a designated clarification path.

Context-aware assistance becomes concrete at such transitions: the right reference, suitable timing, and an understandable response. Whether it succeeds becomes apparent in actual use, including interruptions and state changes.