Die Berechtigungspfade aus Kapitel 7 werden korrigiert, bevor die Work weitergeht.
Der vorgesehene Character kann andocken. Die Structure zeigt den benötigten Service, der Materialpfad ist sichtbar und das Mitglied der Corporation besitzt die für die Verwaltung der Aufgabe benötigten Fähigkeiten. Jede Frage zum Access liefert nun die erwartete Antwort.
Die Aufgabe kann trotzdem nicht beginnen. Der Service ist offline.
Die Structure steht auf demselben Grid wie zuvor. Piloten können andocken, ihre Hangars öffnen und den vertrauten Innenraum sehen. Die Hülle hat den Anschein der Beständigkeit bewahrt, während eine der Funktionen eingestellt wurde, um die herum die Gruppe ihre Work organisiert hat.
Der Failure wirkt nur plötzlich, weil die Abhängigkeit verborgen war. Der Service benötigte ein Service Module, das online bleiben musste. Das Modul benötigte Fuel. Der Fuel benötigte eine Route, eine Reserve, Access zur Fuel Bay und eine Person, die erkennen sollte, wann die Reserve die vorgesehene Work nicht mehr tragen konnte. Erst bei der Aufgabe am Ende dieser Kette liess sich die fehlende Pflege nicht mehr übersehen.
Infrastruktur ist nicht das im Raum stehende Objekt. Sie besteht aus der gepflegten Beziehung zwischen diesem Objekt, seinen Funktionen und den Menschen, die von ihnen abhängen.
Services brauchen Mittel
Service Modules verleihen Upwell Structures ihre Funktionalität.
Die Structure selbst verbraucht nicht allein durch ihre Existenz Fuel. Installierte Service Modules verbrauchen dagegen Fuel, wenn sie online sind. Verschiedene Services können unterschiedliche Anforderungen besitzen, die beim jeweiligen Modul sichtbar sind. Dieses Kapitel benötigt keine allgemeingültige Menge, weil die nützliche Frage vor der Berechnung kommt: Welche Funktion ist online, was hält sie online und welche Work scheitert, wenn sie stoppt?
Diese Unterscheidung verändert die Eröffnungsszene. Die Structure ist nicht verschwunden. Ihre Funktionen zum Andocken und Lagern geben der Gruppe weiterhin einen Ort, an dem sie ankommen kann. Der für die Aufgabe benötigte Service ist nicht verfügbar, weil seine eigene Betriebskette unterbrochen ist.
Beginne mit der Funktion statt mit der Hülle. Benenne den Service, den die Gruppe tatsächlich nutzt. Bestimme das Service Module, das ihn bereitstellt, und ob dieses Modul online ist. Halte den Zustand des Fuel über einen Character fest, der ihn sehen und pflegen kann. Folge der Abhängigkeit dann nach aussen bis zur Work.
Die Kette kann an mehreren Stellen brechen, ohne dieselbe Observation zu erzeugen. Das Modul kann installiert, aber offline sein. Fuel kann in der Structure liegen, während der verantwortliche Character ihn nicht dorthin bringen kann, wo das aktive Modul ihn verwendet. Zur Verwaltung der Structure kann ein Character befugt, aber abwesend sein, wenn sich die Route für den Transport des zusätzlichen Fuel schliesst. Der Nutzer kann Access zum Service besitzen, während der Eigentümer niemanden mit der Pflege des Moduls beauftragt hat.
Die Aussage «Wir besitzen eine Structure» löst keine dieser Bedingungen. Ownership sagt, wo die letztliche Kontrolle liegt, ohne Fuel zu bewegen, einen Service online zu halten oder den verantwortlichen Character verfügbar zu machen.
Das Gegenteil ist ebenso wichtig. Auch wenn ein Service hauptsächlich Work von Gästen trägt, bleibt seine Pflege eine Verpflichtung des Eigentümers. Die Nachfrage der Gäste erzeugt weder automatisch Fuel noch einen Verantwortlichen oder eine Entscheidung über die Wiederherstellung. Bietet eine Gruppe eine Capability an, muss jemand wissen, ob dieses Versprechen beabsichtigt ist und wie lange die gegenwärtigen Mittel es tragen können.
Verfolge Fuel als Capability statt als Inventar. Eine Reserve ausserhalb von Home muss weiterhin eine nutzbare Chain durchqueren. Eine Reserve innerhalb der Structure muss einem Character zur Verfügung stehen, der sie in die Fuel Bay legen und den betreffenden Service verwalten kann. Fuel in der richtigen Bay muss noch immer für die erwarteten aktiven Service Modules ausreichen. Jeder Schritt kann wahr sein, während der nächste Unknown bleibt.
Eine beruhigende Gesamtsumme ohne verbundenen Pfad bringt der Gruppe deshalb wenig. «Fuel ist vorhanden» kann Material auf dem Weg, in einem unzugänglichen Lager oder eine für einen anderen Zweck bestimmte Reserve beschreiben. Die Aussage «Der befugte Verantwortliche beobachtete vor dieser Work den Fuel, der diesen aktiven Services zur Verfügung steht» gibt der nächsten Entscheidung eine nutzbare Grenze.
Der Verbrauch verändert sich zudem mit den ausgewählten Services. Nimmt ein Eigentümer ein neues Modul online, verändert er die Bedingungen jeder bestehenden Schätzung. Nimmt ein Verantwortlicher eines offline, kann er die verbleibenden Mittel länger reichen lassen und zugleich eine Funktion entfernen, von der noch jemand abhängt. Eine nützliche Aufzeichnung benötigt sowohl die Observation der Mittel als auch die Gruppe von Services, die sie tragen sollten.
Damit wird ein bewusster Entscheid für offline zu einem Teil der Pflege und nicht zu ihrem Gegenteil. Manchmal kann die Gruppe einen Service nicht erhalten oder will seine Work nicht länger unterstützen. Ihn aus der operativen Baseline zu entfernen, ist dann ehrlicher, als Nutzer um eine Capability planen zu lassen, die ohne Verantwortlichen verschwinden wird. Der Entscheid muss diese Nutzer vor ihrer nächsten Verpflichtung erreichen.
Pflege verlangt nicht, dass jeder installierte Service online bleibt. Eine ungenutzte Funktion kann Aufmerksamkeit und Ressourcen verbrauchen, ohne dem gegenwärtigen Zweck zu dienen. Zur Pflege gehört der Entscheid, welche Services Home tragen soll, und das Entfernen aufgegebener Erwartungen aus der Baseline, bevor Nutzer darauf Work aufbauen.
Der Service, der in der Eröffnungsszene offline ist, legt damit zwei Fragen offen. Welches Mittel fehlt jetzt? Weshalb bemerkte niemand, dass die Abhängigkeit ihre Grenze erreichte? Die Wiederherstellung des Moduls kann die erste beantworten. Nur eine zugewiesene Pflegepraxis kann die zweite beantworten.
Bedeutung von Power
Eine Upwell Structure befindet sich in Full Power, wenn mindestens ein Service Module online ist. Ist kein Service Module installiert oder online, befindet sich die Structure in Low Power.
Diese Begriffe beschreiben einen wirklichen Zustand, beantworten aber nicht, ob ein bestimmter Service verfügbar ist. Eine Structure mit einem aktiven Service Module kann sich in Full Power befinden, während das für die Work der Gruppe benötigte Service Module offline bleibt. Full Power als alle Funktionen bereit zu lesen, würde den Fehler wiederholen, der Andocken als Beweis für Service Access behandelte.
Low Power liefert eine andere Observation. Gegenwärtig ist kein Service Module online. Diese Tatsache reicht weiter als eine einzelne fehlende Funktion für eine Aufgabe, erklärt aber noch immer nicht die Ursache. Vielleicht fehlt Fuel. Vielleicht wurden Service Modules bewusst offline genommen. Ein anderer Zustand der Structure kann beteiligt sein. Der sichtbare Zustand begrenzt die Untersuchung, ohne eine vollständige Geschichte zu liefern.
Der Power State wirkt auch über gewöhnliche Work hinaus. Das offizielle System unterscheidet diese Zustände bei Verwundbarkeit und Betrieb einer Structure. Verteidigung, Verstärkung und Reaktion im Kampf liegen ausserhalb dieses Kapitels. Die operative Lektion lautet lediglich, dass Full Power und Low Power keine schmückenden Bezeichnungen sind und ein Wechsel zwischen ihnen in die gemeinsame Baseline gehört.
Ein längeres Ausbleiben des Verbrauchs von Fuel durch Service Modules kann eine Structure von Low Power in Abandoned versetzen. In diesem Zustand stehen bestimmte Fähigkeiten der Structure nicht mehr zur Verfügung. Für eine Pflegepraxis wird die genaue Übergangszeit nicht benötigt. Auf eine Observation von Abandoned zu warten, würde den früheren Pflegefehler zu einem deutlich breiteren Zustand heranwachsen lassen.
Die drei Bezeichnungen sollten getrennt bleiben. Full Power beweist mindestens ein aktives Service Module, nicht jede vorgesehene Funktion. Low Power beweist, dass kein Service Module online ist, nicht den Grund dafür. Abandoned ist ein eigener Zustand, der nach anhaltend fehlendem Verbrauch von Fuel durch Service Modules erreicht wird und mit weiteren verlorenen Fähigkeiten verbunden ist.
Mit diesem Vokabular kann die Gruppe den Failure aus der Eröffnungsszene genau melden. Bleibt eine Structure in Full Power, kann der benötigte Service als bestimmtes Modul oder als bestimmte Abhängigkeit untersucht werden. Eine Observation von Low Power weitet die Untersuchung auf jeden vorgesehenen Service aus. Eine Observation von Abandoned zeigt, dass die Planung gewöhnlicher Work bereits Annahmen über die ursprüngliche Aufgabe hinaus verloren hat.
Power besitzt Bedeutung, wenn der Zustand den Umfang der nächsten Frage verändert. Irreführend wird er, wenn eine Bezeichnung als allgemeines Urteil über die Gesundheit von Home verwendet wird.
Zustand sichtbar machen
Pflege benötigt eine Source, welche den gepflegten Zustand sehen kann.
Der Structure Browser zeigt zugängliche Structures und die angebotenen Services. Diese Ansicht hilft einem Nutzer festzustellen, ob seinem Character die benötigte Capability angeboten wird. Die Bedingungen des Eigentümers hinter diesem Angebot bleiben ausserhalb dieser Ansicht.
Mitglieder der besitzenden Corporation können mit der entsprechenden Befugnis die Ansicht My Structures sehen. Diese Information umfasst den verbleibenden Fuel und den gegenwärtigen Vulnerability State ihrer Structures sowie Informationen zu Profile und Zuweisungen. Die Ansicht des Eigentümers kann damit Observations tragen, die einem Gast nicht zur Verfügung stehen.
Die beiden Perspektiven sollten zusammentreffen, ohne vermischt zu werden. Gäste können melden, dass der Service dem vorgesehenen Character zu einer bestimmten Zeit nicht zur Verfügung steht. Ein befugter Eigentümer kann melden, dass das Modul offline ist, welcher Zustand des Fuel sichtbar ist und welcher Zustand der Structure gilt. Zusammen erklären die Observations mehr als eine von ihnen allein.
Mache aus der breiteren Ansicht des Eigentümers kein dauerhaftes Wissen. Fuel wird verbraucht, solange aktive Service Modules laufen. Ein zu Beginn einer Arbeitsphase gesehener Wert altert, während diese Services arbeiten und Menschen die Structure verändern. Der Timestamp gehört auch dann zur Observation, wenn die Oberfläche eine genaue Zahl anzeigt.
Der Zustand des Service verdient ebenfalls eine eigene Zeile. Ein aktives Modul, der Power State der Structure und die Fähigkeit des Nutzers, auf den Service zuzugreifen, hängen zusammen, bleiben aber getrennt. Einer kann sich verändern, ohne bei allen anderen dasselbe Ergebnis auszulösen. Nur Structure grün festzuhalten, entfernt jene Ebene, welche die nächste Person prüfen muss.
Sichtbarkeit muss zu einer Entscheidungsgrenze führen. Eine Observation des Fuel ist wichtig, wenn sie zeigt, ob der vorgesehene Service durch die Work hindurch und bis zum Handeln der nächsten verantwortlichen Person online bleiben kann. Nicht jeder wechselnde Wert muss für jeden Nutzer veröffentlicht werden. Sichtbar sein muss der Zustand für die Person, welche die Reaktion trägt.
Ist die Ansicht nicht verfügbar, wird der Zustand zu Unknown, statt vorausgesetzt zu werden. Die Abwesenheit des Eigentümers weist vielleicht nicht auf ein Problem mit dem Fuel hin, kann der Gruppe aber die Fähigkeit nehmen, den Zustand zu bestätigen oder zu korrigieren. Das ist ein eigener Failure der Capability.
Die Piloten können nun trennen, was jeder weiss. Der arbeitende Character beobachtet den Service offline. Der befugte Eigentümer bestätigt den Zustand des Moduls und des Fuel. Ihre gemeinsame Darstellung verbindet diese Observations mit der pausierten Aufgabe, ohne zu behaupten, jede Funktion der Structure sei ausgefallen.
Failure wirkt weiter
Ein Failure eines Service endet selten beim Service.
Manufacturing und Research können in Upwell Structures über die entsprechenden Service Modules bereitgestellt werden. Geht das betreffende Service Module offline, können laufende Aufgaben dieser Art pausieren, bis der Service zurückkehrt. Wird das Modul entfernt oder die Structure zerstört, können die betreffenden Aufgaben abgebrochen werden.
Diese mechanischen Ergebnisse wirken über die abhängige Work auf den Betrieb. Eine pausierte Aufgabe verhindert, dass ihre erwartete Ausgabe erscheint. Eine spätere Aufgabe kann auf diese Ausgabe warten. Ein Pilot und ein Schiff können bereits für ihren Transport eingeteilt sein. Die Chain kann für eine Lieferung bestätigt worden sein, deren Material nicht bereit sein wird.
Verfolge den Failure aus der Eröffnungsszene nach aussen. Der Service ist offline, deshalb kann die Aufgabe nicht beginnen. Das Material bleibt im Lager, statt in die Aufgabe einzugehen. Die geplante Abschlusszeit verliert ihre Grundlage. Ein von einem anderen Piloten erwarteter Ersatzgegenstand wird nicht verfügbar sein. Die für seinen Transport vorbereitete Route besitzt keinen gegenwärtigen Zweck mehr.
Kein einzelner Schritt ist eine Krise. Die Exposure entsteht, wenn jeder abhängige Plan die alte Annahme weiterverwendet. Ein Transportpilot, der auf einer Route auf Material wartet, das nicht hergestellt werden kann, verwendet Aufmerksamkeit für einen toten Zweig. Setzt die Gruppe ein weiteres Schiff ein, weil sie mit der Ausgabe rechnet, kann sie denselben Mangel vertiefen.
Die Reaktion sollte sich in der entgegengesetzten Richtung durch die Kette bewegen. Pausiere die Entscheidung über die Aufgabe. Informiere den Verantwortlichen der abhängigen Work. Löse Bewegungen, die keine Ladung oder keinen Zweck mehr besitzen. Entscheide, ob die Wiederherstellung dieses Service der richtige Einsatz von Fuel und Befugnis ist oder ob die Work zu einer bestehenden Alternative wechseln soll.
Access kann den Failure schwerer lesbar machen. Der Service wirkt vielleicht für einen Character wegen des Profile nicht verfügbar und bleibt für einen anderen online. Umgekehrt kann ein vollumfänglicher Access des Nutzers ein Modul, das offline ist, nicht funktionsfähig machen. Beide Pfade benötigen eine Bestätigung, bevor die Ursache zugewiesen wird.
Ein Abbruch besitzt eine stärkere Grenze als eine Pause. Eine pausierte Aufgabe kann fortgesetzt werden, wenn ihr Service zurückkehrt. Die Entfernung des betreffenden Moduls oder die Zerstörung der Structure kann die Work stattdessen abbrechen. Die Pflegeaufzeichnung muss eine behebbare Unterbrechung von einer Entscheidung unterscheiden, welche die Aufgabe beendet oder ersetzt.
Andere Services erzeugen andere äussere Konsequenzen. Ein Katalog liegt ausserhalb dieses Kapitels. Die Methode bleibt dieselbe: Benenne die Funktion und bestimme die Work, die sie voraussetzt. Beschreibe den ersten sichtbaren Failure. Entscheide danach, was stoppen muss, bevor sich die fehlende Ausgabe auf einen weiteren Plan ausbreitet.
Zeit verändert die Grösse der Konsequenz. Ein vor Beginn einer neuen Aufgabe offline entdeckter Service kostet vielleicht nur eine verschobene Entscheidung. Derselbe Failure, der erst gefunden wird, nachdem mehrere Aufgaben und Bewegungen um ihre erwarteten Ausgaben herum organisiert wurden, kann Piloten, Material und Routen festhalten. Frühe Sichtbarkeit verkleinert nicht den mechanischen Zustand; sie bindet weniger Verpflichtungen daran.
Deshalb gehört der Verantwortliche der Work in die Reaktion. Wer die Structure pflegt, kann melden, ob das Modul zurückkehren kann. Diese Person kann nicht allein entscheiden, ob der alte Zeitplan, das Material und die Bewegung noch sinnvoll sind. Die Wiederherstellung eines Service nach einer langen Unterbrechung stellt die Annahmen vor der Pause nicht wieder her.
Baue diese Annahmen der Reihe nach neu auf. Bestätige den Service. Beurteile die Aufgabe und ihre Eingaben erneut. Gib eine neue Erwartung über den Abschluss an die abhängige Work weiter. Verpflichte erst danach die Bewegung erneut. Während der fehlenden Verfügbarkeit des Service kann sich die Chain verändert haben, und der einst für den Transport eingeteilte Pilot kann inzwischen einen anderen Zweck tragen.
Ist die Wiederherstellung ungewiss, muss die Rückfallebene mit derselben Disziplin verglichen werden. Eine andere Structure bietet dem vorgesehenen Character vielleicht den Service, besitzt aber keine bestätigte Route. Die Bewegung des Materials kann mehr Exposure erzeugen als das Warten. Die richtige Entscheidung ergibt sich aus der gesamten Abhängigkeit, nicht aus dem Wunsch, den ursprünglichen Zeitplan unversehrt wirken zu lassen.
Infrastruktur wird verständlich, wenn ihre Konsequenzen vor einem Failure verfolgt werden – nicht erst, nachdem jeder abhängige Pilot bereits gehandelt hat.
Abhängigkeiten zuweisen
Kritische Infrastruktur benötigt einen Verantwortlichen, bevor sie eine Reparatur benötigt.
Beginne beim Service, der gegenwärtige Work trägt. Halte seinen vorgesehenen Zweck, das bereitstellende Service Module und den Verantwortlichen fest, der dessen Betriebszustand und Versorgung mit Fuel sehen kann. Benenne die Person, die handeln soll, sobald der beobachtete Zustand diesen Zweck nicht mehr trägt.
Beobachter und Verantwortlicher können unterschiedliche Characters sein. Ein Nutzer kann bemerken, dass ein Service verschwunden ist. Den Zustand des Fuel und des Moduls kann ein befugter Eigentümer prüfen. Der zusätzliche Betriebsstoff kann wiederum von einem Piloten durch die Chain getragen werden. Die Pflegepraxis gelingt, wenn diese Beiträge bei einer benannten Entscheidung zusammentreffen – nicht, wenn jede Person jede Befugnis erhält.
Gib der Abhängigkeit einen Auslöser. Eine Prüfung kann an den Beginn einer Arbeitsphase, vor eine lange Aufgabe, vor den Aufbruch des einzigen Verantwortlichen oder an eine Veränderung der Route gehören. Die nützliche Häufigkeit ergibt sich aus dem Verbrauch von Fuel, dem Access zu Replacement und der Konsequenz einer Unterbrechung. Kein allgemeingültiger Zeitplan kann diese Bedingungen ersetzen.
Füge die abhängige Work hinzu. Ein Service ohne benannten Nutzer ist vielleicht nicht entscheidend, selbst wenn sein Betrieb teuer ist. Eine bescheidene Funktion kann tragend sein, wenn mehrere offene Verpflichtungen sie voraussetzen. Der Zweck bestimmt, was die Gruppe pflegt.
Füge die Folge eines Failure und die erste Reaktion hinzu. Welche Work pausiert, wenn das Modul offline geht? Wer muss informiert werden? Welche Bewegung kann gelöst werden? Welcher Zustand verlangt die Ausweitung einer Frage zum Service auf eine Prüfung der gesamten Structure? Diese Entscheidungen sollten bestehen, bevor die Oberfläche den Failure zeigt.
Benenne zuletzt den Pfad für Replacement. Die Alternative kann ein anderer verfügbarer Service, eine verschobene Aufgabe, eine kleinere Verpflichtung oder eine Route zur Wiederherstellung der Betriebsmittel sein. Eine Rückfallebene ist nur glaubwürdig, wenn ihr Access, ihre Chain und ihre Materialbedingungen mit derselben Sorgfalt gelesen wurden wie beim primären Pfad.
Diese kurze Darstellung der Abhängigkeit ist kein dauerhaftes Inventar jedes Moduls. Sie folgt dem aktiven Zweck. Wird eine Aufgabe geschlossen, kann ihr Service die entscheidende Gruppe verlassen. Beginnt neue Work, kann ein zuvor nebensächlicher Service mit einem Steward, einer Source für die Observation und einer Reaktionsgrenze hinzukommen.
Stell dir die Aufzeichnung zu Beginn der nächsten Arbeitsphase vor. Sie nennt den für die offene Aufgabe benötigten Service und den befugten Character, der sein Modul zuletzt online beobachtet hat. Derselbe Eintrag bezeichnet die für den Fuel verantwortliche Person, die Zeit der Observation des Fuel und den Punkt, vor dem eine weitere Prüfung nötig ist. Er nennt den Verantwortlichen der Aufgabe, die auf ihre Ausgabe wartende Bewegung und die Rückfallebene, falls der Service die Work nicht tragen kann.
Der nächste Pilot kann diese Aufzeichnung lesen, ohne jedes Verwaltungsrecht zu benötigen. Bleibt der Service sichtbar und ist die nächste Prüfung noch nicht fällig, weiss der Pilot, welche datierte Evidenz den Plan trägt. Fehlt der Service, erkennt er die zu pausierende Work und die zu kontaktierende Person. Ist der Verantwortliche nicht verfügbar, tritt eine vorbereitete Rückfallebene an die Stelle einer improvisierten Suche nach Befugnis.
Ein Handover muss Grenzen bewahren. Ein Verantwortlicher, der vor seinem Aufbruch Fuel beobachtete, bestätigt nicht, was nach einer unbestimmten Zeit des Verbrauchs verbleiben wird. Er benennt die aktiven Services, die von der Observation zu tragende Work und den Zeitpunkt, an dem die Verantwortung zur nächsten Person übergeht. Der neue Verantwortliche bestätigt die Annahme, wie ein Steward der Chain einen ungeklärten Zweig annimmt.
Nimmt niemand an, sollte die Infrastruktur im Plan sichtbar degradieren. Verschiebe die neue Aufgabe, verkürze den unterstützten Zeitraum oder entferne den Service aus den versprochenen Capabilities. Unverändert fortzufahren, würde die Abhängigkeit dem Zufall zuweisen und die Nutzer glauben lassen, sie besitze weiterhin einen Verantwortlichen.
Verantwortung umfasst auch ausreichende Befugnis, ohne sie anzuhäufen. Die verantwortliche Person benötigt den für Observation und Handlung nötigen Access, aber nicht jede Fähigkeit der Structure oder Corporation. Ein getrennter Administrator kann die breitere Kontrolle behalten, solange der Reaktionspfad ausdrücklich benannt und innerhalb der vom Service tolerierten Zeit verfügbar ist.
Diese Anordnung übersteht Abwesenheit besser als ein vertrauter Name in einer Notiz. Sie sagt, wer beobachtet, wer handelt, wer über die Work entscheidet und wer das nächste Handover annimmt. Mehrere Positionen kann derselbe Character einnehmen, doch die Funktionen bleiben klar genug getrennt, um beim Aufbruch dieses Character übertragen zu werden.
Das Modul, das offline ist, kann wiederhergestellt werden, ohne den Failure zu verbergen, der seine Abhängigkeiten offengelegt hat. Der Eigentümer bestätigt den Zustand von Fuel und Modul. Der Verantwortliche der Work entscheidet, ob die Aufgabe weiterhin wichtig ist. Eine verantwortliche Person nimmt die nächste Prüfung an, und die Gruppe hält fest, was geschehen soll, wenn der Service während der Work nicht online gehalten werden kann.
Eine Reparatur stellt Funktionalität wieder her. Zuweisung macht ihre Rückkehr tragfähig.
Feldprinzip
Infrastruktur ist eine fortlaufende Verpflichtung, keine einmal platzierte Hülle.
Trenne Structure, Service Module, Fuel, Access des Nutzers und abhängige Work. Lies Full Power, Low Power und Abandoned als begrenzte Zustände statt als allgemeine Urteile. Gib jedem entscheidenden Service einen sichtbaren Zustand, eine verantwortliche Person, einen Auslöser zur Prüfung und eine Alternative für den Fall, dass dieser Zustand versagt.
Die Structure aus der Eröffnungsszene bewegte sich nie. Verändert hat sich die gepflegte Beziehung zwischen ihrem Service und der darauf aufgebauten Work. Indem die Gruppe dieser Beziehung rückwärts folgt, kann sie Capability wiederherstellen, ohne Berechtigung, Power State oder Ownership mit der vollständigen Antwort zu verwechseln.
Part II begann damit, gewöhnliches Home beobachtbar zu machen. Er hielt die Chain ehrlich, trennte Befugnis von Capability und legte die Pflege unter einer vertrauten Structure offen. Home kann nun Work tragen, ohne vorzugeben, diese Unterstützung geschehe von selbst.
Funktion allein ist kein Zweck. Die nächste Frage lautet, was die Gruppe mit dieser Capability tun will und welche neue Exposure beginnt, sobald Aufmerksamkeit, Schiffe, Routen und Material an die Aufgabe gebunden werden.
Part III beginnt mit Work.