Cygnus · geplante ErstversionGeplant: v1Cygnus 1.0 ist ein geplantes, an Abnahmekriterien gebundenes Release einer programmierbaren temporalen Graphdatenbank. Der folgende Umfang ist ein Design- und Qualifizierungsplan; kein Release-Kriterium und kein Leistungsziel wird als erreicht dargestellt.
Status: Cygnus 1.0 ist weder abgenommen noch veröffentlicht. Nachweise zu enthaltenen Fähigkeiten, Sicherheit, Dokumentation, Kompatibilität, Deployment und Wiederherstellung müssen vor einem öffentlichen Release vollständig bestanden sein.
Das geplante Release vereint Sprache, Laufzeitumgebung, Speicherung und Dienste unter einem semantischen Modell. Eine Kandidatenimplementierung ist kein öffentliches Release.
Typisierte Sprache und Ausführung, transaktionale Graph- und Zeitreihenspeicherung, Authentifizierung und Autorisierung im Speicherpfad, typisierte HTTP/RPC- und Streaming-Dienste, generierter TypeScript-Client, API- und MCP-Deskriptoren.
Die sieben unten beschriebenen, begrenzten Modalitätsprofile, Graph-Traversierung, Geodatenindizierung, Text/BM25 und Sparse/Dense-Retrieval, Zeitfenster, Rollups und dauerhafte Abonnements.
Eine ausgewählte Explorer-Oberfläche, fünf festgelegte Anwendungsmuster für Zwillinge, Telemetrie, Ereignisprotokolle, Geo-Tracks und Ressourcen-CRUD; LSP-Kern, VS-Code-Client und begrenztes Headless-Debugging.
Dauerhafte Jobs und Zeitpläne, Beobachtbarkeit auf einem Server, Backup, Point-in-Time-Recovery und geprüfte Wiederherstellung; ein begrenzter Chat-Vertrag mit Anbieterqualifizierung auf exakt festgelegte Versionen und unabhängig kontrollierter Fehlerbehebung.
Reihenfolge der Abhängigkeiten: Kern → Dienstverträge und Sicherheit → zeitliche, räumliche und Retrieval-Daten → ausgewählter Explorer und Agenten-Tools → Single-Server-Betrieb und begrenzter Chat. Daten und sichere Dienste kommen vor der größeren Agenten-Schnittstelle.
Dies sind geplante Anforderungen an die Erstversion mit eigenen Konformitäts- und Sicherheitskriterien – keine Aussage, dass jede Schnittstelle heute verfügbar ist.
Typisierte HTTP/RPC- und Streaming-Operationen, Change-Feeds, generierte TypeScript-Clients und versionierte Dienstbeschreibungen für die Nutzung über API und MCP. Ein Blob-basierter verwalteter Dateidienst würde transaktionale virtuelle Verzeichnisse und begrenzte Übertragung bieten – ohne implizites Parsen oder Zugriff auf das Host-Dateisystem.
Eine eigene Entscheidungs- und Freigabe-Warteschlange würde maßgebliche menschliche Entscheidungen über eine Agentensitzung hinaus festhalten. Der Vorschlag eines Agenten und seine Belege bleiben von der Berechtigung getrennt, ihn zu aktivieren.
Die native Grundausstattung umfasst Sprach-Tags, Darstellungskontext, typisierte Nachrichten- und Katalogidentität sowie begrenzte Formatierung. Server und generierte TypeScript-Clients müssen sich auf fest versionierte Kataloge einigen; konkrete Produktiv-Locales und Supportzeiträume sind noch offen.
Der ausgewählte authentifizierte Explorer umfasst Übersicht, Daten/Graph, Aktivität/Logs, Funktionen/API/MCP, Zugriff sowie die qualifizierte Einrichtung von Chat und Anbietern. Seine Lokalisierung muss Prüfungen zu typisierten Argumenten, RTL, Pseudo-Locale, Barrierefreiheit, feindseligen Übersetzungen und Server-Client-Parität bestehen. LSP-Kern, schlanker VS-Code-Client und der Vertrag für begrenztes Headless-Debugging sind Pflicht; eine Integration des Debug Adapter Protocol im Editor ist zurückgestellt.
Die fünf festgelegten Anwendungsmuster sind Zwillingsentität, Telemetriereihe, Ereignisprotokoll, Geo-Track und Ressourcen-CRUD. Ein allgemeines deklaratives UI-System oder eine Sprachlaufzeit im Browser ist nicht Teil dieser Erstversion.
Dies sind Architekturanforderungen an das geplante Release, vorbehaltlich der Konformitäts- und Sicherheitsqualifizierung.
Bitemporaler Zugriff unterscheidet die Gültigkeitszeit eines Fakts von dem Zeitpunkt, zu dem er ins System gelangte. Eine As-of-Antwort sollte gegen beide reproduzierbar sein, einschließlich späterer Korrekturen.
Strikt serialisierbare Transaktionen mit feingranularer logischer Konflikterkennung sollen Änderungen an Entitäten, Graph, Zeit und deklarierten transaktionalen Indizes oder abgeleiteten Ressourcen in einer Commit-Epoche halten.
Zugriffsprüfungen gehören in die Speicher- und Ausführungspfade, einschließlich Index-Scans, Traversierungen und Aggregaten. Auffinden ist vom Lesezugriff getrennt; verweigerte Ressourcen dürfen weder über Zählungen noch über Fehler oder Existenzhinweise durchsickern. Die Autorisierung der Suche erfolgt vor Ranking und Top-k-Auswahl.
Ein deklarierter öffentlicher Funktionseffekt beschreibt mögliches Verhalten; er erteilt nie selbst eine Berechtigung. Abgerufene Inhalte und Modellausgaben bleiben nicht vertrauenswürdig, wenn ein Agent eine Tool-Aktion vorschlägt.
Gespeicherte Quellen behalten begrenzten Zugriff, versionierte Deskriptoren, Klassifizierung, Herkunft, Aufbewahrung und Autorisierung. Abgeleitete Texte, Kacheln oder Embeddings sind explizit versioniert und werden nie stillschweigend zum Original.
| Modalität | Geplante Darstellung in der Erstversion | Außerhalb der Aussage zur Erstversion |
|---|---|---|
| Text | Begrenzte UTF-8-Strings; große UTF-8-Inhalte als gestreamte oder bereichsweise gelesene Blobs; Text/BM25-Index mit versioniertem Analyzer. | Universelle Zeichensatzreparatur, quellverändernde implizite Normalisierung oder unbegrenzte String-Materialisierung. |
| Dokumente | Maßgebliche Quellbytes mit Metadaten und Herkunft; explizite Text- und Chunk-Ableitungen können geliefert oder von einem deklarierten externen Anbieter erzeugt werden. | Universelles PDF-/Office-Parsing, stilles OCR oder die Behandlung extrahierten Texts als Quelle. |
| Bild, Audio und Video | Quellbytes, Medienmetadaten und Digest; fortsetzbare, begrenzte Aufnahme, bereichsweises Streaming und explizit versionierte externe Ableitungen. | Mitgelieferte Decoder/Transcoder, native Video-Pipeline, Vorschaubilder, Frame-Extraktion oder inhärente Medienähnlichkeit. |
| Zeitreihenzustand | Punkt-, Batch- und Bereichszugriff, reguläre/irreguläre Ausdehnungen und exakte Auflösung; später in der enthaltenen Lieferabfolge Ereigniszeitfenster, Watermarks, Rollups und dauerhafte Abonnements. | Mehrere unabhängige Ereignisse zum selben Zeitpunkt in einer einzigen Reihe; dafür eine Event-Map verwenden. |
| Vektor-GIS | CRS-bewusste Geowerte/-Features, bei Bedarf gestreamte große Geometrien, exakte Prädikate und indizierte Kandidaten mit exakter Nachprüfung. | Verteilte räumliche Ausführung oder eine allgemeine PostGIS-kompatible Ausweichsprache. |
| Raster-GIS | Quellbytes mit Rasterdeskriptor, begrenzter Byte-/Bereichszugriff und deklarierte externe Kachel- oder Übersichtsprojektionen. | Mitgelieferte Rasterdekodierung, native Reprojektion/Übersichtserstellung oder garantierter wahlfreier Kachelzugriff aus sequenziellen Formaten. |
| Dichte und dünnbesetzte numerische Daten | Begrenzte Arrays und dünnbesetzte Arrays; minimale Float-Tensor-Speicherung mit fester Form für von Anbietern erzeugte Embeddings. | Allgemeine Tensor-Algebra, Modellausführung, ONNX, Training, Quantisierung oder Berechnung auf Beschleunigern. |
Konkrete Austauschformate, akzeptierte Dokument-/Medientypen, Vektor- und Rasterprofile, Anbieterversionen und Sicherheits-Fixtures bleiben Release-Entscheidungen.
Die geplante Produktivtopologie ist ein Server. Er kann Mandanten mit Isolation und Kontingenten beherbergen, doch Kapazität und Fehlerdomäne bleiben ein Knoten.
| Profil | Geplante Einordnung in der Erstversion | Abgrenzung |
|---|---|---|
| Embedded | Enthalten | Ein Anwendungsprozess mit lokalem Speicher; kein separater Serverprozess. |
| Entwicklung | Enthalten | Bootstrap leerer Projekte und explizite Quellmodi. |
| Produktivbetrieb, ein Server | Enthalten | Ein Knoten. Zuerst POSIX-Dauerhaftigkeit; Dauerhaftigkeit auf Objektspeicher und Backup-Unterstützung im Release-Umfang. |
| Cluster | Nicht enthalten · späteres Profil | Keine Aussage zu Sharding, Replikation, verteilter Traversierung oder Failover. |
| Isolierte Workloads | Nicht enthalten | Kein separat qualifiziertes Deployment-Profil für isolierte Workloads. |
Entscheidungen zur Betriebsumgebung, etwa ein Kundenrechenzentrum oder eine Private Cloud, sind von diesen Laufzeitprofilen getrennt.
Das geplante Produktivprofil verbindet dauerhafte Jobs und Zeitpläne mit Betriebsnachweisen auf einem Server. Es macht keine Aussage zu Clustern, Replikat-Failover oder knotenübergreifender Verfügbarkeit.
Vollständige und inkrementelle geplante Backups, geprüfte Wiederherstellung und Point-in-Time-Recovery, Aufbewahrung/TTL und Legal Holds sind enthaltene Anforderungen. Ein abgeschlossenes Backup belegt nicht, dass eine Anwendung und ihre Daten wiederhergestellt werden können.
Produktive Beobachtbarkeit und deklarierte Serviceziele würden Vorfälle mit der betroffenen Anwendung und dem betroffenen Release verknüpfen. Nur registrierte, vorab autorisierte Klassen der Fehlerbehebung dürfen innerhalb ihres begrenzten Profils handeln; veraltete oder widerrufene Befugnisse müssen ablehnen oder eskalieren.
Entscheidungen zu Canary und Rollback bleiben unter unabhängiger Kontrolle. Der Agent, der eine Reparatur vorschlägt, kann weder die Erweiterung seiner eigenen Befugnisse freigeben noch seine Abnahmekriterien ändern oder seinen Nachfolger aktivieren.
Rollierende Deployments von Schemas, Verträgen und Backend sind für das Single-Server-Profil geplant. Eine stabile native C-ABI und eine überwachte Anbietergrenze ermöglichen deklarierte Integrationen, ohne die spätere offene Registry oder den Komponenten-Host hinzuzufügen.
Die Release-Qualifizierung erfordert außerdem Crash-Recovery, null Verluste bestätigter Commits und erfolgreiche Wiederherstellungstests unter deklarierten Bedingungen. Die vorgeschlagenen numerischen Schwellenwerte erscheinen unten als Tests, nicht als gemessene Ergebnisse oder Service-Level.
Dies sind vorgeschlagene Workload-Annahmen, die noch von den Autoren bestätigt und von Designpartnern gemessen werden müssen. „Weltweit“ beschreibt den Gegenstand, nicht eine verteilte Ausführung.
| Dimension | Vorgeschlagene Referenz-Workload |
|---|---|
| Zwillingsentitäten | 250.000 Schiffe; 5.000 Häfen und Terminals; 2 Millionen Ladungseinheiten |
| Positionsaufnahme | 25.000 Meldungen/s dauerhaft; 100.000 Meldungen/s für einen 60-Sekunden-Burst |
| Aufbewahrung in voller Auflösung | 90 Tage; rund 194 Milliarden Messpunkte und 2 TB komprimiert |
| Aufbewahrung mit reduzierter Auflösung | Ein Messpunkt pro 5 Minuten über 36 Monate; rund 79 Milliarden Messpunkte und 0,8 TB |
| Ereignisse und Dokumente | 5 Millionen Hafenanläufe, Meldungen und Manifeste pro Jahr |
| Embeddings | 768 float32-Dimensionen; rund 15 GB/Jahr unkomprimiert |
| Graphstruktur | Eigentums-, Charter- und Betreiberpfade bis Tiefe 6; mittlerer Ausgangsgrad 4; Hafenknoten mit bis zu 100.000 Kanten |
| Interaktive Parallelität | 200 Personen und 50 maschinelle Clients |
| Hardware und Speicher | Vorgeschlagene Referenz-Hardwareklasse mit 32 vCPU; Verhältnis von Datensatz zu RAM rund 24:1. RAM, Hersteller und Speichermodell sind nicht festgelegt. |
Der Wert von 25.000 Meldungen/s dauerhaft beschreibt diese Referenz-Workload. Der Wert von 100.000 Meldungen/s dauerhaft in den Abnahmekriterien ist ein strengeres vorgeschlagenes Release-Kriterium; 80.000 Meldungen/s auf dieser Hardware sind eine separate Schwelle für eine Neubewertung des Umfangs.
Eine theoretische Designrechnung mit rund 10,3 komprimierten Bytes pro Messpunkt ergibt etwa 1–2 Billionen Messpunkte und bis zu 20 TiB pro Knoten. Das ist kein gemessenes Kapazitätsergebnis.
≈10,3 Bytes
komprimiert pro Messpunkt: die Grundlage der Designrechnung
1–2 Billionen
Messpunkte pro Knoten, grob geschätzt in theoretischer Designrechnung
≤20 TiB
pro Knoten bei dieser Dichte; kein gemessenes Kapazitätsergebnis
10 TiB / 16 GiB
ein separater vorgeschlagener Qualifizierungsfall: Speicher im Verhältnis zum installierten RAM
Ein separater vorgeschlagener Qualifizierungsfall nutzt 10 TiB Speicher mit 16 GiB installiertem RAM für begrenzte Punkt-, Bereichs-, Seiten-, Stichproben- und Viewport-Abfragen. Das bedeutet weder, dass der Datenbestand oder ein ganzer Index im Arbeitsspeicher liegt, noch, dass jede globale Abfrage interaktiv ist.
Beim strengeren Release-Kriterium von 100.000 Meldungen/s ergäben 90 Tage Messpunkte in voller Auflösung rund 0,78 Billionen Messpunkte und 8 TB. Zwölf Monate wären rund 3,2 Billionen und 32 TB – jenseits des vorgeschlagenen Designschwerpunkts für einen Knoten. Längere Aufbewahrung erfordert reduzierte Auflösung oder ein späteres Cluster-Profil. Vollständiger Export, globale Sortierung und der Neuaufbau eines ganzen Index bleiben Aufgaben für Streaming oder dauerhafte Jobs.
Vor 1.0 gilt nur: Stabile vergebene Kennungen werden nie umgewidmet. Alle anderen Zusagen für 1.x sind Release-Absichten, und mehrere Details sind noch nicht entschieden.
| Dimension | Vor 1.0 | Beabsichtigtes Verhalten in 1.x oder offene Entscheidung |
|---|---|---|
| Quellsprache | Vor 1.0 keine Kompatibilitätszusage für 1.x. | Die Grammatik von 1.0 ist eingefroren; von 1.0 akzeptierter Quellcode wird auch von späteren 1.x-Versionen akzeptiert. |
| Deskriptoren und Katalog | Stabile Typ-, Feld- und andere vergebene IDs werden nie umgewidmet. | Eine spätere 1.x-Version liest Deskriptoren, die von früheren 1.x-Releases geschrieben wurden. |
| Bytecode und Pläne | Keine allgemeine Kompatibilitätszusage. | Physische Pläne werden beim Upgrade neu aufgebaut. Dauerhafte Jobs fixieren eine Ausführungsreferenz; eine neuere Laufzeitumgebung liest, migriert, spielt explizit neu ab oder lehnt ab. Beliebige Checkpoints sind nicht portabel. |
| Speicher: Dekodierung | Keine allgemeine Kompatibilitätszusage. | Spätere Releases behalten Decoder für noch referenzierte 1.x-Blöcke. |
| Speicher: Schreiben | Keine allgemeine Kompatibilitätszusage. | Rückwärtslesen wird je Format deklariert. Ein Downgrade wird nicht zugesagt. |
| Wire-Protokoll und API | Keine allgemeine Kompatibilitätszusage. | Innerhalb von 1.x nur additiv; inkompatible Änderungen erfordern eine neue Hauptversion des Dienstes. |
| Generierter Client | Keine allgemeine Kompatibilitätszusage. | Ein für 1.x generierter Client kompiliert gegen spätere 1.x-Server. |
| Deklaratives Frontend | Keine allgemeine Kompatibilitätszusage. | Deskriptorarten kommen innerhalb von 1.x nur additiv hinzu. |
| Pakete und Komponenten | Keine allgemeine Kompatibilitätszusage. | Aufbewahrte Decoder, Locks und ausgewählte native Anbieterschnittstellen kommen kompatibel hinzu. Eine offene Registry und ein Komponenten-Host sind spätere Arbeit. |
| Rollierendes Cluster-Upgrade | Nicht anwendbar. | Nicht anwendbar: kein Cluster-Profil in 1.0. |
| Backup und Wiederherstellung | Keine allgemeine Kompatibilitätszusage. | Eine spätere 1.x-Version stellt Backups früherer 1.x-Versionen wieder her und meldet ein verifiziertes Wiederherstellungsergebnis. |
| Betriebskonfiguration | Keine allgemeine Kompatibilitätszusage. | Innerhalb von 1.x nur additiv; ein Entfernen erfordert ein Deprecation-Release. |
| KI-Anbieteradapter | Keine allgemeine Kompatibilitätszusage. | Das portable Chat-Schema und das Worker-Protokoll kommen kompatibel hinzu. Konkrete Anbieterartefakte fixieren ihre eigenen Versionen, Richtungen und Fähigkeiten. Kein Modell und keine Funktion eines Herstellers wird impliziert. |
| Agenten- und MCP-Arbeitsbereich | Supportzeitraum noch auszuwählen. | Versionsrichtungen, Aushandlung und Fehlerverhalten erfordern eine Release-Entscheidung. |
| Agentensitzung und Anleitung | Supportzeitraum noch auszuwählen. | Versionsrichtungen und Checkpoint-Verhalten erfordern eine Release-Entscheidung. |
| Versionierter KI-Skill | Supportzeitraum noch auszuwählen. | Beide Richtungen und das Fehlerverhalten erfordern eine Release-Entscheidung. |
| Öffentliche Funktionseffekte | Keine allgemeine Kompatibilitätszusage. | Das Hinzufügen eines Effekts bricht den öffentlichen Funktionsvertrag und erfordert eine neue Hauptversion des Dienstes; es erteilt nie selbst eine Befugnis. |
| Konsistenz-Token | Supportzeitraum noch auszuwählen. | Das Token gehört zum Dienstumfang der Erstversion; sein Kompatibilitätsvertrag erfordert eine Release-Entscheidung. |
| Lokalisierte Nachrichten und Kataloge | Stabile Nachrichten-, Katalog- und Profil-IDs werden nie umgewidmet. | Öffentliche Schlüssel und typisierte Argumente kommen kompatibel hinzu; referenzierte Nachrichten bleiben lesbar. Locales, Standardwerte und Supportzeiträume der Kataloge sind noch offen. |
Die Release-Supportmatrix muss für jede Zeile Lese- und Schreibrichtung, unterstützte Zeiträume, Aushandlung und Fehlerverhalten festlegen. Eine Garantie für Downgrades oder die Portabilität beliebiger Checkpoints wird nicht impliziert.
Der geplante anbieterneutrale Chat-Vertrag umfasst Inhalte, Nachrichten, Ereignisse, Tools, strukturierte Ausgabe und dauerhafte Sitzungs- und Laufprotokolle. Modellspezifische Fähigkeiten werden nie von einem generischen Endpunktnamen abgeleitet.
| Geplante Anbindung in der Erstversion | Qualifizierungsgrenze |
|---|---|
| Deterministischer Fake-Anbieter | Erforderlich für reproduzierbare Tests. |
| OpenAI Responses (direkt) | Ein konkretes Anbieterartefakt und eine fest versionierte Fähigkeits-/Vertragsmatrix; kein Herstellermodell wird zugesagt. |
| Anthropic Messages | Ein konkretes Anbieterartefakt und eine fest versionierte Fähigkeits-/Vertragsmatrix. |
| Natives Ollama | Qualifiziert gegen seinen nativen Vertrag, nicht gegen seine OpenAI-kompatible Schnittstelle. |
| Begrenzter OpenAI-kompatibler Endpunkt | Typisierte Endpunktanbindung mit geprüften Fähigkeiten; sie gibt nicht vor, OpenAI zu sein. |
| Extern verwaltete, ko-residente Laufzeitumgebung | Nur begrenzte Ressourcenansprüche des Cygnus-Clients; die externe Laufzeitumgebung zählt nicht zur Reserve von Cygnus. |
| Zertifiziertes, von Cygnus verwaltetes lokales llama.cpp | CPU-Variante erforderlich; CUDA nur nach Qualifizierung. Exaktes Modell, Tokenizer, Laufzeitumgebung, Gerät, Konfiguration und Ressourcenrahmen erfordern ein signiertes Zertifikat. |
Entfernte oder unabhängig betriebene lokale Endpunkte erben keine RAM-/VRAM-Garantien des verwalteten lokalen Betriebs. Native Modellberechnung, breite anbieternative Agenten, automatisches Fallback und unbegrenzte KI-Nutzung liegen außerhalb dieses Profils. Anbieter- und Produktnamen bezeichnen ausschließlich Schnittstellen; sie implizieren keine Partnerschaft oder Empfehlung.
Keines der folgenden Kriterien gilt als bestanden. Die Werte gelten für deklarierte Bedingungen zu Workload, Hardware und Konsistenz; Muss- und Soll-Kriterien bleiben getrennt: 22 Kriterien müssen bestanden werden, 2 sollten bestanden werden.
| Kriterium · erforderlicher Nachweis | Vorgeschlagener Schwellenwert | Anforderung · Status |
|---|---|---|
| 01 Designpartner im Produktivbetrieb mit einer Workload nach Art der Referenz | Mindestens 3 | Muss bestanden werdenNoch nicht bestanden |
| 02 Produktives führendes System mit aufbewahrter Historie | Mindestens 1 mit mindestens 6 Monaten Historie | Muss bestanden werdenNoch nicht bestanden |
| 03 Dauerhafte Positionsaufnahme auf der vorgeschlagenen Referenz-Hardwareklasse mit 32 vCPU, bei transaktionaler Indexkonsistenz | Mindestens 100.000 Meldungen/s | Muss bestanden werdenNoch nicht bestanden |
| 04 Aufnahme von Lastspitzen ohne Verwerfen und ohne unbegrenztes Wachstum der Warteschlange | 100.000 Meldungen/s für 60 Sekunden | Muss bestanden werdenNoch nicht bestanden |
| 05 Schiffe innerhalb eines Polygons bei 250.000 Live-Positionen | p99 höchstens 150 ms | Muss bestanden werdenNoch nicht bestanden |
| 06 Lesen der 90-tägigen Route eines einzelnen Schiffs | p99 höchstens 250 ms | Muss bestanden werdenNoch nicht bestanden |
| 07 Hybrides Sparse- und Dense-Top-20-Retrieval über 5 Millionen Dokumente | p99 höchstens 300 ms | Muss bestanden werdenNoch nicht bestanden |
| 08 Lesen der Zwillingsnachbarschaft, Tiefe 3 und höchstens 500 Knoten | p99 höchstens 50 ms | Sollte bestanden werdenNoch nicht bestanden |
| 09 Korrektheit bei Out-of-Core-Betrieb ohne unbegrenztes Speicherwachstum | Datensatz mindestens 24-mal so groß wie der RAM | Muss bestanden werdenNoch nicht bestanden |
| 10 Mehraufwand der Autorisierung auf Elementebene gegenüber grobgranularer Richtlinie | Höchstens das 2-Fache | Muss bestanden werdenNoch nicht bestanden |
| 11 Wiederherstellungspunkt bestätigter Commits auf einem Server | Null verlorene bestätigte Commits | Muss bestanden werdenNoch nicht bestanden |
| 12 Neustart mit einem Datensatz von 3 TiB | Maßgebliche Schreibvorgänge laufen innerhalb von 20 Sekunden wieder | Muss bestanden werdenNoch nicht bestanden |
| 13 Geplante Tests der geprüften Wiederherstellung im Release-Zeitfenster | 100 % bestanden | Muss bestanden werdenNoch nicht bestanden |
| 14 Crash-Recovery bei jedem Commit-Schritt | 100 % der Tests bestanden | Muss bestanden werdenNoch nicht bestanden |
| 15 Agenten-Evaluierungen leerer Projekte ohne menschliche Nachbesserung | Mindestens 70 % erfolgreich innerhalb deklarierter Budgets | Muss bestanden werdenNoch nicht bestanden |
| 16 Vom leeren Projekt zur bereitgestellten, autorisierten Lese-/Schreibfunktion für einen Zwilling mit generiertem TypeScript-Client und Formular | Höchstens 30 Minuten, agentengesteuert | Sollte bestanden werdenNoch nicht bestanden |
| 17 Verpflichtende Konformitäts-Testsuiten für jedes enthaltene Profil | 100 % bestanden | Muss bestanden werdenNoch nicht bestanden |
| 18 Eingefrorene Spezifikationen und minimale Konformitäts-Testsuiten | Kernsubstrat, stabile Identitätsdeskriptoren sowie Bedrohungs- und Sicherheitskern; Modalitätsdeskriptoren, Sprache, Projekt, Zwischendarstellung, Pläne, Schema, Speicherung, Transaktionen, Streams, Paket-Lock, Lokalisierung und Kernwerkzeuge; Dienste, MCP, Features, UI, generiertes TypeScript, Deployment-Bundles, Change-Feeds und vollständige Sicherheit; Suche und Ereigniszeit; geführtes MCP, eingefrorene Feature-Projektion, Explorer-Lokalisierung, LSP und Headless-Debugging; Single-Server-Betrieb, native Anbieterschnittstelle und begrenzter Chat. Das Bedrohungsmodell wird bei jedem enthaltenen Kriterium neu überprüft. | Muss bestanden werdenNoch nicht bestanden |
| 19 Dokumentationsbeispiele laufen als Tests | 100% | Muss bestanden werdenNoch nicht bestanden |
| 20 Baselines für Performance-Regressionen mit Verantwortlichen | Jeder Benchmark im Hot Path | Muss bestanden werdenNoch nicht bestanden |
| 21 Vollständige Support- und Kompatibilitätsmatrix | Konkrete Formate, Dokument-/Medien-/Raster-/Anbieterprofile, Locales und Kataloge ausgewählt; alle 19 Dimensionen legen beide Richtungen, Zeiträume, Aushandlung und Fehlerverhalten fest; keine offenen Zellen | Muss bestanden werdenNoch nicht bestanden |
| 22 Produktive Identität und kryptografische Aktivierung | Qualifizierter externer Schlüsselanbieter und auditierte Zeremonie für den ersten Administrator; kein Rückfall auf Entwicklungs- oder Datei-Anbieter | Muss bestanden werdenNoch nicht bestanden |
| 22 Offenlegung von Sicherheitslücken und Release-Betrieb | Überwachter Kontakt, öffentlicher Verschlüsselungsschlüssel, security.txt, Weg für Sicherheitshinweise, Supportkalender und erprobte Rollen für Release und Rollback | Muss bestanden werdenNoch nicht bestanden |
| 24 Vollständige Abnahme des begrenzten Chats | Abnahme von Kern, allen fünf Anbieteradaptern, MCP, Wissen, extern verwaltetem lokalem Betrieb, zertifiziertem verwaltetem lokalem CPU-Betrieb, Bibliothek und Ressourcenuntergrenze | Muss bestanden werdenNoch nicht bestanden |
| 25 Bibliothekskatalog der Erstversion | Jedes erforderliche Mitglied hat ein freigegebenes, ausgereiftes Release; empfohlene Mitglieder bestehen oder legen einen Nachfolger und die Abweichung offen | Muss bestanden werdenNoch nicht bestanden |
Das Release-Kriterium von 100.000 Meldungen/s auf der vorgeschlagenen Hardwareklasse mit 32 vCPU ist getrennt von einem anspruchsvolleren Entwicklungsziel auf einer kleineren, nicht festgelegten Hardwareklasse. Kriterien zu Sicherheit, Identität, Anbietern, Dokumentation und Supportmatrix sind ebenso notwendig wie der Durchsatz.
Die konkreten Versionen für Dokumente, Medien, Raster, Vektoren, Massenaustausch und Anbieter, Produktiv-Locales, Katalogzeiträume sowie mehrere Kompatibilitätsrichtungen für Agenten, Sitzungen, Skills und Tokens sind noch offen. Sie müssen vor 1.0 ausgewählt und qualifiziert werden.
Auch Preise, Lizenzierung, kaufmännische Paketierung, Anbieterfinanzierung, Zeitpläne und Liefertermine sind noch nicht festgelegt. Ein vorgeschlagenes Ziel ist ein durchzuführender Test, keine Kundenzusage.
Beziehungen, Historie, Standort und Suche, die zusammenspielen müssen: Wir gleichen das mit der geplanten Grenze der Erstversion ab und sagen Ihnen offen, wo es passt.
Oder schreiben Sie an contact@natusai.com
NatusAI