Die Route aus Kapitel 6 wird bestätigt, bevor die Bewegung beginnt.
Am Ziel dockt der erste Character in der erwarteten Structure an. Er kann seine Schiffe und sein persönliches Inventar sehen, doch der für den nächsten Schritt benötigte Service scheint ihm nicht zur Verfügung zu stehen. Ein zweiter Character gehört zur besitzenden Corporation und trägt die Rolle Factory Manager. Er kann die betreffende Aufgabe der Corporation einsehen, doch das für ihre Fortsetzung benötigte Material lässt sich nicht aus der Hangardivision entnehmen.
In keiner der beiden Szenen muss etwas defekt sein.
Andocken versprach keinen Access zu jedem Service. Eine Corporation Role versprach keinen Access zu jedem Gegenstand. Aus dem Ownership der Structure wurde nicht jedes Mitglied zu ihrem Administrator, und aus der Sichtbarkeit einer Aufgabe wurde ihr Material nicht verwendbar.
Die Route beantwortete, wohin die Piloten reisen konnten. Sie konnte nicht beantworten, was ihre Characters nach der Ankunft tun konnten.
Diese Capability muss als Pfad gelesen werden. Ownership, Sichtbarkeit, Nutzung und Administration treffen auf unterschiedliche Systeme, bevor eine Handlung möglich wird. Verstehen lässt sich der Failure nur, wenn die Gruppe diese Fragen lange genug auseinanderhält, um die fehlende Bedingung zu finden.
Vier getrennte Fragen
Beginne mit Ownership: Wem gehört die Structure, der Vermögenswert oder die Information?
Ownership bezeichnet die Person oder Corporation, deren Systeme das betreffende Objekt enthalten. Es kann darauf hinweisen, wer die Befugnis letztlich zuweisen kann. Für sich allein beweist Ownership nicht, dass der Character auf dem Grid diese Befugnis jetzt besitzt.
Die Structure aus der Eröffnungsszene gehört einer Corporation. Diese Tatsache sagt nichts darüber, welches Mitglied ihr Profile bearbeiten darf, wer einen bestimmten Service nutzen kann oder wer Material aus einem Hangar der Corporation entnehmen darf. In einer Structure, die ihm nicht gehört, kann ein Gast nützliche Work ausführen. Ein Mitglied des Eigentümers kann dieselbe Work möglicherweise nicht abschliessen.
Die zweite Frage betrifft die Sichtbarkeit: Was kann dieser Character sehen?
Eine sichtbare Structure, ein sichtbarer Service, eine sichtbare Aufgabe oder Inventardivision liefert dem Character Information. Diese kann genügen, um einen Zustand zu melden. Eine solche Ansicht gewährt nicht immer das Recht, das Sichtbare zu verwenden oder zu verändern. Umgekehrt kann ein Character eine enge Fähigkeit besitzen, ohne eine bequeme Sicht auf alle umliegenden Informationen zu erhalten.
Die dritte Frage betrifft die Nutzung: Kann der Character den Service erhalten oder das für die Handlung benötigte Material verwenden?
Die Nutzung kann von einem Structure Profile, einer oder mehreren Access Lists, den Berechtigungen für Hangars der Corporation und dem Zustand des Service abhängen. Diese Bedingungen verschmelzen nicht, nur weil sie in derselben Structure zusammentreffen. Eine erfüllte Bedingung kann den Character an der nächsten noch immer stoppen.
Die vierte Frage betrifft die Administration: Wer kann den bestimmenden Zustand verändern?
Ein Administrator kann ein Profile bearbeiten oder eine Aufgabe der Corporation verwalten, ohne der Pilot zu sein, der die Work ausführen soll. Der arbeitende Pilot kann den Service nutzen, ohne die Befugnis zu besitzen, dessen Zielgruppe zu verändern. Administration ermöglicht es, andere Nutzer zu beeinflussen, und darf nicht daraus abgeleitet werden, dass ein Character eine einzelne Aufgabe abgeschlossen hat.
Material verdient einen eigenen Platz innerhalb dieses Modells. Sichtbar und nutzbar kann ein Service sein, während seine Eingabe in einer Division liegt, die der Character weder einsehen noch daraus entnehmen kann. Ebenso begründet Access zum Material keinen Access zu jenem Service, der es verarbeiten soll.
Erst wenn diese Ebenen bekannt sind, sollte die Gruppe nach Capability fragen. Die eigentliche Frage ist nicht, ob eine einzelne Berechtigung besteht. Capability hängt vom vollständigen Pfad ab. Der vorgesehene Character muss am vorgesehenen Ort und zur vorgesehenen Zeit vom Erkennen der Aufgabe bis zu ihrem Abschluss mit dem benötigten Schiff, Material und Service gelangen.
Der erste Character aus der Eröffnungsszene hat damit das Andocken und einen Teil seiner persönlichen Sichtbarkeit bestätigt. Der zweite hat die Befugnis zur Verwaltung der Aufgabe bestätigt. Keines der Ergebnisse beantwortet die nächste Handlung. Die fehlenden Bedingungen unterscheiden sich, obwohl beide Characters dasselbe Ergebnis beschreiben: Ich kann nicht fortfahren.
Profiles bieten Services
Ein Structure Profile legt fest, welche Services anderen Spielern zur Verfügung stehen. Die innerhalb dieses Profile zugewiesenen Access Lists bestimmen, wer auf jeden Service zugreifen kann.
Diese Trennung ist der erste Schlüssel zum Problem des angedockten Gastes. Andocken ist ein über das Profile geregelter Service. Der nach dem Andocken benötigte Service kann eine andere Zuweisung besitzen. Wer die erste Zielgruppe passiert, gehört dadurch nicht zu jeder weiteren.
Einem einzelnen Service innerhalb eines Profile können eine oder mehrere Access Lists unabhängig zugewiesen werden. Dasselbe Profile kann für mehrere Structures verwendet werden; eine Änderung daran betrifft alle Structures, die es verwenden. Ein Profile ist deshalb nicht bloss eine Bezeichnung an einer Hülle. Es wirkt als gemeinsame Festlegung des Service Access, deren Umfang vor einer Änderung verstanden werden muss.
Das Profile macht einen Service nicht physisch funktionsfähig. Es legt die Verfügbarkeit für Nutzer fest. Kapitel 8 trennt dieses Angebot vom Service Module, vom Fuel und von dem Zustand, die für die Bereitstellung der Capability nötig sind. Hier ist entscheidend, dass eine Konfiguration des Access erklären kann, weshalb zwei Characters bei derselben Structure unterschiedliche Ergebnisse erhalten.
Das gegenwärtige Profile kann vom CEO, den Directors und Mitgliedern mit der Rolle Station Manager in der besitzenden Corporation verändert werden. Diese Befugnis gehört zur Administration. Ihr Umfang ist grösser als die Fähigkeit des Gastes, anzudocken oder einen einzelnen Service zu nutzen. Der arbeitende Pilot sollte sie nicht erhalten, nur um einen ungeklärten Zugriffspfad zu lösen.
Der Administrator muss auch den richtigen Umfang erkennen. Die Bearbeitung eines Profile, das mehrere Structures verwenden, kann den Access über die Structure aus der Eröffnungsszene hinaus verändern. Ein örtliches Problem sollte keine gemeinsame Änderung auslösen, bevor der Eigentümer weiss, welches Profile, welcher Service und welche Access Lists das Ergebnis erzeugen.
Deshalb ist ein genauer Bericht wertvoll. Die Aussage «Der Service fehlt» vermischt mehrere Möglichkeiten. «Dieser Character kann andocken, aber zu diesem Zeitpunkt nicht auf den benötigten Service in dieser Structure zugreifen» benennt den geprüften Pfad. Ein Eigentümer kann die Zuweisung des Profile, die Access Lists des Service und den Betriebszustand des Service vergleichen, ohne eine einzelne Observation zu einem allgemeinen Failure zu erklären.
Profiles legen damit eine Beziehung offen, keine Garantie. Sie verbinden die angebotenen Services einer Structure mit Zielgruppen. Der Nutzer muss von diesen Zielgruppen weiterhin ausgewählt sein, alle getrennten Materialberechtigungen besitzen und eintreffen, während die Infrastruktur die Work tatsächlich ausführen kann.
Access Lists wählen
Access Lists sind Listen von Personen, die zusammen mit Profiles den Access zu Services in einer Upwell Structure kontrollieren.
Eine Access List kann einzelne Characters, Corporations, Alliances oder Everyone enthalten. Der betreffende Eintrag kann einem einzelnen Character den Access erlauben oder verweigern. Das Ergebnis folgt nicht der breitesten Art von Gruppe auf der Seite. Innerhalb einer Liste bestimmt die feinste zutreffende Einstellung: Alliance ist genauer als Everyone, Corporation genauer als Alliance und Character genauer als Corporation.
Angenommen, die Corporation des Gastes darf den benötigten Service nutzen, doch derselbe Gast besitzt in derselben Access List einen ausdrücklich blockierenden Eintrag für seinen Character. Die genauere Einstellung des Character bestimmt das Ergebnis dieser Liste. Der Character kann weiterhin der Corporation angehören und über eine andere Zuweisung andocken dürfen. Das Ergebnis beim Service ist kein Widerspruch.
Mehrere Access Lists fügen eine weitere Grenze hinzu. Sind demselben Service mehrere Listen zugewiesen, werden die zutreffenden Ergebnisse jeder Liste kombiniert. Eine Erlaubnis aus einer zugewiesenen Liste kann damit den Access gewähren, obwohl eine andere zugewiesene Liste den Character blockiert. Nur die Liste mit dem blockierenden Eintrag zu lesen, würde die endgültige Zielgruppe des Service nicht erklären.
Diese Verbindung muss verstanden sein, bevor jemand versucht, den Access zu reparieren. Das Hinzufügen eines Character zu einer weiteren Liste kann eine Erlaubnis erzeugen und den ursprünglichen Widerspruch bestehen lassen. Das Entfernen einer Corporation aus einer Liste kann wirkungslos bleiben, weil eine zweite Liste sie weiterhin zulässt. Der geprüfte Service und alle ihm zugewiesenen Listen bilden den betreffenden Pfad.
Auch die Administration einer Access List ist vom Ownership der Structure getrennt. Nur Admins oder Managers einer Access List können die von ihnen verwalteten Listen sehen und verändern. Ein Station Manager, der ein Structure Profile ändern kann, beweist damit keine administrative Kontrolle über jede zur Zuweisung verfügbare Access List. Für jede Ebene muss bestimmt werden, wer sie verändern kann, statt nach einer einzigen Rolle zu suchen, die ausreichend hochrangig klingt.
Das Modell rechtfertigt keinen breiten Access. Es ist auch keine Sicherheitsdoktrin zur Suche nach illoyalen Mitgliedern. Die Regel dient der Deutung: Beginne beim vorgesehenen Character und Service. Folge dem Profile zu jeder zugewiesenen Access List. Wende die spezifischen Einträge und ihre Kombination an. Halte an, sobald das beobachtbare Ergebnis erklärt ist, oder führe den ungeklärten Zustand zu Unknown zurück.
Der gescheiterte Pfad zum Service kann untersucht werden, ohne das Ownership des Gastes zu verändern. Zuerst prüft der Eigentümer den Pfad des Service im Profile. Anschliessend testet der Gast das Ergebnis mit demselben Character. Access ist erst bestätigt, wenn der vorgesehene Pfad funktioniert – nicht, wenn ein Administrator einen plausiblen Namen auf einer Liste sieht.
Roles ermöglichen Handeln
Corporation Roles gewähren bestimmte Fähigkeiten. Sie bilden keine allgemeine Vertrauensstufe, und ihre Namen können nicht für den Handlungspfad stehen.
Der zweite Character trägt Factory Manager. Diese Rolle erlaubt die Verwaltung von Aufgaben der Corporation, darunter Aufgaben, die von anderen Mitgliedern eingerichtet wurden. Sie erlaubt zudem unabhängig vom Zugriff auf den Hangar der Corporation die Auflistung und Nutzung von Blueprints der Corporation in der betreffenden Industry View.
Dieselbe offizielle Beschreibung bewahrt die fehlende Grenze: Eine Aufgabe, die Eingabematerial benötigt, verlangt weiterhin den richtigen Take Access für den betreffenden Hangar oder Container. Befugnis über die Aufgabe und Befugnis über das Material sind nicht dasselbe.
Die Hangardivisionen der Corporation unterscheiden mehrere Zugriffsfähigkeiten. Query erlaubt dem Character, den Inhalt des betreffenden Hangars zu sehen, aber keine Entnahme. Take erlaubt die Entnahme von Gegenständen und das Öffnen von Containern in diesem Hangar, nicht jedoch die Entnahme des Containers selbst. Container Take regelt die Entnahme von Containern. Auch der Standortkontext der Rolle muss dem Ort entsprechen, an dem das Material liegt.
Diese Unterschiede erklären mehrere Ergebnisse, die sonst willkürlich wirken. Ein Character kann die Eingabe sehen und sie nicht entnehmen. Ein anderer kann Take ohne Query besitzen und keine gewöhnliche Inventarauflistung erhalten, während eine Aufgabe in Industry das benötigte Material aus dem erlaubten Hangar dennoch prüfen und entnehmen kann. Beim dritten Character lassen sich Gegenstände aus einem Container entnehmen, nicht aber der Container selbst.
Das Kapitel benötigt nicht jede Corporation Role, um diesen Punkt zu zeigen. Es benötigt nur die von der Szene berührten Fähigkeiten. Factory Manager beantwortet, wer die Aufgabe verwalten darf. Query, Take und – wenn die Aufgabe den Container selbst bewegt – Container Take beantworten, wie das Material gesehen und gehandhabt werden kann. Das Profile und die Access Lists beantworten, ob der Service der Structure dem Character zur Verfügung steht.
Station Manager gehört zu einem anderen Pfad. Die Rolle bietet Verwaltungsoptionen für Upwell Structures, welche der Corporation gehören, darunter Profiles. Sie kann die für die Aufgabe benötigten Materialberechtigungen nicht ersetzen. Sie dem arbeitenden Mitglied zu geben, würde administrative Befugnis hinzufügen, ohne zwingend die fehlende Eingabe zugänglich zu machen.
Verfolge die Aufgabe aus der Eröffnungsszene vom Ergebnis rückwärts. Der Character muss die Aufgabe der Corporation verwalten, auf den richtigen Service zugreifen, das benötigte Material erkennen und dessen Verwendung durch die Aufgabe erlauben können. Die vorhandene Rolle bestätigt nur den ersten Teil. Der Failure sieht nicht länger nach einer unzuverlässigen Oberfläche oder einer defekten Structure aus. Der sichtbare Bruch liegt zwischen zwei berechtigten Ebenen der Zugriffsrechte.
Gastabhängigkeit unterscheidet sich
Gäste können echte Capability besitzen, ohne deren Grundlage zu besitzen.
Der erste Character dockt an, lagert persönliche Schiffe und kann vielleicht einige Services nutzen. Diese Handlungen sind weder eingebildet noch zweitrangig. Sie tragen wirkliche Work. Ihre Abhängigkeit unterscheidet sich, weil ein anderer Eigentümer das Profile, die Access Lists, die Service Modules und den Zustand der Structure kontrolliert, auf denen die Work beruht.
Damit ein Schiff an einer Upwell Structure ein Tether erhält, muss ausserdem die Erlaubnis zum Andocken bestehen. Diese Beziehung macht aus der Erlaubnis kein Sicherheitsversprechen. Ein aktives Tether besitzt bestimmte Wirkungen, während verschiedene Handlungen und Zustände es verhindern oder unterbrechen können. Der Pilot muss den aktiven Zustand beobachten, statt ihn aus der früher verfügbaren Andockerlaubnis abzuleiten.
Dasselbe Prinzip gilt innerhalb der Structure. Ein Gast, der gestern einen Service nutzte, besitzt Evidenz über den gestrigen Access und Betriebszustand. Das Profile oder eine zugewiesene Access List kann der Eigentümer verändern. Auch der Service kann in einen anderen Zustand wechseln. Ein Plan des Gastes sollte auf einer aktuellen Prüfung beruhen, wenn die Konsequenz dies verlangt.
Auch Eigentümer tragen Abhängigkeiten. Eine Corporation kann die Hülle besitzen, während die einzige Person, die eine benötigte Access List verändern kann, abwesend ist. Material kann der Corporation gehören, während dem vorgesehenen Betreiber die passenden Hangarrechte fehlen. Ownership bündelt die letztliche Kontrolle, garantiert aber nicht, dass die benötigten Personen und Berechtigungen zur benötigten Zeit zusammentreffen.
Dadurch unterscheidet sich die Rückfallebene von Eigentümern und Gästen. Ein Eigentümer kann einen Steward einsetzen, der den Pfad von Access und Infrastruktur innerhalb der gewählten Befugnisse der Corporation pflegt. Ein Gast kann diese Veränderung nicht voraussetzen. Er kann die angebotene Capability bestätigen, Alternativen bewahren und die Work begrenzen, die von der Konfiguration eines anderen abhängig ist.
Nichts davon macht Gastzugang grundsätzlich ungeeignet. Die Abhängigkeit ist widerrufbar und wird von anderen verwaltet; damit wird sie Teil der Baseline. Kann die Work bei einer Änderung des Access pausieren oder umziehen, ist die Abhängigkeit vielleicht akzeptabel. Würde ein nicht verfügbarer Service unersetzliche Capability oder offene Verpflichtungen festsetzen, benötigt der Plan eine andere Grenze, bevor die Work beginnt.
Der angedockte Gast aus der Eröffnungsszene sollte nicht nach dem Ownership der Structure fragen. Die nötige Antwort lautet, ob der benötigte Service seinem Character absichtlich zur Verfügung steht, wer ein unbeabsichtigtes Ergebnis korrigieren kann und was mit der geplanten Work geschieht, falls der Access fehlt.
Den Pfad prüfen
Namen von Berechtigungen sind Evidenz über eine Konfiguration. Eine abgeschlossene Handlung ist Evidenz über Capability.
Prüfe bei einer entscheidenden Aufgabe den Pfad mit jenem Character, der sie ausführen soll. Beginne beim Ergebnis und gehe rückwärts. Bestätige, dass der Character die Aufgabe erkennen, den Service erreichen und das benötigte Material unter den betreffenden Rechten der Corporation verwenden kann. Stelle danach fest, ob das richtige Schiff oder eine andere Capability vorhanden ist. Ein gesonderter Verantwortlicher muss die Befugnis besitzen, eine gescheiterte Ebene zu beheben, ohne unbeteiligten Access zu verändern.
Ort und Zeit gehören zur Prüfung. Eine mit dem falschen Hangarkontext verbundene Berechtigung kann das hier liegende Material nicht tragen. Das Ergebnis eines Service aus einer anderen Structure kann das zugewiesene Profile dieser Structure nicht bestätigen. Die erfolgreiche Handlung von gestern bleibt nützliche Geschichte, darf aber eine aktuelle Prüfung nicht unbemerkt ersetzen, wenn die Work nun eine grössere Konsequenz trägt. Diese Grenzen verhindern, dass ein vertrauter Name eines Character mehrere verschiedene Pfade wie eine einzige Berechtigung wirken lässt.
Die Prüfung sollte verhältnismässig sein. Sie muss kein wertvolles Material verbrauchen oder eine unumkehrbare Aufgabe beginnen, nur um eine Annahme zu beweisen. Der Character kann die betreffenden Ansichten untersuchen, das Erscheinen des Service bestätigen, den vorgesehenen Materialpfad prüfen und vor der Verpflichtung anhalten. Kann die Handlung nicht sicher getestet werden, halte fest, welche Teile direkt beobachtet wurden und welche abgeleitet bleiben.
Verwende den Character und nicht die Vorschau eines Administrators als Source für die Capability des Nutzers. Ein Eigentümer sieht vielleicht, dass ein Profile eine Access List enthält. Erst das Ergebnis des vorgesehenen Character bestätigt, wie der verbundene Pfad gegenwärtig für diesen Character aufgelöst wird.
Folge dem Pfad des Gastes aus der Eröffnungsszene. Das beabsichtigte Ergebnis ist nicht bloss der Eintritt in die Structure. Der Character muss andocken, den benötigten Service finden und den Punkt erreichen, an dem die geplante Work beginnen kann. Das Andocken gelingt; dieser Teil des Pfads erhält damit eine aktuelle Observation. Der fehlende Service stoppt die Prüfung, bevor Material eingesetzt wird.
Ein Eigentümer liest die Konfiguration danach vom selben Ergebnis rückwärts. Welches Profile ist dieser Structure zugewiesen? Welche Access Lists sind diesem Service zugewiesen? Wo wird der Gast innerhalb jeder Liste eingeordnet, und wie werden die Ergebnisse der Listen verbunden? Die Untersuchung bewahrt ausserdem eine getrennte Frage für Kapitel 8: Ist der Service selbst betriebsfähig?
Angenommen, der Eigentümer findet die Corporation des Gastes in einer erlaubenden Liste. Das ist noch kein Grund, die Frage zu schliessen. Ein genauerer Eintrag für den Character kann innerhalb derselben Liste bestimmen. Eine andere Liste kann ein eigenes Ergebnis beitragen. Der Eigentümer hat die betreffende Konfiguration erkannt; der Gast liefert weiterhin die endgültige Evidenz über den Access.
Nach einer bewussten Korrektur wiederholt der Gast nur den gescheiterten Teil. Ein neuer Versuch kann zeigen, dass der Service nun für den vorgesehenen Character verfügbar ist. Dieses Ergebnis beweist weder denselben Access für jedes Mitglied der Corporation des Gastes noch die Verfügbarkeit aller Services. Es kann auch nicht versprechen, dass der Access unverändert bleibt. Die Bestätigung ist an diesen Character und Zweck gebunden.
Der Pfad des Mitglieds der Corporation beginnt anderswo. Das Mitglied kann die Aufgabe sehen und verwalten; Factory Manager ist für diesen Teil der Aufgabe damit bereits belegt. Der Failure tritt dort ein, wo die Work auf ihre Eingabe trifft. Das Mitglied bestätigt die betreffende Hangardivision und was die Oberfläche dort sehen oder entnehmen lässt.
Ist die Eingabe unsichtbar, untersucht die Gruppe Query im richtigen Standortkontext. Ist sie sichtbar, kann aber nicht wie benötigt verwendet werden, wird Take relevant. Soll der Container selbst bewegt werden, stellt sich die engere Frage nach Container Take. Jede Prüfung folgt dem Objekt, das die Aufgabe tatsächlich benötigt. Keine beginnt damit, in der Hoffnung auf Erfolg ein Bündel von Rollen zu vergeben.
Diese Methode schützt spätere Handovers. Die Aufzeichnung kann sagen, dass der Pfad eines Gastes zum Service bestätigt und der Materialpfad eines Mitglieds der Corporation korrigiert wurde. Die nächste Schicht erbt zwei begrenzte Observations statt der irreführenden Schlussfolgerung, der Access sei repariert.
Das Gegenteil gilt ebenso. Eine erfolgreiche Prüfung durch den Nutzer bestätigt nicht die Fähigkeit des Eigentümers, den Pfad später zu verändern. Die Administration sollte durch die dafür verantwortliche Person geprüft werden. Die beiden Sources beantworten unterschiedliche Fragen.
Halte die Prüfung mit ihrer Zeit und ihrem Zweck fest. Access geprüft altert schlecht, weil die Aussage Character, Service, Material und Handlung auslässt. Die Feststellung «Der benannte Character konnte vor dieser Aufgabe den benötigten Service und den Materialpfad sehen» kann die genannte Work tragen, ohne dauerhaften Access zu behaupten.
Zwei begrenzte Ergebnisse bleiben. Die Prüfung folgt dem Pfad des Gastes über das Profile und die zugewiesenen Access Lists, bis der vorgesehene Character den Service nutzen kann oder die Work verschoben wird. Der Pfad des Mitglieds zur Aufgabe wird über Factory Manager und den betreffenden Access zum Hangar geprüft, bis die Eingabe genutzt werden kann oder ein anderer befugter Betreiber die Aufgabe annimmt.
Niemand musste aufgrund einer Vermutung weitreichende Befugnisse vergeben. Der Name einer Rolle wurde nicht als Beleg für Bereitschaft behandelt. Jede fehlende Capability wurde auf jener Ebene gefunden, die sie tatsächlich bereitstellen konnte.
Feldprinzip
Access ist nicht Ownership. Etwas zu sehen, gewährt nicht die Erlaubnis, es zu verwenden. Eine Rolle ist nicht die abgeschlossene Handlung, und Administration ist nicht Bereitschaft.
Lies Capability als Pfad durch den vorgesehenen Character, den Ort, den Service, das Material und die Befugnis. Lass Profiles die angebotenen Services beschreiben, Access Lists ihre Zielgruppen auswählen und Corporation Roles nur jene Fähigkeiten bereitstellen, die sie tatsächlich benennen. Bestätige das Ergebnis durch den Character, der handeln muss.
Die Route aus Kapitel 6 brachte beide Piloten zur richtigen Structure. Kapitel 7 erklärt, weshalb sie nach ihrer Ankunft dennoch nicht arbeiten konnten. Sobald die Pfade der Berechtigungen korrigiert sind, bleibt eine weitere Abhängigkeit ausserhalb jeder Access List und jeder Rolle.
Eine vollständige Berechtigung kann noch immer zu einem Service ohne Fuel, in einem Offlinezustand oder ohne Unterstützung für die umgebende Work führen. Rechte ermöglichen den Versuch; sie halten die Infrastruktur nicht funktionsfähig.
Kapitel 8 folgt dem Service selbst.