Zu Beginn der Arbeitsphase wirkt Home unverändert.
Dieselbe Structure steht auf demselben Grid. Die erwarteten Schiffe liegen weiterhin in ihren Hangars, und die gemeinsame Aufzeichnung zeigt noch immer eine Route, welche die frühere Schicht benutzt hat. Der erste Blick liefert keinen Grund zur Beunruhigung.
Dann fallen drei kleine Unterschiede auf.
Bei der Prüfung durch die neue Schicht zeigt der Structure Browser einen Service nicht mehr an, den die geplante Work benötigt. Eine erneute Prüfung im Probe Scanner zeigt eine zuvor erfasste Cosmic Signature nicht. Der betreffende Zweig der Chain wurde zuletzt von einem anderen Piloten während einer früheren Arbeitsphase bestätigt.
Diese Observations beweisen keine Gefahr. Vielleicht ist der Service für diesen Character nicht verfügbar, statt für alle zu fehlen. Die Signature kann sich verändert haben, ohne den Zweck dieses Abends zu berühren. Die übernommene Aufzeichnung der Chain kann weiterhin eine nutzbare Route beschreiben.
Zusammen brechen die Unterschiede jedoch eine wichtige Annahme: Der von der früheren Schicht übernommene Zustand kann nicht mehr ohne Prüfung verwendet werden.
Kapitel 4 legte eine Baseline als gemeinsame Vereinbarung fest. Part II beginnt damit, diese Vereinbarung beobachtbar zu machen. Vertrautheit ist nicht die Frage. Die Bedingungen, welche die nächste Entscheidung tragen, müssen weiterhin dem datierten Zustand entsprechen, auf den sich die Gruppe geeinigt hat.
Gewöhnliches als Evidenz
Gewöhnliche Bedingungen werden leicht übersehen, weil sie keine Reaktion verlangen. Die vertraute Structure ist vorhanden. Die erwartete Routenaufzeichnung besteht. Ein funktionierender Service erscheint dort, wo ihn die Gruppe erwartet. Die nächste Aufgabe besitzt einen Verantwortlichen.
Jede dieser stillen Tatsachen wird erst nützlich, wenn sie als Teil eines Zwecks festgehalten wird.
Eine Baseline ist diese Aufzeichnung. Sie sagt, welche Unterstützung von Home zu einem bestimmten Zeitpunkt, über bestimmte Sources und für eine benannte Art von Work beobachtet wurde. Die Aufzeichnung behauptet nicht, Home sei sicher, dauerhaft oder vollständig.
Diese Unterscheidung ist wichtig, weil Normalität kein allgemeingültiger Zustand ist. Für einen kurzen Flug zum Scanning benötigt ein Pilot vielleicht eine aktuelle Sicht auf das lokale System und die ersten relevanten Connections. Eine Gruppe, die unersetzliche Capability bewegt, kann eine tiefere Routendarstellung, bestätigten Access und eine bekannte Rückfallebene verlangen. Für den ersten Zweck kann Home gewöhnlich und für den zweiten noch nicht bereit sein.
Solche Unterschiede benötigen einen Bezugspunkt, bevor sie Bedeutung erhalten. Die frühere Schicht meldete nicht bloss, alles sei in Ordnung. Sie hinterliess eine begrenzte Darstellung. Ein benannter Pilot hatte die für die Rückkehr verwendete Route beobachtet. Der erforderliche Service war für die Characters sichtbar, welche diese Work ausführten. Entscheidende Scanning Capability war vorhanden, und keine offene Aufgabe hing von einem abwesenden Verantwortlichen ab.
Diese Darstellung kann zutreffen und dennoch alt sein.
Alter macht die frühere Arbeit nicht nachlässig. Es macht die Darstellung historisch. Gegenwärtige Observations lassen sich mit ihr vergleichen, statt die Erinnerung darüber entscheiden zu lassen, ob sich ein Unterschied wichtig anfühlt.
Evidenz über das Gewöhnliche muss bescheiden bleiben. Das Sensor Overlay kann einen Überblick über die mit seiner gewählten Anzeige sichtbaren Orte der Exploration liefern. Der Probe Scanner kann Cosmic Anomalies und Cosmic Signatures anzeigen; Anomalies benötigen keine Probes, um gefunden zu werden, Cosmic Signatures dagegen schon. Diese Oberflächen legen verschiedene beobachtbare Ebenen offen. Keine von ihnen zeigt jedes Ereignis im System, und keine macht aus dem Fehlen in einer Ansicht einen Beweis für Sicherheit.
Dieselbe Zurückhaltung gilt für Infrastruktur. Der Structure Browser zeigt Structures, auf die ein Character zugreifen kann, sowie die dort angebotenen Services. Characters mit der entsprechenden Befugnis innerhalb der Corporation können zusätzliche Informationen über ihre eigenen Structures sehen, darunter den verbleibenden Fuel und den Vulnerability State. Die Ansicht gehört dem beobachtenden Character. Ein Gast und ein Eigentümer können deshalb im selben Moment unterschiedliche, korrekte Observations besitzen.
Eine Baseline bewahrt diese Grenze. Sie hält fest: für diesen Beobachter zu diesem Zeitpunkt sichtbar – nicht: für alle wahr, bis etwas anderes bekannt wird.
Werden gewöhnliche Bedingungen so beschrieben, lässt sich Veränderung erkennen, ohne sie zu dramatisieren. Die Baseline sagt den nächsten Failure nicht voraus. Damit kann sich ein neuer Zustand nicht hinter einem alten Gefühl der Vertrautheit verbergen.
Ebenen von Home
Home besitzt nicht nur einen Zustand.
Sein System, seine Chain, seine Infrastruktur, seine Vermögenswerte und seine Work können jeweils eine andere Antwort tragen. Sie in der Aussage Home ist in Ordnung zusammenzufassen, entfernt genau die Unterschiede, die benötigt werden, sobald sich ein Teil verändert.
Beginne mit der Ebene des Systems. Zu einem festgehaltenen Zeitpunkt beobachtet ein benannter Pilot die für die vorgesehene Work relevanten Cosmic Signatures und Cosmic Anomalies. Die Source umfasst die Oberfläche und die aktive Ansicht, die für die Observation verwendet wurden. Das Ergebnis ist kein vollständiges Inventar des Raums. Es bildet eine datierte Darstellung dessen, was der Pilot sehen konnte und was ausserhalb des gewählten Umfangs blieb.
Die fehlende Signature gehört auf diese Ebene. Eine neue Ansicht im Probe Scanner weicht von der früheren Aufzeichnung ab. Diese Tatsache erklärt noch nicht, ob die frühere Signature abgelaufen, aus der Ansicht gefiltert oder anderweitig falsch erkannt worden ist. Die Baseline hat ihre Aufgabe erfüllt, sobald sie die Abweichung sichtbar macht und die Ursache zu Unknown zurückführt.
Die Ebene der Chain erfasst bekannte Connections und das Alter der Observations, auf denen sie beruhen. Frische darf nicht von der Systemebene übertragen werden. Ein neuer Scan von Home bestätigt nicht automatisch jeden entfernten Zweig erneut. Ebenso kann eine alte Route auf einer Shared Map verbleiben, ohne für eine neue Bewegung geeignet zu bleiben.
Kapitel 6 entwickelt diese Ebene vollständig. Für die Baseline ist das Minimum klar: Welcher Zweig ist für den gegenwärtigen Zweck wichtig, wer hat ihn zuletzt beobachtet, wann geschah das und was wurde seither nicht geprüft?
Die Infrastruktur bildet eine weitere Ebene. Trenne die Structure von ihren Services, dem Access und ihrem sichtbaren Zustand. Die Hülle kann stehen bleiben, während ein Service nicht verfügbar ist. Das Angebot eines Service kann bestehen, während dem eintreffenden Character der benötigte Access fehlt. Informationen über Fuel und den Vulnerability State, die ein befugter Eigentümer sieht, können in der Ansicht eines Gastes fehlen.
Für die Eröffnungsszene lässt sich deshalb eine genaue Observation festhalten: Der benötigte Service war für diesen Character zu diesem Zeitpunkt nicht sichtbar. Die Ursache bleibt offen. Diese Aussage ist nützlicher als die Structure ist defekt, weil sie zeigt, was als Nächstes geprüft werden muss, ohne mehr zu behaupten, als die Ansicht belegt.
Vermögenswerte bilden eine vierte Ebene. Eine vollständige Preisliste ist nicht nötig. Die Baseline benötigt die kleine Gruppe von Capabilities, deren Fehlen die vereinbarte Work verändert. Eine Schiffshülle für das Scanning kann vorhanden, für den vorgesehenen Piloten aber nicht verfügbar sein. Fuel kann bestehen, jedoch über einen Zugriffspfad kontrolliert werden, den die für den Service verantwortliche Person nicht nutzen kann. Ein Replacement kann ausserhalb von Home erfasst sein, während seine Route unbestätigt bleibt.
Halte Capability statt beruhigender Menge fest. Rückfallebene für das Scanning vorhanden und beim letzten Check für den benannten Piloten zugänglich trägt eine Entscheidung. In Home liegen mehrere Schiffe tut das nicht.
Die letzte Ebene ist Work. Aufgaben, Bewegungen und Prüfungen können offen bleiben, nachdem die Person, die sie begonnen hat, gegangen ist. Ihr Zustand in der Baseline sollte den gegenwärtigen Zweck, den Steward und die nächste Entscheidung benennen. Eine nicht abgeschlossene Aufgabe ohne Verantwortlichen kann jede andere Ebene gesünder wirken lassen, als sie ist, weil noch niemand die Capability prüft, welche die Aufgabe benötigen wird.
Diese fünf Ebenen wirken zusammen, sollten aber erst aufeinandertreffen, nachdem jede ehrlich gelesen worden ist. Ein fehlender Service beeinflusst die Work, wenn sie ihn benötigt. Eine alternde Chain erhält eine andere Bedeutung, wenn ein Replacement oder ein Aufbruch von ihr abhängt. Eine neue Signature wird wichtig, sobald sie die Routenfrage verändert, welche die Gruppe beantworten muss.
Die Baseline ist kein einzelnes grünes Zeichen neben Home. Sie bildet eine kurze Sammlung datierter Aussagen, deren Beziehungen untersucht werden können, wenn sich der Plan verändert.
Jede Observation altert
Eine Observation ohne Zeit leiht sich bereits Gewissheit von der Zukunft.
Service verfügbar kann wahr gewesen sein, als der frühere Pilot hinsah. Route nutzbar kann eine einzelne abgeschlossene Bewegung beschreiben. Schiff für das Scanning bereit kann den Zustand wiedergeben, den sein Eigentümer vorbereitet hatte. Werden Source und Alter entfernt, wird jede Aussage zu einem Versprechen, das niemand gegeben hat.
Für jede tragende Observation gelten vier Grenzen: Was wurde gesehen, wer sah es, wann wurde es gesehen und für welchen Zweck galt es als ausreichend?
Die Source ist mehr als der Name eines Characters. Sie umfasst den Weg, über den der Zustand sichtbar wurde. Ein direkter Scan, eine Ansicht im Structure Browser und die Nachricht eines anderen Piloten sind unterschiedliche Sources. Die Nachricht kann zutreffen, bleibt aber Reported, bis die gegenwärtige Entscheidung die von ihr benötigte Bestätigung erhält.
Der Timestamp zeigt der nächsten Person, wann die Zuverlässigkeit zu verfallen begann. Er liefert kein allgemeingültiges Ablaufdatum. Eine lokale Observation kann für eine Entscheidung nützlich bleiben, während ein entfernter Zweig vor einer gewichtigen Bewegung eine weitere Prüfung benötigt. Wie schnell die Information altert, ergibt sich aus dem vorübergehenden System und aus der Konsequenz eines Irrtums.
Der Zweck bestimmt diese Konsequenz. Eine für einen Scout beobachtete Route wurde nicht zwingend für einen Transport geprüft. Ein für seinen Eigentümer bestätigter Service wurde nicht zwingend für einen Gast bestätigt. Ein für die Lagerung gezählter Vermögenswert wurde nicht zwingend für den sofortigen Einsatz vorbereitet.
Shared Location Folders verstärken dieselbe Lektion. Sie verwenden verschiedene Zugriffsstufen, können von einem Character als online oder offline verbunden werden und Locations mit Ablaufdatum enthalten. Fehlt eine Location in der aktiven Ansicht eines Piloten, kann das am Zustand des Ordners oder am Access liegen statt an einem veränderten Grid. Die Baseline sollte genügend Kontext zur Source erfassen, um diese Möglichkeit offenzuhalten.
Alter lässt sich zeigen, ohne die Aufzeichnung in eine Wand aus Uhren zu verwandeln. Die Gruppe benötigt Timestamps nur dort, wo Zeit die Deutung verändert. Die letzte Bestätigung der Route, welche die Bewegung dieses Abends trägt, ist wichtig. Das genaue Alter eines ungenutzten Zweigs vielleicht nicht.
Diese Auswahl verhindert zwei Fehler. Wird kein Alter festgehalten, wirken übernommene Aussagen gegenwärtig. Wird jede denkbare Zeit erfasst, gehen die Aussagen unter, welche eine Entscheidung tragen.
Die nützliche Frage lautet nicht: Wie alt sind alle unsere Informationen? Frage stattdessen: Welche alte Observation würde die nächste Handlung verändern, wenn sie nicht mehr zuträfe?
Veränderungen brauchen Bedeutung
Ein Unterschied ist Evidenz. Er ist noch keine Deutung.
Die verschwundene Signature, der nicht verfügbare Service und der alternde Zweig der Chain sind drei Abweichungen von der übernommenen Baseline. Keine von ihnen sollte unmittelbar zu einer Threat, einem Failure oder einem Grund erklärt werden, Home aufzugeben.
Frage zuerst, ob die Veränderung den genannten Zweck berührt. Eine fehlende Signature ohne Bezug zur Work dieses Abends kann lediglich die Darstellung des Systems verengen. Ein nicht verfügbarer Service ist sofort bedeutsam, wenn eine Aufgabe gleich von ihm abhängen wird. Eine alte Aufzeichnung der Chain wird dringend, sobald die Route das einzige Replacement tragen soll.
Bestimme danach die kleinste Aussage, die sich verändert hat. Der Character sah den Service nicht. Das gegenwärtige Ergebnis im Probe Scanner wich vom früheren Ergebnis ab. Der betreffende Zweig besitzt keine Bestätigung aus der gegenwärtigen Arbeitsphase. Diese Aussagen bewahren die Observation vor der Erklärung.
Vergleiche als Nächstes die Sources. Stammte die frühere Observation des Service von einem Eigentümer und die neue von einem Gast, kann Access den Unterschied erklären. Aufzeichnungen der Signatures, die unter verschiedenen sichtbaren Auswahlen entstanden, sind noch nicht vergleichbar. Ein der früheren Schicht nur als Reported übermittelter Zweig der Chain kann älter sein als die Nachricht, die ihn übermittelte.
Was nach diesem Vergleich verbleibt, kann ohne Drama eingeordnet werden.
Manche Abweichung ist zu erwarten und unterbricht die Work nicht. Manche Veränderung beeinträchtigt eine Capability und verlangt eine neue Entscheidung. Ein Widerspruch zwischen Sources verlangt Bestätigung. Fehlt Kontext, kehrt der Zustand zu Unknown zurück.
Unknown ist kein Vorwurf. Es ist korrekt, sobald die Baseline die beabsichtigte Schlussfolgerung nicht mehr tragen kann. Die betroffene Work kann pausieren, während nicht betroffene Work fortgesetzt wird.
Die Unterschiede aus der Eröffnungsszene führen nun zu verhältnismässigen Reaktionen. Der benötigte Service wird über die Ansicht des Characters geprüft, der ihn verwenden soll, und wenn nötig über einen befugten Eigentümer. Die fehlende Signature wird unter einer bekannten Ansicht erneut gescannt, bevor eine Schlussfolgerung über die Route verändert wird. Der alternde Zweig der Chain wird nicht für die geplante Bewegung freigegeben, bis die betreffenden Connections für diesen Zweck beobachtet worden sind.
Es wurde kein Notfall ausgerufen. Die Baseline hat Zeit für eine Untersuchung geschaffen, bevor sich mehrere Annahmen zu einer verbinden.
Wesentliches beobachten
Eine nützliche Überwachung ist kleiner als Home.
Der Versuch, jedes Objekt, jeden Vermögenswert, jede Berechtigung und jede Tätigkeit zu überwachen, würde aus gewöhnlicher Anwesenheit eine dauernde Berichterstattung machen. Das Ergebnis wäre detailliert und unlesbar. Wichtige Veränderungen könnten sich in genau jenem Aufwand verbergen, der sie sichtbar machen soll.
Wähle die wenigen Signale, welche den gegenwärtigen Zweck tragen.
Für das System kann dies die Darstellung der Signatures sein, die benötigt wird, um die betreffende Route wiederaufzubauen oder die geplante Work zu beginnen. Ihre Aufzeichnung nennt den beobachtenden Piloten, die Zeit und die Ansicht. Nicht jede unbeteiligte Anomaly muss wie ein dauerhafter Alarm behandelt werden.
Beobachte für die Chain die letzte bestätigte Observation des Zweigs, der Bewegung, Replacement oder Rückkehr trägt. Das Signal ist nicht die Zahl der Connections auf der Karte. Es fragt, ob die benötigte Beziehung in der Tiefe, welche die nächste Entscheidung verlangt, über aktuelle Evidenz verfügt.
Beobachte bei der Infrastruktur den bestimmten Service und den Zugriffspfad, von denen die Work abhängt. Ein allgemeiner Zustand der Structure kann eine Prüfung durch den Character, der handeln soll, nicht ersetzen. Eigentümer können Observations zu Fuel und zum Vulnerability State ergänzen, wenn diese Bedingungen den Zweck tragen; Gäste sollten nicht vorgeben, Informationen zu sehen, die nur Eigentümern offenstehen.
Beobachte bei den Vermögenswerten eine oder zwei Capabilities, deren Fehlen den Plan verändern würde. Das Signal kann eine zugängliche Scanning Capability oder die für den Rückzug benötigte Rückfallebene sein. Wert und Menge bleiben gegenüber der Nutzung zweitrangig.
Halte bei der Work den Steward und die nächste Entscheidung sichtbar. Eine offene Aufgabe ohne bestätigten Verantwortlichen ist selbst eine Abweichung, auch wenn jede physische Eingabe weiterhin vorhanden ist.
Jedes Signal benötigt einen Auslöser. Dieser ist nicht immer ein fester Zeitplan. Er kann mit einer Arbeitsphase, einer Bewegung wichtiger Capability, einem Handover, einer Änderung des Access oder in dem Moment beginnen, in dem eine neue Aufgabe von der Bedingung abhängt. Prüfe erneut, sobald sich die Konsequenz veralteter Information verändert.
Der Beginn einer Arbeitsphase bietet ein brauchbares Beispiel. Wer übernimmt, wiederholt nicht jede Observation, die jemals mit Home verbunden war. Die Person liest den von der früheren Schicht hinterlassenen Zweck und bestimmt die Bedingungen, die dieser Zweck weitergibt. Heute Abend sind das der für die Bewegung vorgesehene Zweig, der nach dieser Bewegung erforderliche Service und die Capability, die bei einem nötigen Wiederaufbau der Route gebraucht wird.
Der erste Durchgang bestimmt, was sofort fortgesetzt werden kann. Unbeteiligte Vermögenswerte müssen nicht erneut gezählt werden. Ein entfernter Zweig ausserhalb der vorgesehenen Route kann ausserhalb der Überwachung bleiben. Work, die weder vom fehlenden Service noch von der alternden Connection abhängt, kann unter ihrer eigenen Baseline fortgesetzt werden.
Der zweite Durchgang behandelt die Abweichung. Der Pilot löscht die frühere Observation des Service nicht, nur weil die aktuelle Ansicht davon abweicht. Beide Observations bleiben innerhalb ihrer Sources wahr: Der frühere Character sah den Service damals; der eintreffende Character sieht ihn jetzt nicht. Die nächste Bestätigung wird über den Zugriffspfad zugewiesen, den die geplante Work tatsächlich verwenden wird.
Der Zweig der Chain erhält dieselbe Behandlung. Sein Eintrag auf der Shared Map bleibt als Geschichte erhalten, doch seine alte Bestätigung wird nicht als aktuelles Routenwissen dargestellt. Ein der Bewegung zugewiesener Pilot beobachtet die betreffende Connection erneut. Bis dahin wartet nur die betroffene Bewegung. Die Karte hat nicht versagt; ihre Ungewissheit wurde sichtbar, bevor sie mit einem Versprechen verwechselt werden konnte.
Beim Handover wird die Überwachung zu einer kurzen Darstellung veränderter Bedingungen und offener Entscheidungen. Die nächste Schicht benötigt keinen Leistungsbericht. Sie benötigt die noch offene Frage zur Signature und die Grenzen der Bestätigung des Service. Zudem muss sie wissen, dass der Routenzweig beobachtet wurde, nachdem die Bewegung verschoben worden war. Jede Aussage behält ihre Source und Zeit.
Dieser Rhythmus ist wichtiger als eine dauerhafte Checkliste. Lies den übernommenen Zweck. Bestätige die Bedingungen, welche die nächste Konsequenz tragen. Bewahre Abweichungen, bis ihre Sources verglichen werden können. Übergib die verbleibenden Unknowns mit Verantwortlichen. Die Einzelheiten verändern sich mit der Work, während die Disziplin erkennbar bleibt.
Die Überwachung benötigt ausserdem eine Reaktionsgrenze. Weicht ein Signal von der Baseline ab, halte die Observation fest, begrenze den betroffenen Zweck und weise die nächste Bestätigung zu. Mache nicht aus jeder Abweichung einen allgemeinen Stopp. Lass die Work nicht bloss deshalb weiterlaufen, weil kein einzelner Unterschied dramatisch wirkt.
Diese kleine Auswahl kann sich zusammen mit Home verändern. Ein während einer Phase des Scanning unbedeutender Service kann die Überwachung verlassen. Eine Transportroute kann hinzukommen, sobald Replacement beginnt. Die Baseline bleibt nützlich, weil sie der Abhängigkeit statt der Gewohnheit folgt.
Nun kann der Pilot aus der Eröffnungsszene Home beschreiben, ohne es sicher oder unsicher zu nennen. Die Darstellung des Systems enthält eine ungeklärte Abweichung bei einer Signature. Die für die Bewegung benötigte Route ist alt und wartet auf eine neue Observation. Ein erforderlicher Service ist für den vorgesehenen Character nicht bestätigt. Vermögenswerte und unbeteiligte Work bleiben innerhalb ihrer genannten Bedingungen.
Das genügt, um zu entscheiden, was pausiert und was weitergeht.
Feldprinzip
Eine Baseline ist ein datierter Vergleich, kein Versprechen, dass gewöhnliche Bedingungen bestehen bleiben.
Trenne System, Chain, Infrastruktur, Vermögenswerte und Work. Gib jeder tragenden Observation eine Source, einen Timestamp und einen Zweck. Behandle eine Abweichung als Evidenz, bevor du ihre Ursache benennst. Beobachte nur die Bedingungen, deren Veränderung die nächste Entscheidung beeinflussen würde.
Home wird lesbar, wenn eine neue Observation drei Fragen beantworten kann: Was wurde erwartet, was ist anders und welche Work verlangt nun eine Prüfung?
Die Antwort muss nicht jede Ursache klären. Sie muss die Grenze der Entscheidung offenlegen. Ein Character, der einen benötigten Service nicht sieht, hat eine Frage zum Access festgestellt, keinen Failure der gesamten Structure. Ein verändertes Ergebnis beim Scanning hat eine Abweichung im System festgestellt, keine feindliche Absicht. Eine alternde Routenaufzeichnung hat den Bedarf nach Bestätigung festgestellt, nicht den gegenwärtigen Zustand jeder Connection, die sie einst beschrieb. Genauigkeit verhindert, dass sich ein kleines Unknown zu einem allgemeinen Urteil über Home ausbreitet.
Diese Genauigkeit schützt auch den Aufwand. Piloten prüfen die Bedingung erneut, von der die nächste Entscheidung abhängt. Unbeteiligte Observations müssen nicht wiederholt werden, nur damit die Baseline vollständig wirkt.
Darin liegt ihr praktischer Wert. Die Baseline gibt gewöhnlicher Anwesenheit ein Gedächtnis, das infrage gestellt werden kann. Neue Evidenz kann es verändern, ohne umzuschreiben, was frühere Beobachter tatsächlich sahen. Und Work kann begrenzt werden, ohne aus jeder Ungewissheit einen Alarm zu machen.
Die Chain bleibt die älteste ungeklärte Bedingung. Ihre sichtbaren Zweige tragen noch immer frühere Observations, Berichte und Annahmen aus einer anderen Arbeitsphase. Eine Baseline kann dieses Alter offenlegen. Die Route ehrlich halten kann sie allein nicht.
Kapitel 6 folgt der Chain durch die Zeit.