Zusammenfassung

  • NxtGen Datacenter Cloud Technologies beschreibt sich als größten souveränen Cloud-Anbieter Indiens, mit fünf Rechenzentren, über 1.000 Kunden und einem vereinheitlichten GPU-Bestand aus NVIDIA-, AMD- und Intel-Plattformen; nur ein Standort, Bidadi bei Bangalore, ist in irgendeinem erhaltenen öffentlichen Dokument namentlich benannt.
  • Beide Registerabfragen zu AS132717 – der allgemeine Resolver und der RDAP-Dienst von APNIC selbst – scheiterten am 17. Oktober 2026, sodass sich registrierte Präfixe, die Zahl der Transit-Anbieter und der RPKI-Origin-Status des Netzes aus dem öffentlichen Register nicht feststellen ließen.
  • Eine veröffentlichte staatliche Liste der im MeitY Government Community Cloud, bei CERT-In oder in der IndiaAI Mission empanelten Anbieter war nicht auffindbar; drei Empanelment-Behauptungen stützen sich damit allein auf die Erklärung des Betreibers und nicht auf einen prüfbaren Nachweis.

Die Behauptung, wie sie formuliert ist

NxtGen Datacenter Cloud Technologies stellt eine knappe Menge von Aussagen auf. Die eigene Startseite erklärt: „NxtGen is India's largest sovereign CSP operating five data centers across India“ (NxtGen). Eine vom Unternehmen anlässlich des Starts von SpeedCloud Global herausgegebene Mitteilung ergänzt das operative Detail: NxtGen-Teams hätten die Flagge „from a Himalayan pass in Ladakh at over 18,000 feet to company's own datacenter at Bidadi near Bangalore“ getragen, und dasselbe Dokument hält fest, „NxtGen is empaneled under the MeitY Government Community Cloud, CERT-In, and the IndiaAI Mission“, das Unternehmen sei „India's largest sovereign cloud provider, serving more than 1000+ customers across the country“, und das „NxtGen AI portfolio unifies GPU platforms from NVIDIA, AMD & Intel“ (Mitteilung zum Start von SpeedCloud Global).

Als Dossier für eine öffentliche Beschaffung gelesen, zerfallen diese Aussagen sauber in vier Klassen. Es gibt eine Identitätsbehauptung: Es existiert eine bestimmte juristische Person, die in Indien operiert. Es gibt eine physische Behauptung: Es existieren fünf Rechenzentren, und mindestens eines davon steht in Bidadi. Es gibt eine Nachweisbehauptung: Drei benannte staatliche Programme haben das Unternehmen in ihre Lieferantenlisten aufgenommen. Und es gibt eine technische Behauptung: Ein heterogener Beschleunigerbestand über drei Siliziumhersteller ist in Betrieb. Jede dieser Behauptungen ist grundsätzlich prüfbar.

Nur einige sind es in der Akte, die am 17. Oktober 2026 tatsächlich beschafft werden konnte, und das Muster dessen, was prüfbar ist und was nicht, ist die nützlichste Information, die eine Gegenpartei aus diesem Unternehmen ziehen kann.

Was das Verzeichnis festhält und was nicht

Der Verzeichniseintrag, den BTW über das Unternehmen führt, ist bewusst schlank. Er hält die Entität als in Indien eingetragene Privatgesellschaft fest, mit einer auf Indien bezogenen Abdeckung von Rechenzentrums- und Colocation-Diensten, ohne verzeichnete Unternehmensbeziehungen, ohne verzeichnete Führungskontakte und mit genau einer verzeichneten Evidenzgrundlage, die auf den Nummernregistereintrag zu AS132717 verweist (BTW-Verzeichniseintrag). Das ist keine Kritik am Verzeichnis; es ist die exakte Formulierung dessen, was ein evidenzbasiertes Verzeichnis sagen kann, wenn die zugrunde liegenden öffentlichen Quellen entweder selbstveröffentlicht oder unzugänglich sind. Die Lückenhinweise des Verzeichnisses selbst verlangen die Prüfung des Landes der juristischen Person, der aktuellen Dienste, der sichtbaren Anlagen, der Mutter- und Tochterbeziehungen und der zuständigen öffentlichen Führungskontakte. Keine dieser Fragen wurde durch das hier versammelte Material beantwortet.

Die Konsequenz verdient es, ohne Umschweife benannt zu werden, weil sie im ganzen Bericht wiederkehrt. Die einzige Evidenzgrundlage des Verzeichnisses ist ein Nummernregister. Lässt sich dieses Register nicht lesen, dann sind der Verzeichniseintrag und die Website des Betreibers die einzigen beiden verfügbaren Beschreibungen des Unternehmens, und keine der beiden ist unabhängig vom Unternehmen. Ein Verzeichnis, das eine unerreichbare Quelle zitiert, hat nichts belegt; es hat eine Prüfungsabsicht notiert.

Die Netzwerkschicht, die nicht gelesen werden konnte

AS132717 ist die Achse. Eine autonome Systemnummer ist die Kennung, unter der ein Netz seine Erreichbarkeit gegenüber der globalen Routing-Tabelle bekanntgibt, und für einen Rechenzentrums- und Cloud-Betreiber ist sie die nächste Entsprechung einer öffentlichen Erklärung darüber, was das Unternehmen tatsächlich anbindet. Ein Satz registrierter Präfixe sagt einer Gegenpartei, über wie viel Adressraum der Betreiber verfügt und damit ungefähr, wie groß sein adressierbarer Bestand ist. Die Zahl der Transit-Anbieter sagt, wie viele unabhängige Transitbeziehungen die Kunden des Betreibers vom übrigen Internet trennen.

Die RPKI-Origin-Validierung sagt, ob diese Ankündigungen kryptografisch belegt oder lediglich behauptet sind. Nichts davon ist eine Marketingzahl; alles davon ist beobachtbar.

Am 17. Oktober 2026 war es hier nicht beobachtbar. Eine Abfrage beim allgemeinen Resolver https://rdap.org/autnum/132717 lieferte keinen verwertbaren Datensatz, und der erhaltene Schnappschuss enthält nur den Hinweis, dass der direkte Zugriff auf die technischen Registrierungs- und Routing-Datenbanken für AS132717 fehlschlug (rdap.org-Abfrage zu AS132717). Eine zweite Abfrage, diesmal am autoritativen RDAP-Endpunkt von APNIC, der den Eintrag für eine von APNIC zugewiesene Ressource enthalten sollte, scheiterte ebenfalls, sodass auch der registrierte Inhaber und die konkret mit AS132717 verbundenen IPv4- und IPv6-Präfixe aus dieser Quelle nicht bestätigt werden konnten (APNIC-RDAP-Abfrage zu AS132717).

Die Unterscheidung zwischen einem Beschaffungsfehler und einem Befund ist hier wichtiger als an jeder anderen Stelle dieses Berichts. Zwei gescheiterte Abfragen belegen nicht, dass NxtGen nichts ankündigt, dass sein Netz klein ist oder dass seine Routing-Hygiene schlecht wäre. Sie belegen, dass das Register an diesem Datum über diese beiden Kanäle nicht lesbar war. Wer daraus eine Aussage über den Betreiber macht, hat die Evidenz überdehnt, und zwar genau in der Form, gegen die dieser Bericht argumentiert. Sagbar ist etwas Engeres und dennoch Nützliches: Eine Gegenpartei, die das Netz von NxtGen am 17.

Oktober 2026 aus öffentlichen Quellen hätte dimensionieren wollen, hätte es nicht gekonnt und hätte entweder das Unternehmen direkt fragen oder ein kommerzielles Routing-Intelligence-Produkt einsetzen müssen.

Ein Standort mit Namen, vier ohne

Die physische Behauptung ist leichter zu formulieren und nur etwas leichter zu prüfen. Das Unternehmen erklärt, fünf Rechenzentren in Indien zu betreiben. Die erhaltene Akte benennt genau eines: Bidadi bei Bangalore, in der unternehmenseigenen Mitteilung beschrieben als „company's own datacenter“ (Mitteilung zum Start von SpeedCloud Global). Die anderen vier werden an keiner Stelle des beschafften Materials benannt, adressiert oder datiert.

Für ein Rechenzentrumsgeschäft ist das eine substanzielle Auslassung und kein Stilproblem. Die Ökonomie eines Standorts hängt an Daten, die nur ein Dossier auf Standortebene liefern kann: ob das Gebäude eigen oder gemietet ist, wann es in Betrieb ging, über welche vertraglich gesicherte Leistung es verfügt, ob es eine Stufen-Zertifizierung oder eine gleichwertige geprüfte Designprüfung besitzt und welche Netzbetreiber Präsenzpunkte darin haben. Eine Zahl von fünf ohne Adressen lässt sich nicht mit Eigentumsregistern, Anschlusswarteschlangen der Stromversorger, Baugenehmigungen oder Interconnection-Datenbanken abgleichen.

Ein benannter Standort lässt sich zumindest grundsätzlich abgleichen, und Bidadi ist ein reales, identifizierbares Industriegebiet bei Bangalore. Aber ein benannter Standort von fünf belegt die anderen vier nicht, und die Formulierung „company's own datacenter“ ist das Unternehmen, das seinen eigenen Besitz beschreibt, kein Eigentumsnachweis.

Ein Punkt zweiter Ordnung verdient Hervorhebung, weil er bestimmt, wie Behauptungen souveräner Kapazität üblicherweise gelesen werden. Einkäufer und öffentliche Stellen behandeln die Standortzahl oft als Resilienzindikator, mit der Begründung, fünf Standorte könnten nicht gleichzeitig ausfallen. Diese Begründung trägt nur, wenn die fünf Standorte getrennt mit Strom versorgt, getrennt angebunden und getrennt besetzt sind.

Eine Zahl mit einer einzigen Adresse erlaubt keine Unterscheidung zwischen einem tatsächlich verteilten Bestand und einer Hauptanlage, die um angemietete Fläche in Räumen Dritter ergänzt wurde, und diese beiden Konfigurationen haben sehr unterschiedliche Risikoprofile, wenn ein einzelner Einspeisepunkt oder ein einzelner Transit-Anbieter ausfällt.

Empanelment als Nachweis ohne Register

Die Nachweisbehauptung wiegt in der öffentlichen Beschaffung am schwersten und lässt sich am wenigsten öffentlich prüfen. Das Unternehmen erklärt, im MeitY Government Community Cloud, bei CERT-In und in der IndiaAI Mission empanelt zu sein (Mitteilung zum Start von SpeedCloud Global). Jede dieser Kategorien entspricht einer realen Lieferantenzulassung gegenüber dem indischen Staat, und jede wäre üblicherweise durch einen Eintrag auf einer Regierungsseite, eine Zuschlagsmitteilung oder eine veröffentlichte Empanelment-Verfügung belegt.

Ein solcher Eintrag war nicht auffindbar. Die unabhängige Berichterstattung, die in dem erhaltenen Schnappschuss zusammengefasst ist, beschreibt die GPU-Kapazität der IndiaAI Mission als unterausgelastet, mit langsamen Zuweisungsverfahren, langen Bereitstellungszeiträumen und finanziellen Einschränkungen für nutzende Unternehmen, und stellt fest, dass die verfügbaren öffentlichen Informationen keine abschließende staatlich veröffentlichte Liste empanelter Cloud-Diensteanbieter der IndiaAI Mission liefern und den Empanelment-Status einzelner Entitäten nicht bestätigen (Bericht zur GPU-Auslastung der IndiaAI).

Das ist ein präziser und gewichtiger Befund, der sorgfältig gelesen werden muss. Er sagt nicht, dass NxtGen nicht empanelt ist. Er sagt, dass das Empanelment aus der öffentlichen Akte nicht bestätigt werden kann, weil diese Akte kein Register enthält, gegen das es zu bestätigen wäre. Der Unterschied zwischen diesen beiden Sätzen trennt den Vorwurf von der Evidenzgrenze, und nur der zweite ist hier haltbar.

Das Argument zur Kontrollfläche folgt unmittelbar. Empanelment ist ein Tor, keine Messung. Es besagt, dass eine benannte Stelle einen Lieferanten in eine Liste aufgenommen hat, was eine Aussage über Verfahren und Zulässigkeit ist; es besagt nichts darüber, wie viele Beschleuniger dieser Lieferant installiert hat, wie viele öffentliche Arbeitslasten er tatsächlich bedient oder ob er eine bestimmte Arbeit im nächsten Quartal liefern kann. Ist das Tor veröffentlicht, kann der Einkäufer wenigstens die Aufnahme bestätigen.

Ist es das nicht, schrumpft der Nachweis auf die Erklärung des Lieferanten, und die Prüflast verlagert sich vollständig auf den Einkäufer, der die Aufnahme nun über direkten Kontakt zum Programmreferat prüfen muss. In einem Markt, dessen Hauptargument gerade darin besteht, dass der Lieferant innerhalb des Tores steht, macht ein unveröffentlichtes Tor das Argument unfalsifizierbar, und unfalsifizierbare Aussagen werden von versierten Einkäufern abgezinst und von weniger versierten zum Nennwert angenommen.

Die Behauptung heterogener Beschleuniger

Die technische Behauptung ist für Ingenieure die interessanteste und in der Akte die am wenigsten dokumentierte. Das Unternehmen erklärt, sein KI-Portfolio „unifies GPU platforms from NVIDIA, AMD & Intel“ (Mitteilung zum Start von SpeedCloud Global). Keine Beschleunigerzahl, keine Modellzusammensetzung, keine Rackdichte, keine Leistungsaufnahme in Megawatt, kein Inbetriebnahmedatum und kein Kundenvertrag begleiten diesen Satz im beschafften Material.

Wörtlich genommen beschreibt der Satz ein Ingenieursproblem, das schwieriger ist als ein Ein-Lieferanten-Bestand, und es lohnt, genau zu sein, warum. Drei Beschleunigerhersteller bedeuten mindestens drei Treiber- und Firmware-Stapel, mindestens drei Sätze von Speicherhierarchien und Interconnect-Topologien und mindestens drei Scheduling-Pfade, die eine Cloud-Kontrollfläche abstrahieren muss, damit ein Kunde eine Arbeitslast von einem zum anderen bewegen kann.

Sie bedeuten, dass ein auf dem Silizium eines Herstellers gemessener Benchmark nicht ohne Requalifizierung auf das eines anderen übertragbar ist, sodass eine Schlagzeilen-Leistungszahl nur pro Arbeitslast und pro Hersteller Sinn ergibt. Und sie bedeuten, dass Kapazitätsplanung zu einem kombinatorischen Problem wird, weil eine Aufgabe, die eine bestimmte Interconnect-Topologie verlangt, möglicherweise nur in einer der drei Familien ausführbar ist.

Nichts davon macht die Aussage falsch. Es macht sie zu einer Integrationsbehauptung, bevor sie eine Kapazitätsbehauptung ist, und Integrationsbehauptungen werden mit Dokumentation geprüft, nicht mit Beteuerungen: ein veröffentlichter Instanzkatalog, eine Support-Matrix für Treiber und Scheduler, eine Qualifizierungsnotiz pro Arbeitslast. Fehlen diese Artefakte, sagt der Satz dem Einkäufer, dass drei Herstellerbeziehungen bestehen, und nichts darüber, was ausgeführt werden kann, mit welcher Geschwindigkeit oder mit welcher Verfügbarkeit.

Für einen öffentlichen oder Unternehmenskäufer, dessen Arbeitslast an ein bestimmtes Framework gebunden ist, ist das der Unterschied zwischen einer brauchbaren Antwort und einer Pressemitteilung.

Souveränität als Beschaffungskategorie

Das Wort souverän leistet in der Positionierung dieses Unternehmens enorme Arbeit, und es lohnt, es zu zerlegen statt es zu verwerfen. In der Cloud-Beschaffung ruht der Souveränitätsstatus üblicherweise auf vier trennbaren Eigenschaften: der rechtlichen Jurisdiktion über die Daten, also welches nationale Recht Offenlegung erzwingen kann; der operativen Kontrolle, also wer die Plattform administrieren darf und unter wessen Weisung; dem physischen Standort, also wo die Anlage und ihre Versorgung liegen; und dem Netzpfad, also welche Infrastruktur den Verkehr transportiert und wo er Grenzen überquert.

Ein Anbieter kann einige dieser Eigenschaften besitzen und andere nicht, und Einkäufer verwechseln sie häufig.

Die vier Eigenschaften sind zudem hierarchisch voneinander abhängig, und das ist der hier entscheidende Teil. Operative Kontrolle lässt sich nicht beurteilen, ohne zu wissen, wer den Anbieter besitzt und leitet, und genau diese Frage beantwortet die Akte nicht: Es wurde kein Rundenbetrag, kein benannter Investor, keine Bewertung und keine Beteiligungsstruktur beschafft, und eine gezielte Abfrage zu Unternehmensbasisdaten lieferte keine Quelle. Der physische Standort lässt sich nicht ohne ein Standortdossier beurteilen, und nur einer von fünf ist benannt.

Der Netzpfad lässt sich nicht ohne das Routing-Dossier beurteilen, und beide Registerabfragen scheiterten. Die Jurisdiktion, die einzige Eigenschaft, die sich allein aus der Eintragung einer Gesellschaft klären lässt, ist die einzige, die dieser Bericht mit Vertrauen feststellen kann: Die Entität ist als indische Privatgesellschaft eingetragen.

Das Ergebnis ist unbequem für eine Kategorie, deren gesamter Geschäftswert auf der Aussage ruht, ein Einkäufer wisse, wo seine Daten und seine Kontrollfläche liegen. Ein souveräner Cloud-Anbieter, der sich nicht unabhängig in der Kontrollstruktur seiner eigenen Jurisdiktion, an seinen eigenen Standorten und über sein eigenes Netz verorten lässt, bietet ein jurisdiktionelles Etikett statt einer prüfbaren Architektur. Das Etikett kann zutreffen. Aber ein Einkäufer, der seine Wahl gegenüber einer Aufsicht, einem Prüfer oder einem parlamentarischen Ausschuss verteidigen muss, kann ein Etikett nicht als Beweis verwenden.

Was sich bepreisen lässt und was nicht

Trennt man die Schichten, ergibt sich eine kurze und brauchbare Bilanz. Belegt: Das Unternehmen existiert als Privatgesellschaft in Indien, mit Abdeckung von Rechenzentrums- und Colocation-Diensten, und ein Standort in Bidadi bei Bangalore wird in seiner eigenen Mitteilung benannt. Erklärt, aber nicht unabhängig bestätigt: die Zahl von fünf Rechenzentren, die Kundenangabe über tausend, die drei Empanelments und das Multi-Vendor-Beschleunigerportfolio. Am Datum der Akte nicht beschaffbar: die registrierten Präfixe, die Zahl der Transit-Anbieter und der RPKI-Status von AS132717.

Überhaupt nicht festgestellt: Eigentum, Aktionariat, Finanzierung, Beschleunigerbestand und Inbetriebnahmedaten.

Für einen Einkäufer folgt aus dieser Bilanz eine konkrete Sorgfaltssequenz und kein Urteil. Den APNIC-Eintrag und die aktuelle Präfixliste anfordern und gegen einen kommerziellen Routing-Feed halten. Die Adressen der anderen vier Standorte und die Strom- und Konnektivitätsverträge anfordern, die sie tragen. Die Aktenzeichen der Empanelment-Verfügungen und das ausstellende Referat anfordern und sie direkt mit diesem Referat bestätigen. Die Stückliste der Beschleuniger und eine Qualifizierungsnotiz pro Arbeitslast für das Framework anfordern, das der Einkäufer tatsächlich ausführt.

Jede dieser Anforderungen ist von einem Betreiber beantwortbar, der die erklärte Kapazität tatsächlich besitzt, und jede bleibt bei einem Betreiber unbeantwortet, der sie nicht besitzt. Der Wert der Sequenz liegt darin, eine kaufmännische Aussage in eine Menge von Dokumenten zu überführen, deren Fehlen selbst informativ ist.

Für einen Investor oder eine Gegenpartei, die das Unternehmen als Geschäft und nicht als Lieferanten bewertet, ist die Lücke anders, aber verwandt. Die Verteidigungsfähigkeit eines Cloud-Betreibers ruht auf Kapitalintensität und Auslastung: wie viel in Standorte und Silizium geflossen ist und wie viel dieser Ausgaben Erlös erzeugt. Keine der beiden Zahlen ist hier verfügbar.

Das Fehlen eines Finanzierungsdossiers ist in einem Markt, in dem souveräne KI-Kapazität in großem Maßstab finanziert wird, besonders unangenehm, weil es die Frage offen lässt, ob der Bestand mit Eigenkapital, mit vertraglich besicherter Schuld oder mit öffentlichen Abnahmeverpflichtungen errichtet wurde. Diese drei Finanzierungsstrukturen versagen auf sehr verschiedene Weise, und eine Gegenpartei kann das Versagensmuster nicht bepreisen, ohne zu wissen, welches zutrifft.

Warum die Lücke die Geschichte ist

Es wäre leicht, diesen Bericht als Anklage gegen ein Unternehmen zu lesen. Das verfehlte den allgemeineren Punkt. Der Grund, warum ein Cloud-Betreiber fünf Rechenzentren, drei Empanelments und einen Multi-Vendor-GPU-Bestand veröffentlichen kann, ohne dass irgendetwas davon prüfbar wäre, ist, dass die Prüfinfrastruktur rund um souveräne KI-Kapazität dünner ist als die Kapazitätsbehauptungen selbst. Nummernregister sind autoritativ, waren aber an diesem Datum über zwei verschiedene Kanäle unzugänglich. Empanelment-Listen existieren als Verwaltungsartefakte, werden aber nicht konsistent veröffentlicht.

Standortdossiers sind private Geschäftsdokumente. Beschleunigerbestände werden fast nie offengelegt. Jede dieser Lücken ist einzeln verteidigbar; zusammen bedeuten sie, dass die öffentliche Akte keine Unterscheidung erlaubt zwischen einem Betreiber, der gebaut hat, was er sagt, und einem, der es nur angekündigt hat.

Das ist ein Problem der Marktstruktur und nicht das einer einzelnen Firma. In einem Sektor, in dem Staaten öffentliche Mittel für heimische Rechenkapazität auf der Grundlage von Lieferantenerklärungen binden, bildet das Fehlen eines veröffentlichten Empanelment-Registers eine Rechenschaftslücke mit präziser Form: Die am besten positionierte Stelle zur Prüfung der Aufnahme ist das Programmreferat, die am wenigsten dazu fähige ist der Einkäufer, und die am stärksten zu Übertreibung geneigte ist der Lieferant.

Die Berichterstattung über die Unterauslastung der IndiaAI Mission deutet darauf hin, dass die Folgen bereits makroskopisch sichtbar sind, wo als verfügbar gezählte Kapazität nicht verbraucht wird. Ob der konkrete Bestand von NxtGen zu diesem Muster gehört, lässt sich aus dieser Akte nicht bestimmen, und dieser Bericht behauptet es nicht.

Quellen und Evidenzgrenzen

Die Fakten dieses Berichts stammen aus fünf erhaltenen Quellen, jede datiert. Die Selbstbeschreibung des Betreibers steht in NxtGen. Der Standortname, die Empanelment-Behauptungen, die Kundenzahl und das Beschleunigerportfolio stehen in einer vom Unternehmen herausgegebenen Mitteilung, der Mitteilung zum Start von SpeedCloud Global. Die beiden Registerfehlschläge sind in der rdap.org-Abfrage zu AS132717 und in der APNIC-RDAP-Abfrage zu AS132717 vermerkt. Der unabhängige Kontext zur Auslastung der IndiaAI Mission und zum Fehlen eines veröffentlichten Empanelment-Registers steht im Bericht zur GPU-Auslastung der IndiaAI. Der Verzeichniseintrag steht im BTW-Verzeichniseintrag.

Fünf Grenzen muss jeder Leser, der diesen Bericht nutzt, mittragen. Die Registergrenze: Registrierung, Präfixsatz, Zahl der Transit-Anbieter und RPKI-Origin-Status von AS132717 wurden nicht festgestellt, und die beiden Fehlschläge waren Zugriffsfehler, keine negativen Ergebnisse. Die Empanelment-Grenze: Eine veröffentlichte staatliche Liste empanelter Anbieter im MeitY Government Community Cloud, bei CERT-In oder in der IndiaAI Mission war nicht auffindbar, weshalb die Empanelment-Behauptungen als Behauptungen vermerkt bleiben.

Die Kapazitätsgrenze: Es wurde keine Beschleunigerzahl, Modellzusammensetzung, Rackdichte, Leistungsaufnahme in Megawatt, kein Inbetriebnahmedatum und kein Kundenvertrag gefunden. Die Eigentumsgrenze: Es wurde kein Rundenbetrag, kein Investor, keine Bewertung und keine Beteiligungsstruktur beschafft. Und die Standortgrenze: Nur einer der fünf behaupteten Standorte ist in einer erhaltenen Quelle benannt. Jede Grenze ist auf den 17. Oktober 2026 datiert, und jede würde durch ein einziges Dokument der oben bezeichneten Art geschlossen. Das ist die konstruktive Lesart eines Berichts, der ansonsten Abwesenheiten dokumentiert.