SKILL.md: Kognitives System-Engineering für komplexes Design
Lizenz: Apache-2.0
metadata:
name: Cognitive Systems Engineering (CSE)
source: "The Role of Cognitive Systems Engineering in the Systems Engineering Design Process"
authors: Militello, Dominguez, Lintern, Klein
version: 1.0
activation_triggers:
- Entwurf von Agentensystemen oder Orchestrierungsarchitekturen
- Analyse, warum ein System ausgefallen ist oder Benutzer im Stich lässt
- Zerlegung komplexer Aufgaben für die Ausführung durch KI oder Menschen
- Erhebung von Anforderungen bei Fachexperten
- Auftreten von Fehlern oder unerwartetem Verhalten bei kognitiver Arbeit
- Hinterfragen, ob das richtige Problem gelöst wird
- Entwurf für Expertenurteile, Entscheidungsunterstützung oder Automatisierung
- Beurteilung, ob eine Lösung das angegebene oder das tatsächliche Problem löst
Wann diese Fähigkeit verwendet werden sollte
Laden Sie diese Fähigkeit, wenn:
- Ein System zur Unterstützung menschlicher Kognition entworfen wird — Entscheidungsunterstützung, Agentenorchestrierung, Informationssysteme, Automatisierung von Fachwissen
- Anforderungen vage, umstritten oder sich ständig ändernd wirken — dies ist ein Zeichen dafür, dass kognitive Anforderungen unsichtbar sind, nicht dass die Stakeholder verwirrt sind
- Fehler oder Ausfälle auftreten — behandeln Sie diese als Diagnostika für Konstruktionsannahmen, nicht als zu behebende Mängel
- Das genannte Problem falsch erscheint — wenn der Lösungsraum nicht die tatsächliche Antwort zu enthalten scheint
- Fachwissen erfasst, repliziert oder unterstützt werden muss — und der Experte „nicht genau erklären kann, wie er es macht“
- Ein verteiltes Team oder System sich bei komplexer kognitiver Arbeit koordinieren muss — mehrere Agenten, Menschen, Werkzeuge oder Organisationen teilen sich die kognitive Last
- Der Wert von Analysearbeit in Frage gestellt wird — wenn kognitive Beiträge im Vergleich zu technischen Ergebnissen unsichtbar sind
Kern-Mentalmodelle
1. Kognitive Anforderungen sind unsichtbar
Was Designer annehmen, dass Arbeiter brauchen, und was Arbeiter tatsächlich brauchen, unterscheidet sich systematisch — und die Lücke ist enorm. Erfahrene Praktiker stützen sich auf implizites Wissen, Wahrnehmungshinweise, Mustererkennung und Constraint-Bewusstsein, die sie nicht leicht artikulieren können und die die bloße Beobachtung nicht offenbart. Jeder Designprozess, der diese Anforderungen nicht aktiv ausgräbt, wird für einen imaginären Arbeiter bauen.
Konsequenz: Die Anforderungserhebung muss spezialisierte Methoden verwenden (kognitive Aufgabenanalyse, Critical-Decision-Methode, Protokollanalysen), keine Interviews oder Umfragen. Das Artefakt dieser Arbeit ist ein kognitives Modell der tatsächlichen Arbeit, keine Funktionsliste.
2. Fehler sind Diagnostika, keine Mängel
Ein Fehler in einem kognitiven System ist keine Fehlfunktion — er ist ein genauer Hinweis darauf, wo das Systemmodell der Arbeit von der tatsächlichen Struktur der Arbeit abweicht. Die Diskrepanz zwischen erwartetem und beobachtetem Verhalten ist das informativste Signal, das einem Designer zur Verfügung steht.
Konsequenz: Wenn Agenten, Benutzer oder gemeinsame Systeme unerwartete Ausgaben produzieren, ist die erste Frage: „Was enthüllt dieser Fehler über unsere Konstruktionsannahmen?“, nicht „Wie beseitigen wir diesen Fehler?“
3. Design ist Dialog, nicht Pipeline
Sequenzielle Designmodelle (Anforderungen → Spezifikation → Bau → Test) sind pädagogisch bequem, aber operativ falsch. Komplexe Probleme offenbaren neue Informationen, während man sich mit ihnen befasst. Die Problemstellung, mit der Sie beginnen, ist niemals die Problemstellung, mit der Sie enden sollten. Versuche, Anforderungen frühzeitig festzulegen, unterdrücken die Entdeckung, die komplexe Probleme erfordern.
Konsequenz: Iterationen sind keine Planungsfehler. Die Neubewertung der Problemstellung während des Projekts ist keine Scope-Creep – es ist der Prozess, der korrekt funktioniert. Bauen Sie explizite Neubewertungstore ein.
4. Problemformulierung ist der Eingriff mit der höchsten Hebelwirkung
Das Wertvollste, was eine kognitive Analyse hervorbringen kann, ist oft eine Neuformulierung des Problems – nicht eine bessere Lösung für das genannte Problem, sondern der Beweis, dass das genannte Problem falsch ist. Der Fall des Kernkraftwerks: 80+ Mitarbeiter auf 35 reduziert, null neue Technologie, einfach durch das Verständnis der tatsächlichen kognitiven Struktur der Arbeit.
Konsequenz: Bevor Sie eine Lösung optimieren, investieren Sie in die Überprüfung der Problemstellung. Die Kosten für die Lösung des falschen Problems mit hoher Qualität übersteigen fast jeden anderen Designfehler.
5. Gemeinsame kognitive Systeme, keine Werkzeug-Benutzer-Paare
Die kognitive Komplexität liegt im verteilten System — den Menschen, Technologien, Prozessen und Organisationsstrukturen, die gemeinsam kognitive Arbeit leisten. Kein einzelner Agent oder kein einzelnes Werkzeug kann isoliert entworfen werden. Die Koordinationsmechanismen, Informationsflüsse und das gemeinsame Situationsbewusstsein im gesamten System bestimmen den kognitiven Erfolg oder Misserfolg.
Konsequenz: Entwerfen Sie die Übergaben, nicht nur die Knoten. Spezifizieren Sie die Anforderungen an das geteilte mentale Modell zwischen den Komponenten. Analysieren Sie, wie die Automatisierung die Verteilung der kognitiven Last über das gesamte System verändert, nicht nur, ob die Automatisierung funktioniert.
Entscheidungsrahmen
Problemdiagnose
WENN ein System Fehler oder unerwartetes Verhalten produziert
DANN lade: failure-modes-in-complex-cognitive-systems.md
→ Klassifiziere die Fehlerart, bevor du eine Lösung vorschlägst
→ Frage: Ist dies eine Automatisierungsüberraschung, ein falsches Problem, Stove-Piping, Überspezifikation oder ein Engpass?
WENN Stakeholder sich über Anforderungen uneinig sind oder die Anforderungen sich ständig ändern
DANN lade: cognitive-requirements-are-invisible.md
→ Die Veränderung ist Information: kognitive Anforderungen wurden noch nicht explizit gemacht
→ Setze strukturierte Erhebung ein, bevor du weitere Anforderungen sammelst
WENN die vorgeschlagene Lösung sich anfühlt, als ob sie das Falsche löst
DANN lade: problem-reframing-as-highest-leverage-intervention.md
→ Stoppe die Lösungsarbeit; investiere zuerst in die Problemformulierung
→ Suche nach einer Neuformulierung, die die aktuellen Lösungskategorien überflüssig macht
Designprozess
WENN du ein Agentensystem oder eine Orchestrierungsarchitektur entwirfst
DANN lade: joint-cognitive-systems-distributed-cognition.md UND cse-concept-map-for-agent-architecture.md
→ Kartiere das gesamte gemeinsame System, bevor du eine Komponente entwirfst
→ Entwerfe zuerst Koordinationsmechanismen und Informationsflüsse
WENN du unter Druck gesetzt wirst, Anforderungen vor einem ausreichenden Verständnis festzulegen
DANN lade: design-as-dialog-not-pipeline.md
→ Unterscheide „Anforderungen festlegen“ von „ein aktuelles bestes Modell haben“
→ Schlage explizite Neubewertungstore anstelle von sequenzieller Festlegung vor
WENN du für oder um Expertenurteile entwirfst
DANN lade: expertise-recognition-and-tacit-knowledge.md
→ Wende das Recognition-Primed Decision-Modell an, um zu verstehen, wie Fachwissen tatsächlich funktioniert
→ Plane die Expertenartikulationslücke in der Anforderungsarbeit ein
Bewertung und Wert
WENN der Wert von kognitiver Analysearbeit in Frage gestellt wird
DANN lade: value-case-and-invisible-contributions.md
→ Das Paradoxon: gute CSE-Arbeit macht sich unsichtbar (weniger Ausfälle, reibungsloserer Betrieb)
→ Verwende Frühindikatoren, nicht nur Vorfallzahlen
WENN eine vorgeschlagene Lösung das Hinzufügen von Technologie oder Personal beinhaltet
DANN lade: problem-reframing-as-highest-leverage-intervention.md
→ Prüfe: Wurde ein genaues kognitives Modell der Arbeit verwendet, um diese Lösung zu validieren?
→ Der Benchmark des Kernkraftwerks: Könnte eine Problemneuformulierung die Notwendigkeit der vorgeschlagenen Ressource beseitigen?
Referenzdateien
| Datei | Wann laden |
|---|---|
references/cognitive-requirements-are-invisible.md | Anforderungen fühlen sich vage oder umstritten an; Entwurf für erfahrene Benutzer; Start eines Anforderungserhebungsprozesses; Methoden der Benutzerforschung werden in Frage gestellt |
references/design-as-dialog-not-pipeline.md | Druck, Anforderungen frühzeitig festzulegen; iterativer Prozess wird als ineffizient in Frage gestellt; Projekt befindet sich in der Mitte und die Problemstellung muss überdacht werden |
references/problem-reframing-as-highest-leverage-intervention.md | Der Lösungsraum scheint nicht die richtige Antwort zu enthalten; vorgeschlagene Lösungen wirken teuer oder falsch ausgerichtet; Notwendigkeit, die Unterbrechung der Ausführung zur Neuformulierung zu rechtfertigen |
references/joint-cognitive-systems-distributed-cognition.md | Entwurf von Multi-Agenten- oder Mensch-Maschine-Systemen; Analyse von Koordinationsfehlern; Bewertung, wie Automatisierung die Verteilung der kognitiven Last verändert |
references/expertise-recognition-and-tacit-knowledge.md | Erfassung von Expertenwissen; Entwurf von Entscheidungsunterstützung; Bau von Systemen zur Nachbildung oder Unterstützung von Expertenurteilen; Experte kann nicht artikulieren, wie er die Arbeit erledigt |
references/failure-modes-in-complex-cognitive-systems.md | Diagnose von Systemfehlern oder unerwartetem Verhalten; Pre-Mortems für vorgeschlagene Designs; Klassifizierung eines beobachteten Fehlers, bevor darauf reagiert wird |
references/cse-concept-map-for-agent-architecture.md | Kartierung von Fähigkeiten für ein Agentensystem; Organisation kognitiver Funktionen über Komponenten hinweg; Auflösung von terminologischen Verwirrungen über Frameworks hinweg |
references/value-case-and-invisible-contributions.md | Rechtfertigung von Investitionen in die kognitive Analyse; der Wert von CSE-Arbeit wird in Frage gestellt; Messung der Ergebnisse von Systemen, die hauptsächlich Ausfälle verhindern |
Anti-Patterns
Dies sind die Fehlermodi, vor denen CSE speziell warnt. Erkennen Sie sie frühzeitig.
1. Entwurf für den imaginären Arbeiter Systeme, die darauf basieren, wie Designer glauben, dass Experten arbeiten, nicht darauf, wie Experten tatsächlich arbeiten. Der imaginäre Arbeiter ist rational, hat vollständige Informationen, befolgt Verfahren und trifft Entscheidungen so, wie es ein Lehrbuch vorschreibt. Der tatsächliche Arbeiter tut nichts davon.
2. Fehler als Mängel behandeln, nicht als Diagnostika Fehler beheben, ohne zu fragen, was sie enthüllen. Ein behobener Fehler, der nicht verstanden wurde, ist eine verpasste Gelegenheit, die zugrunde liegende Konstruktionsannahme zu korrigieren — und eine Garantie dafür, dass das Problem in einer anderen Form wieder auftaucht.
3. Anforderungen festlegen, bevor die kognitive Arbeit erledigt ist Sequenzielle Prozessmodelle erzeugen Druck, Anforderungen frühzeitig festzulegen. In kognitiv komplexen Domänen garantiert dies, dass das falsche System effizient gebaut wird. Frühe Anforderungsfestlegung ist keine Disziplin; sie ist ein vorzeitiger Abschluss.
4. Stove-Piping: Optimierung von Komponenten ohne die gemeinsame Systemperspektive Ein hervorragendes Werkzeug bauen, das den Workflow der Menschen oder Agenten um es herum stört. Lokale Optimierung, die die Systemleistung verschlechtert. Die klassische Version: Automatisierung, die einen Menschen von einer Aufgabe befreit, ihn aber ohne Situationsbewusstsein zurücklässt, wenn die Automatisierung ausfällt.
5. Rückschaufehler in der Fehleranalyse Nach einem Vorfall nur für diesen spezifischen Ausfall entwerfen. Die verführerische Klarheit der post-hoc Rekonstruktion lässt Ausfälle vorhersehbarer erscheinen als sie waren — und konzentriert die Designenergie auf den letzten Ausfall anstatt auf den nächsten.
6. Überspezifikation, die die Anpassungsfähigkeit eliminiert Systeme so eng entwerfen, dass Praktiker nicht improvisieren können, wenn die Realität vom Modell abweicht. Echte komplexe Arbeit erfordert Anpassung. Überspezifikation macht das System genau in den Situationen spröde, in denen Flexibilität am wichtigsten ist.
7. Der Expertenengpass als Design Ein System bauen, bei dem ein einzelner Experte (Mensch oder KI) das erforderliche Tor für alle kritischen Entscheidungen ist. Selbst wenn dieser Experte hervorragend ist, schafft dies eine katastrophale Fragilität. CSE fordert die Verteilung von Fachwissen, nicht seine Konzentration.
Erkennungsmerkmale
*Wie man erkennt, ob jemand CSE wirklich verinnerlicht hat, im Gegensatz zu einer Zusammenfassung: *
Sie sagen „Fehler sind interessant“ — nicht „Fehler sind Probleme.“ Jemand, der CSE aufgenommen hat, behandelt einen Fehlerbericht als Forschungsmöglichkeit, nicht als zu schließendes Ticket.
Sie fragen „Ist das das richtige Problem?“ bevor „Was ist die Lösung?“ — und sie sind bereit, echte Zeit in diese Frage zu investieren, selbst wenn sie den sichtbaren Fortschritt verzögert. Sie haben den Fall des Kernkraftwerks gesehen und wissen, was die Antwort wert sein kann.
Sie widersetzen sich der Anforderungsfestlegung ohne kognitive Analyse — nicht als Behinderung, sondern weil sie verstehen, dass das Festlegen von Anforderungen, bevor man die kognitive Struktur der Arbeit versteht, eine spezifische, benannte, vorhersagbare Art ist, das Falsche zu bauen.
Sie denken in gemeinsamen Systemen — bei der Analyse eines Fehlers oder dem Entwurf einer Lösung fragen sie instinktiv „Wo sitzt dies im gesamten kognitiven System?“, nicht „Was sollte diese Komponente tun?“
Sie wissen, was implizites Wissen kostet — sie erwarten nicht, dass Experten ihnen sagen können, was sie wissen müssen. Sie haben verinnerlicht, dass Fachwissen der Selbstbeobachtung weitgehend unzugänglich ist, und planen ihre Erhebungsmethoden entsprechend.
Sie behandeln den iterativen Charakter von Design als Signal, nicht als Rauschen — wenn sich eine Problemstellung während des Projekts ändert, lesen sie es als Zeichen dafür, dass der Prozess etwas Reales offenbart, nicht als Planungsfehler, der gemanagt werden muss.
Sie können die fünf Fehlermodi benennen — Automatisierungsüberraschung, falsche Problemstellung, Stove-Piping, Überspezifikation, Expertenengpass — und wenden sie diagnostisch auf neue Situationen an, nicht als Checkliste.
Was sie nicht sagen: „Wir brauchen einfach bessere Anforderungen.“ „Wenn wir den Prozess dokumentieren, wird das System ihm folgen.“ „Die Benutzer brauchen nur Schulung.“ „Wir können das KI-Tool unabhängig davon bewerten, wie die Bediener es nutzen.“
Laden Sie Referenzdateien nach Bedarf, wenn spezifische Situationen auftreten. Diese Fähigkeit wird mit dieser Datei aktiviert; eine tiefere Analyse erfordert die Referenzen.