Page locked

This page is currently locked for editing by another user. You have to wait until this user finishes editing or the lock expires.
Currently locked by: 130.235.16.4,216.73.216.78
Lock expires at: 2025-07-05 02:19 (11 min)
This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
=== The topics discussed during the clinic ===

https://hait.cs.lth.se/_media/implementation_methods_for_industry.jpeg

===== Eight topics were suggested and discussed in the workshop (in no particular order): =====

  * Cognitive offload
  * Hybrid cognitive systems
  * Shared workload
  * Emergence
  * Implementation methods for industry
  * Individualised AI
  * Silent failures
  * Trust and transparency

The following paragraphs try to summarise the most important aspects that can be distilled from the notes. Passages, phrases, concepts, or simply words that have been filled through educated guessing by the editor (Elin), are marked in brackets [...]. Terms that are taken directly from the notes are set in //italics//.

Topics or terms that received markers are coded in colour as follows: 

<color #7092be>1 marker</color>

<color #00a2e8>2 markers</color>

<color #22b14c>3 markers</color>

<color #ff7f27>4 markers</color>

<color #ed1c24>5 markers</color>

=== Cognitive offload ===

Aspects mentioned and marked as important in this discussion were //<color #7092be>Team Resource Management</color>// (TRM) as well as the idea of //providing / enhancing <color #7092be>cues</color>// for a //<color #7092be>mental picture</color>//, [to give operators overview], as the aim would be to not loose the //mental picture// of the situation at hand. However, [suggested] //<color #00a2e8>solutions may confuse</color>// [solutions to providing overview, or solutions to directly solving a problem?]. 
Other items mentioned in this discussion were //human-centered decision making//, with one particular area //AI focused action planning//. 
//Dull, dirty and dangerous tasks// link //robots// / machines with operators (example UGV operators), where the issues of generally too //high workload// and handling //other tasks// at the same time come into play.

See also the original chart from the workshop: 

{{:cognitive_offload.jpeg?nolink&400|}}

=== Hybrid cognitive systems and capabilities ===

The main questions discussed here were whether such systems should be seen / promoted as //<color #ff7f27>tools or teammates</color>// and whether a transition between these viewpoints should be seen as a //mode switch or a continuous (gradual) transition//, which could then also be defined in //<color #22b14c>three dimensions (competency, authority, and responsibility)</color>//. 

See also the original chart including two diagrams from the workshop: 

{{:hybrid_cognitive_systems.jpeg?nolink&400|}}

=== Shared workload ===

Regarding the topic of //<color #00a2e8>shared workload</color>//, a taxonomy was suggested, considering two types of workload to be discussed, namely //physical// and //mental / cognitive// workload. On the physical side, temporal aspects of sharing workload and in particular monitoring these efforts were raised. Monitoring of a jointly handled task can be done goal based or behaviour based, and there could be failure checkpoints and early warning points [signals] considered. One further question would be to discuss who is monitoring whom and in how far these roles would be interchangeable. On the mental side, aspects as //information processing// and //associative elements// were shown as sub-categories. Aside the taxonomy, an important aspect discussed was the overall objective of sharing workload, i.e. to allow for human and AI to //complement// each other and to //<color #00a2e8>share information</color>//. It was also mentioned out that system design plays a role, where it might be valuable to look into //systems that can be adjusted "on the move"// [to find the right way of sharing the workload for the task at hand].

See also the original chart from the workshop:

{{:shared_workload.jpeg?nolink&400|}}

=== Individualised AI ===

The discussion here centered around the question whether (and if so, how) AI should be individualised, both regarding its application and the training necessary to apply it, as expressed in the call for //<color #7092be>individualised AI training programs</color>//. Aspects like the //scope of knowledge// and a //shared framework for understanding// [somewhat limited by the cognitive capabilities of AI]. One point mentioned here was //<color #7092be>explainability / transparency</color>//, and in particular the degree to which this should be provided (on //state / action level or to provide deep understanding//) , i.e. the //<color #7092be>boundaries of explainability and transparency</color>// came into play here. This included also the question of recognition of //implicit context//, [that might be different given different individuals being part of the team]. A central question is that of //<color #22b14c>whom or what [an AI / system] should be individualised</color>// for, and an overarching question is that of [whether individualisation should be discussed in terms of] //general or specialised AI//.

See also the original chart from the workshop:

{{:individualized_ai.jpeg?nolink&400|}} 

=== Trust and transparency ===

Two aspects, that would link to the following topic (How to deal with silent failures), are that [the AI] //<color #7092be>must understand why it made a mistake</color>// and to //<color #7092be>explain when disagreeing</color>//. For trust to be established, [the system / human?] //<color #7092be>must be predictable</color>//, which can include //simulation// as a tool. This altogether is, however, not //<color #00a2e8>necessarily inherent to AI based systems, it could also be a "normal" algorithm</color>// that is discussed. Further, the issue of //<color #7092be>liability</color>// is mentioned. Topics for research are suggested as //<color #22b14c>visualising AI decision making (also for different types of users</color>// and //digital twin//.

See also the original chart from the workshop:

{{:trust_and_transparency.jpeg?nolink&400|}}

=== Silent failures ===

//<color #ed1c24>"How to deal with silent failures?"</color>// was the overall question, that was seen as highly relevant. As a silent failure a situation was described, where a system (the AI) functions according to specifications, but misunderstands the human due to ambiguities in what is said, done, or observed. The system response is then clear and "correct", while the system behaviour seems "off" in the eyes of the observer (user / collaborator). Concrete suggestions to work on several possible ways of avoiding such situations were given. Using //probability measures or confidence levels// was one suggestion, entailing a follow-up question of //how to determine these reliably and transparently//. Systems, that would be able to //<color #7092be>confirm from time to time</color> [without being obnoxious]// or give //<color #7092be>better feedback at instruction</color>// were mentioned, as well as //<color #00a2e8>simulation or roll-outs</color>//. 

See also the original chart from the workshop:

{{:silent_failures.jpeg?nolink&400|}}

=== Emergence ===

Topics under this umbrella term were //<color #7092be>definitions [in terms of whether it is possible to find any], e.g. flocking, crowds, etc.</color>// Also relevant was the question whether it is possible to //predict and evaluate emergent behaviour (and whether this should be seen as benefit or risk)//. Further there were sub-topics discussed like //how to leverage emergence// and [how to work with it / research it in] //theory and practice//.

See also the original chart from the workshop here:

{{:emergence.jpeg?nolink&400|}}

=== Implementation methods for the industry ===

Central topics/issues in this area are still to //<color #22b14c>establish use cases and scenarios that are applicable and relevant for the industry</color>//, to //<color #ff7f27>close the gap between academia and industry</color>//, and to //<color #7092be>demonstrate concrete measurable added value [of HAIT] to the industry</color>//. This would include to talk about actual //<color #ff7f27>tools instead of simple models</color>//, and to even consider a //"human readiness level"// [rather than TRL].

See also the original chart from the workshop:

{{:implementation_methods_for_industry.jpeg?nolink&400|}}