Zwei mögliche Systeme haben die erste Diskussion überstanden.
Auf der gemeinsamen Seite wirken sie nahezu gleich. Beide sind erreichbar. Beide bieten Raum, in dem die Gruppe arbeiten könnte. In jedem System ist eine Upwell Structure sichtbar, doch nur eine gewährt derzeit Gastzugang. Kurze Notizen nennen eine Class, einen Effect und mehrere beim Scouting beobachtete Connections.
Die Frage am oberen Rand der Seite lautet, welches System besser sei.
Es ist die falsche Frage.
Ein Kandidat unterstützt die geplante Work, rückt Replacement jedoch weiter weg. Der andere ist heute bequem, weil eine andere Corporation Access gewährt. Diese Bequemlichkeit beruht auf einer Entscheidung, welche die Gruppe nicht kontrolliert. Keines der Systeme ist einfach gut oder schlecht. Jedes verlangt, eine andere Art von Abhängigkeit zu akzeptieren.
Die Wahl von Home beginnt mit der Frage, was das System tragen soll.
Zweck vor Class
Eine Class lässt sich leicht in eine Überschrift setzen. Der Zweck ist schwieriger, denn er zwingt die Gruppe, sich selbst zu beschreiben.
Was werden die Menschen hier tatsächlich tun? Wie oft werden sie es tun? Welche Capability muss bei ihrer Ankunft verfügbar sein? Was muss in das System oder aus dem System gebracht werden? Wie lange soll die Anordnung bestehen? Diese Fragen sind weniger elegant als eine Rangliste, doch sie zeigen, was eine Rangliste verbergen würde.
Angenommen, die Gruppe erklärt, Home solle Exploration, begrenzte Ressourcenarbeit und grundlegendes Replacement für wenige Piloten tragen. Dieser Satz ist ein Anfang, kein vollständiger Zweck. Er lässt offen, ob die Gruppe bei verändertem Access pausieren kann, ob Materialien täglich hinausgebracht werden müssen und ob die Abwesenheit einer Person die Work stoppen würde.
Ein brauchbarer Zweck besteht aus fünf Teilen.
Erstens benennt er die Work. Im Wormhole Space leben ist eine Identität. Eine kleine Basis für Exploration und eine bestimmte Phase von Ressourcenarbeit unterhalten beschreibt eine Nutzung.
Zweitens benennt er die Menschen. Ein für einen unabhängigen Piloten gewähltes System erzeugt andere Koordinationskosten als eines, das mehrere Schichten tragen soll. Der Unterschied liegt nicht nur in der Grösse. Mehr Menschen bedeuten mehr Handovers, mehr Eigentümer und mehr Gelegenheiten, bei denen eine Annahme unbemerkt weitergegeben wird.
Drittens benennt er die erforderlichen Capabilities. Dazu gehören Scanning, Lagerung und Replacement sowie alle Services, welche die Work tatsächlich benötigt. Sie sollten sichtbar sein, bevor eine Structure wegen ihres Angebots bewundert wird. Eine bloss angenehme Capability darf während des Vergleichs nicht unbemerkt zur Voraussetzung werden.
Viertens benennt er die Zeit. Ein Versuch kann Abhängigkeiten akzeptieren, die für eine unbegrenzte Anwesenheit ein schwaches Fundament wären. Eine auf Dauer angelegte Anordnung muss Abwesenheit, verzögertes Replacement und veränderlichen Access überstehen, ohne so zu tun, als würden diese Bedingungen nie eintreten.
Schliesslich benennt er das Ende. Die Gruppe sollte wissen, welches Ergebnis den Versuch erfolgreich machen würde, welcher Befund das System ungeeignet machen würde und wie viel zurückbleiben darf, solange diese Entscheidung offen ist.
Ein brauchbarer Zweck könnte so lauten: Während einer Versuchsphase trägt Home die Exploration mehrerer Piloten. Es beherbergt ersetzbare Arbeitsvermögenswerte und bietet nur die Services, die nötig sind, um diese wieder einsetzen zu können. Die Work pausiert, wenn die betreffende Chain kein Replacement tragen kann. Der Versuch endet, bevor ein einzelner Vermögenswert oder eine Regelung für Access notwendig wird, um alles andere zurückzuholen.
Die Formulierung sagt bewusst nicht voraus, wie oft nützliche Connections erscheinen oder wie viel Work die Piloten abschliessen werden. Sie benennt, welche Capability das System tragen soll und was die Gruppe noch nicht von ihm verlangen wird. Neue Gelegenheiten können beobachtet werden, ohne während desselben Versuchs zu neuen Verpflichtungen aufzusteigen.
Der Zweck sollte auch für jemanden verständlich sein, der an der Wahl des Systems nicht beteiligt war. Beruht die Erklärung auf Begeisterung, Ruf oder einer ungeschriebenen Geschichte, kann die nächste Schicht sie nicht prüfen. Ein kurzer, ausdrücklicher Zweck gibt späteren Belegen etwas, das sie bestätigen oder infrage stellen können.
Der Zweck wählt das System nicht allein. Er verwandelt Systemeigenschaften in beantwortbare Fragen. Eine Class wird in Bezug auf eine bestimmte Tätigkeit bedeutsam. Ein Effect wird zur Bedingung, die auf tatsächliche Schiffe und Work wirkt. Connections werden zu Routen, die eine bestimmte Bewegung tragen sollen. Infrastruktur wird zu einer Gruppe von Capabilities mit Verantwortlichen und Grenzen.
Ohne Zweck lädt jedes nützliche Merkmal zu einer weiteren Tätigkeit ein. Die Gruppe wählt ein System, weil dort vieles möglich wäre, und entdeckt später, dass sie nicht erklären kann, welche dieser Möglichkeiten die Verpflichtung rechtfertigte. Mit einem Zweck bleibt das Mögliche vorerst nur möglich. Nur die erforderlichen Bedingungen fliessen in die Entscheidung ein.
System lesen
Gewöhnliche Wormhole Systems werden üblicherweise in die Classes C1 bis C6 eingeteilt. Die offiziellen Static Data bilden ausserdem die Wormhole Class und die System Effects ab. Diese stabilen Systemeigenschaften lassen sich erfassen und prüfen. Sie sind keine vollständige Beschreibung von Home.
Eine Class ist zuerst eine Kategorie und erst danach eine Interpretation. Sie hilft festzustellen, welches System betrachtet wird und welche weiteren Fragen zum Plan gehören. Für sich allein zeigt sie weder die morgen verfügbare Route noch die Menschen, die das System teilen werden, oder den Access, den ein Gast behalten wird.
Dieser Unterschied ist wichtig, weil Spieler mit der Bezeichnung der Class oft fremde Schlussfolgerungen übernehmen. Ein Kandidat wird möglicherweise als einfach oder schwierig, reich oder arm, geeignet oder unerwünscht bezeichnet, bevor der Zweck der Gruppe im Satz vorkommt. Manche dieser Urteile mögen für die Person nützlich gewesen sein, die sie gebildet hat. Es bleiben Interpretationen für einen anderen Plan.
Erfasse zuerst die Eigenschaft.
Das System besitzt eine angegebene Class. Erfasse die Source, anhand derer sie bestimmt wurde. Das System besitzt einen Effect oder es wurde kein relevanter Effect festgestellt. Erfasse ihn getrennt. Structures und andere sichtbare Infrastruktur gehören zu einer weiteren Ebene. Gegenwärtige Connections gehören zur Chain, nicht in das Feld der Class.
Diese Trennung verhindert, dass eine korrekte Beobachtung eine unbelegte Schlussfolgerung trägt. C3 kann eine geprüfte Eigenschaft sein. Die Aussage C3 ist für uns richtig bezeichnet dagegen eine Entscheidung, die den Zweck, die Capabilities und die akzeptierten Kosten der Gruppe benötigt. Die erste Aussage kann wahr bleiben, während sich die zweite verändert.
Static Data sind hier wertvoll, weil sie den Unterschied zwischen den Definitionen des Spiels und den betrieblichen Erfahrungen der Bewohner eines Systems bewahren. Sie enthalten Informationen zu Wormhole Classes und Effects. Drittentwicklern stellen sie jedoch keine systemspezifischen statischen Wormholes bereit, die Spieler möglicherweise aus Erfahrung oder anderen Aufzeichnungen erwarten. Eine Feldnotiz über eine erwartete Connection muss deshalb ihre eigene Source und Ungewissheit bewahren.
Dieses Kapitel benötigt keinen Katalog der Classes. Ein solcher Katalog würde zur Wahl nach Bezeichnung verleiten und überall dort veralten, wo er Werte, Ertrag oder eine vorausgesetzte Lebensweise einschmuggelt. Der Explorer benötigt eine klarere Fähigkeit: Lies jede Systemeigenschaft und frage danach, welche Konsequenz sie für diesen Zweck besitzt.
Kann eine Gruppe diese Frage nicht beantworten, sollte sie die Lücke nicht mit dem Ruf des Systems füllen. Sie kann die Konsequenz prüfen, eine aktuelle Source suchen oder die Eigenschaft ungeklärt lassen. Unknown ist nützlicher als eine übernommene Rangliste.
Connections lesen
Der erste Kandidat bot während mehrerer Scouting-Besuche eine bequeme Route. Beim zweiten waren wiederholt mehr Schritte nötig, um die von der Gruppe genutzten Orte zu erreichen. Es liegt nahe, aus diesen Beobachtungen dauerhafte Eigenschaften der Systeme zu machen.
Sie sind keine dauerhaften Eigenschaften.
Wormholes bilden kurzlebige Connections. Ihre Informationen geben grobe Hinweise auf Lebensdauer und Massenzustand, aber keinen Fahrplan und kein Versprechen für das nächste Ziel. Die um einen Kandidaten beobachtete Chain beschreibt den Access während dieser Observation. Auch wiederholte Aufzeichnungen können sie nicht zu Infrastruktur machen.
Wiederholte Observations können dennoch nützlich sein. Sie zeigen, was die Gruppe tatsächlich vorgefunden hat, wie oft sie Routen neu aufbauen musste und welche Bewegungen während der Stichprobe schwierig waren. Ihr Wert beruht auf bewahrten Grenzen: Daten, Sources, fehlenden Schichten und dem Zweck, nach dem die Routen beurteilt wurden.
Nenne dies ein Profil der beobachteten Connections. Das Wort Profil bedeutet keine garantierte Gruppe von Ausgängen. Es bezeichnet eine kontrollierte Geschichte dessen, was die Gruppe vorfand und was dieser Befund von ihr verlangte.
Die Aufzeichnung sollte vier Dinge auseinanderhalten.
Die gegenwärtige Chain zeigt die Connections, die dem letzten Beobachter zur Verfügung standen. Eine erwartete Beziehung bezeichnet etwas, von dem die Bewohner mit angegebener Source glauben, dass es wahrscheinlich gefunden wird. Der Routenbedarf beschreibt, was der Zweck wie oft bewegen muss. Die Routentoleranz legt fest, wie die Gruppe handelt, wenn diese Bewegung nicht wie geplant stattfinden kann.
Diese Ebenen beantworten verschiedene Fragen. Ein heute nützlicher Ausgang kann einen Scouting-Flug tragen, ohne zu beweisen, dass das System regelmässigen Transport unterstützt. Eine erwartete Connection kann den nächsten Scan leiten, ohne Ladung zum Transport freizugeben, bevor die Route beobachtet wurde. Eine schwierige Route kann akzeptabel sein, wenn die Work pausieren kann, aber ungeeignet, wenn Replacement von einer Frist abhängt.
Hier wird die Wahl von Home operativ. Die Gruppe wählt keine dauerhafte Strasse. Sie entscheidet, wie viel wiederkehrende Work sie akzeptieren kann, um vorübergehende Strassen zu entdecken, zu beurteilen und zu nutzen.
Der Vergleich der Kandidaten sollte deshalb Aussagen wie dieses System hat guten Access vermeiden. Benenne, was beobachtet wurde und was der Zweck verlangt. Vielleicht erforderte ein Kandidat bisher längere Transportwege, während der andere im gleichen Beobachtungszeitraum leichter erreichbar war. Ein Ergebnis kann bevorzugt werden, doch der Vergleich muss die Möglichkeit bewahren, dass die nächste Chain diese Erfahrung umkehrt.
Eine Entscheidung unter dieser Ungewissheit ist nicht schwach. Sie ist ehrlich. Schwach wäre es, einen unumkehrbaren Plan auf einer Routenbeschreibung aufzubauen, die nie beanspruchte, dauerhaft zu sein.
Der Beobachtungszeitraum sollte zur unterstützten Entscheidung passen. Ein kurzer Besuch kann belegen, dass während des Besuchs Bewegung möglich war. Er kann nicht den wiederkehrenden Aufwand des Wohnens belegen. Längere Beobachtung kann Unterschiede zeigen, wird aber nie zur Garantie. Die Aufzeichnung gewinnt an Wert, wenn sie ihren Umfang zeigt, und verliert ihn, wenn ruhige Phasen oder fehlende Beobachter stillschweigend als gewöhnliche Bedingungen behandelt werden.
Warte nicht auf eine perfekte Stichprobe. Auch das Warten kostet Zeit und kann die Gruppe dazu verleiten, so zu handeln, als sei der Kandidat bereits gewählt. Sammle genügend Belege für die Grösse der ersten Verpflichtung, halte diese umkehrbar und beobachte weiter, nachdem der Versuch begonnen hat.
Effect lesen
Ein Effect verändert die Bedingungen, unter denen Schiffe in einem Wormhole System arbeiten. Die offiziellen Static Data bezeichnen die Effect Types und die Systemdaten, zu denen sie gehören. So werden das Vorhandensein und der Typ eines Effect zu prüfbaren Eigenschaften. Die operative Konsequenz hängt weiterhin vom Plan ab.
Derselbe Effect kann auf verschiedene Schiffe, Fittings, Aufgaben und Toleranzen treffen. Ihn als nützlich oder schädlich zu bezeichnen, bevor diese Beziehungen benannt sind, wiederholt den Fehler bei der Class. Eine Eigenschaft wird zur Rangfolge, ohne den Plan unter dem Urteil zu zeigen.
Lies den Effect in drei Durchgängen.
Stelle zuerst fest, welcher Effect gilt. Halte die aktuellen offiziellen Daten oder eine andere kontrollierte Source sichtbar. Verlasse dich nicht auf eine aus einer alten Karte übernommene Bezeichnung, wenn die Eigenschaft geprüft werden kann.
Bestimme danach, welche erforderliche Capability er berührt. Die Frage ist nicht, ob der Effect beliebt ist. Sie lautet, ob er die Schiffe oder Handlungen verändert, von denen der benannte Zweck abhängt. Benötigt der Zweck eine Capability nicht, sollte ihre Wechselwirkung die Wahl nicht bestimmen.
Entscheide schliesslich, wie die Konsequenz geprüft wird. Eine Gruppe muss möglicherweise bestätigen, dass ihre vorgesehenen Schiffe, Reserven und Arbeitsgewohnheiten weiterhin geeignet sind. Die Prüfung gehört zur Gruppe und ihrem gegenwärtigen Plan. Sie darf nicht als zeitlose Regel für alle Leser verkleidet werden.
Für dieses Entscheidungsmodell ist keine numerische Tabelle der Effects nötig. Zahlenwerte würden eine eigene Prüfung aktueller Daten verlangen, und eine vollständige Liste würde zur Optimierung verleiten, bevor die Work verstanden wurde. Für Explorer soll der Effect als Betriebsbedingung sichtbar bleiben, nicht zur Identität des Systems werden.
Das Ergebnis lässt sich in einfacher Sprache festhalten. Effect bestätigt; Wechselwirkung mit der geplanten Scanning Capability nach einer Prüfung akzeptiert. Oder: Effect bestätigt; Konsequenz für die erforderliche Work bleibt Unknown, daher hängt noch keine Verpflichtung davon ab.
Eine solche Aufzeichnung ist weniger eindrucksvoll als eine farbcodierte Rangliste. Für die nächste Person ist sie nützlicher, weil die Grenze zwischen Eigenschaft, Interpretation und Entscheidung erhalten bleibt.
Bestehende Infrastruktur
Der zweite Kandidat wirkt einfacher, weil bereits eine Structure vorhanden ist. Ihre gegenwärtige Nutzung durch die Gruppe ist ein echter Vorteil. Sie entspricht nicht der Kontrolle darüber.
Upwell Structure Profiles legen fest, welche Services anderen Spielern angeboten werden. Access Lists bestimmen, wer diese Services nutzen kann. Eine sichtbare Structure, ein angebotener Service und der tatsächliche Access eines Character sind deshalb getrennte Tatsachen. Jede kann wahr sein, während eine andere falsch ist oder sich später verändert.
Eine Gastregelung sollte als Abhängigkeit von einem anderen Eigentümer gelesen werden. Welche Capabilities sind jetzt verfügbar? Wer besitzt die Kontrolle über Profile und Access Lists? Wie wird eine Veränderung bemerkt? Welche Work stoppt, wenn Access entzogen wird? Welche Vermögenswerte können ohne diesen Access zurückgeholt werden? Die Antworten entscheiden, ob die Nutzung als Gast einen Versuch, gewöhnliche Work oder nur eine vorübergehende Bequemlichkeit trägt.
Der Eigentümer trägt andere Verpflichtungen. Nur Mitglieder einer spielergeführten Corporation mit der passenden Rolle können eine Upwell Structure einsetzen. Die gegenwärtigen offiziellen Regeln für die Bereitstellung schliessen zudem Shattered Wormhole Systems und Thera aus. Diese Grenzen sind für die Wahl wichtig, weil die Gruppe nicht in jedem Kandidaten den Gastzugang durch eine eigene Upwell Structure ersetzen kann.
Das ist kein Grund, Ownership automatisch vorzuziehen. Ownership schafft Kontrolle über einige Entscheidungen und Verantwortung für viele weitere. Die Structure, ihre Services, Betriebsmittel, Zustände, Gestaltung des Access und spätere Entfernung werden zu Verpflichtungen. Kapitel 8 wird diese Pflege direkt untersuchen. Vorerst genügt es, die Vorstellung zurückzuweisen, Ownership verwandle Ungewissheit in Dauerhaftigkeit.
Sowohl Gastnutzung als auch Ownership können ein gültiges Home tragen. Sie versagen auf unterschiedliche Weise.
Eine Capability des Gastes kann verschwinden, weil ein anderer Eigentümer Access, Services oder die Vereinbarung selbst verändert. Der Gast kann diese Abhängigkeit verringern, indem er die Lagerung begrenzt, eine Alternative bewahrt und festlegt, wie schnell Work beendet werden kann. Der Eigentümer kann Access kontrollieren und trotzdem durch vernachlässigte Betriebsmittel, unklare Verantwortung oder den Zustand der Infrastruktur eine Capability verlieren. Kontrolle verlagert die Abhängigkeit; sie kann sie nicht entfernen.
Bestehende Infrastruktur muss ausserdem für jeden Service einzeln gelesen werden. Die Anwesenheit der Structure belegt, dass das Objekt besteht. Sie kann weder beweisen, dass jeder gewünschte Service angeboten wird, noch dass der aktuelle Character ihn nutzen kann oder dass er für die Dauer des Plans verfügbar bleibt. Bestätige nur die Capabilities, die der Zweck verlangt, und binde die Observation an eine Zeit.
Die beiden Kandidaten wirken nun weniger ähnlich. Einer verlangt von der Gruppe, einen grösseren Teil der Infrastrukturverpflichtung selbst zu tragen. Der andere ermöglicht einen leichteren Anfang, legt aber eine wichtige Entscheidung in fremde Hände. Der bedeutsame Unterschied liegt nicht zwischen Unabhängigkeit und Abhängigkeit. Er liegt darin, welche Abhängigkeit die Gruppe sehen, begrenzen und beenden kann.
Ein einfacher Beginn darf nicht mit einer kleinen Verpflichtung verwechselt werden. Gastzugang kann die unmittelbare Work der Bereitstellung beseitigen und zugleich Vermögenswerte und Routinen hinter einer Berechtigung ansammeln, welche die Gruppe nicht erhalten kann. Ownership kann mehr Vorbereitung verlangen und zugleich die kontrollierenden Entscheidungen verdeutlichen. Beide Anordnungen werden schwer, sobald die dahinter angesammelten Vermögenswerte nicht mehr nach dem Zeitplan der Gruppe entfernt werden können.
Deshalb gehört Access selbst dann in die Aufzeichnung der Auswahl, wenn er unkompliziert wirkt. Notiere die tatsächlich genutzte Capability, die kontrollierende Partei, die jüngste Bestätigung und die verfügbare Handlung, falls sie sich verändert. Die Aufzeichnung macht einen anderen Eigentümer nicht berechenbar. Sie verhindert, dass Bequemlichkeit mit Kontrolle verwechselt wird.
Zielkonflikt akzeptieren
Nachdem die Eigenschaften getrennt wurden, gewinnt keiner der Kandidaten jede Spalte.
Das erste System passt zur geplanten Work und gibt der Gruppe mehr Kontrolle über die erforderliche Capability. Seine beobachteten Routen haben Replacement langsamer und aufwendiger gemacht. Seine Wahl bedeutet, den Transportaufwand zu akzeptieren und zu begrenzen, was zwischen nützlichen Connections unersetzbar werden darf.
Das zweite erlaubt der Gruppe, mit weniger eigener Infrastruktur zu beginnen. Der gegenwärtige Gastzugang trägt die erforderlichen Services. Seine Wahl bedeutet, zu akzeptieren, dass eine andere Corporation eine Capability kontrolliert, von der die Work abhängt. Die gewählte Anordnung muss der Gruppe erlauben, zu pausieren, Vermögenswerte zurückzuholen oder zu gehen, wenn sich dieser Access verändert.
Keine Rechnung macht diese Kosten gleich. Die Entscheidung hängt davon ab, welchen Failure der Zweck toleriert und welche Last die Gruppe tatsächlich tragen kann. Eine Gruppe mit wenig Zeit für Infrastruktur kann begrenzte Gastnutzung vernünftigerweise vorziehen. Eine Gruppe, deren Work keinen ungewissen Access toleriert, kann die Transportlast bevorzugen. Kehre den Zweck um und dieselben Systeme können ihre Reihenfolge tauschen.
Behandle die Wahl als begrenzte Hypothese.
Benenne den Zweck: welche Work, für wen und für wie lange. Erfasse die geprüften Eigenschaften: Class, Effect, beobachtete Connections und erforderliche Infrastruktur. Benenne den akzeptierten Zielkonflikt in einem Satz. Lege danach fest, welche Belege eine Überprüfung auslösen.
Die Entscheidungsaufzeichnung sollte auch verworfene Interpretationen bewahren. Die Class wurde erfasst, aber nicht als Ertragsrangliste verwendet. Der gegenwärtige Gastzugang wurde bestätigt, aber nicht als dauerhaft behandelt. Beobachtete Connections flossen in den Versuch ein, wurden jedoch nicht zu garantierten Routen erhoben. Diese Grenzen schützen davor, dass die Entscheidung beim Nacherzählen gewisser wird.
Eine Überprüfung kann durch wiederholtes Versagen notwendiger Bewegungen, veränderten Access oder einen nicht verfügbaren Service ausgelöst werden. Eine Wechselwirkung des Effect, welche die erforderliche Work ungeeignet macht, oder eine von der Gruppe nicht tragbare Arbeitslast kann die Überprüfung ebenfalls auslösen. Die Bedingung sollte beobachtbar sein. Wir mögen das System nicht mehr lässt sich schwer in eine Handlung übersetzen. Die Route für Replacement hat wiederholt die in unserem Versuch erlaubte Verzögerung überschritten zeigt, welche Annahme versagte.
Begrenze schliesslich die erste Verpflichtung. Bewege nur die Vermögenswerte, die zur Prüfung des Zwecks nötig sind. Baue nicht mehrere Tätigkeiten um den Kandidaten auf, bevor die erste ihre Tragfähigkeit gezeigt hat. Lege einen Termin oder ein Ereignis für die Überprüfung fest und bewahre einen Weg, den Versuch zu beenden, ohne dass das System ausgerechnet beim Aufbruch bequem werden muss.
Dieses Vorgehen garantiert nicht die Wahl des besseren Kandidaten. Es macht den Grund für die Wahl sichtbar. Ändern sich die Bedingungen, kann die Gruppe eine aufgezeichnete Hypothese überarbeiten, statt eine Identität zu verteidigen.
Home ist nicht das System, das nichts verlangt. Ein solches System gibt es nicht. Home ist ein System, dessen notwendige Zielkonflikte genau genug beobachtet wurden, um sie zu akzeptieren, und dessen verbleibende Unknowns klein genug gehalten wurden, um einen Irrtum zu überstehen.
Feldprinzip
Wähle den Zweck vor der Eigenschaft.
Erfasse Class, Effect, Connections und Infrastruktur als getrennte Ebenen. Lass jede von ihnen erst in Beziehung zu Work, Menschen, Zeit und Exit der Gruppe günstig oder ungünstig werden. Behandle gegenwärtigen Access als gegenwärtig, wiederholte Routen als beobachtete Geschichte und Ownership als Verantwortung statt als Sicherheit.
Der Entscheid zu bleiben sollte eine begrenzte Hypothese mit Bedingungen für die Überprüfung sein, keine Erklärung, das ideale System sei gefunden worden.
Nach der Wahl von Home stellt sich die Frage, wie viel an diese Hypothese gebunden werden darf. Kapitel 3 wendet sich von der Auswahl dem Gewicht von Vermögenswerten, Replacement und konzentriertem Verlust zu.