Cygnus · première version prévueV1 prévueCygnus 1.0 est une version prévue, soumise à des critères d’acceptation, d’une base de données de graphe temporel programmable. Le périmètre ci-dessous est un plan de conception et de qualification ; aucun critère de publication ni objectif de performance n’est présenté comme atteint.
Statut : Cygnus 1.0 n’a été ni accepté ni publié. Les capacités incluses ainsi que les preuves de sécurité, de documentation, de compatibilité, de déploiement et de restauration doivent toutes être validées avant une publication.
La version prévue réunit langage, environnement d’exécution, stockage et services sous un même modèle sémantique. Une implémentation candidate n’est pas une version publiée.
Langage et exécution typés, stockage transactionnel de graphe et de séries temporelles, authentification et autorisation dans les chemins de stockage, services HTTP/RPC typés et en streaming, client TypeScript généré, descripteurs d’API et MCP.
Les sept profils de modalités bornés décrits ci-dessous, le parcours de graphe, l’indexation géospatiale, la recherche texte/BM25 et creuse/dense, les fenêtres temporelles, les agrégations et les abonnements durables.
Une surface Explorer retenue, cinq modèles d’application figés pour les jumeaux, la télémétrie, les journaux d’événements, les trajectoires géographiques et le CRUD de ressources ; cœur LSP, client VS Code et débogage headless borné.
Tâches durables et planifications, observabilité sur serveur unique, sauvegarde, restauration à un instant donné et restauration vérifiée ; un contrat de chat borné, avec une qualification des fournisseurs figée à la version exacte et une remédiation contrôlée de manière indépendante.
Ordre des dépendances : cœur → contrats de services et sécurité → données temporelles, spatiales et de recherche → Explorer et outils d’agents retenus → exploitation sur serveur unique et chat borné. Les données et les services sécurisés précèdent l’interface d’agents plus large.
Il s’agit d’exigences prévues pour la première version, avec des critères de conformité et de sécurité distincts, et non de l’affirmation que chaque surface est disponible aujourd’hui.
Opérations HTTP/RPC typées et en streaming, flux de modifications, clients TypeScript générés et descriptions de services versionnées pour l’usage via API et MCP. Un service de fichiers gérés adossé à des blobs fournirait des répertoires virtuels transactionnels et des transferts bornés, sans analyse implicite ni accès au système de fichiers de l’hôte.
Une file propriétaire de décisions et de validations conserverait les choix humains faisant autorité au-delà d’une session d’agent. La proposition d’un agent et ses éléments probants restent séparés de l’autorisation de l’activer.
Le socle natif comprend balises de langue, contexte de présentation, identité typée des messages et des catalogues, et mise en forme bornée. Le serveur et les clients TypeScript générés doivent s’accorder sur des catalogues figés ; les paramètres régionaux de production exacts et les durées de support restent ouverts.
L’Explorer authentifié retenu couvre Vue d’ensemble, Données/graphe, Activité/journaux, Fonctions/API/MCP, Accès et configuration qualifiée du Chat et des fournisseurs. Sa localisation doit passer des contrôles d’arguments typés, RTL, pseudo-locale, accessibilité, traductions hostiles et parité serveur/client. Le cœur LSP, le client VS Code léger et le contrat de débogage headless borné sont obligatoires ; une intégration Debug Adapter Protocol dans l’éditeur est reportée.
Les cinq modèles d’application figés sont l’entité de jumeau, la série de télémétrie, le journal d’événements, la trajectoire géographique et le CRUD de ressources. Un système général d’interface déclarative ou un environnement d’exécution du langage dans le navigateur ne font pas partie de cette première version.
Il s’agit d’exigences d’architecture pour la version prévue, soumises à une qualification de conformité et de sécurité.
L’accès bitemporel distingue le temps de validité d’un fait du moment où il est entré dans le système. Une réponse « à date » doit être reproductible selon les deux axes, y compris après des corrections ultérieures.
Des transactions strictement sérialisables, avec une détection fine des conflits logiques, doivent regrouper dans une même époque de commit les modifications d’entités, de graphe, de temps et d’index transactionnels ou de ressources dérivées déclarés.
Les contrôles d’accès s’appliquent dans les chemins de stockage et d’exécution, y compris les parcours d’index, les traversées et les agrégats. La découverte est distincte de l’accès en lecture ; les ressources refusées ne doivent pas transparaître par des comptages, des erreurs ou des indices d’existence. L’autorisation de recherche intervient avant le classement et la sélection top-k.
Un effet déclaré d’une fonction publique décrit un comportement potentiel ; il n’accorde jamais d’autorisation à lui seul. Le contenu récupéré et les sorties du modèle restent non fiables lorsqu’un agent propose une action d’outil.
Les sources stockées conservent accès borné, descripteurs versionnés, classification, provenance, conservation et autorisation. Le texte, les tuiles ou les plongements vectoriels dérivés sont explicitement versionnés et ne se substituent jamais silencieusement à l’original.
| Modalité | Représentation prévue en première version | Hors de l’engagement de première version |
|---|---|---|
| Texte | Chaînes UTF-8 bornées ; UTF-8 volumineux sous forme de blobs lus en flux ou par plages ; index texte/BM25 versionné par analyseur. | Réparation universelle des jeux de caractères, normalisation implicite modifiant la source ou matérialisation de chaînes non bornée. |
| Documents | Octets sources faisant autorité, avec métadonnées et provenance ; des dérivés explicites (texte, fragments) peuvent être fournis ou produits par un fournisseur externe déclaré. | Analyse universelle des PDF et documents bureautiques, OCR silencieux ou traitement du texte extrait comme source. |
| Image, audio et vidéo | Octets sources, métadonnées média et empreinte ; ingestion bornée avec reprise, streaming par plages et dérivés externes explicitement versionnés. | Décodeurs/transcodeurs intégrés, pipeline vidéo natif, vignettes, extraction d’images ou similarité intrinsèque des médias. |
| État des séries temporelles | Accès par point, par lot et par plage, étendues régulières ou irrégulières et résolution exacte ; plus tard dans la séquence de livraison incluse, fenêtres en temps d’événement, filigranes, agrégations et abonnements durables. | Plusieurs événements indépendants au même instant dans une seule série ; utiliser pour cela une table d’événements. |
| SIG vectoriel | Valeurs et entités géographiques tenant compte du CRS, géométries volumineuses en flux si nécessaire, prédicats exacts et candidats indexés avec revérification exacte. | Exécution spatiale distribuée ou langage de contournement général compatible PostGIS. |
| SIG raster | Octets sources avec descripteur raster, accès borné par octets ou par plages et projections externes déclarées de tuiles ou d’aperçus. | Décodage raster intégré, reprojection native ou génération d’aperçus, ou accès aléatoire garanti aux tuiles depuis des formats séquentiels. |
| Numérique dense et creux | Tableaux bornés et tableaux creux ; stockage minimal de tenseurs flottants de forme fixe pour les plongements produits par un fournisseur. | Algèbre tensorielle générale, exécution de modèles, ONNX, entraînement, quantification ou calcul sur accélérateur. |
Formats d’échange exacts, types de documents et de médias acceptés, profils vectoriels et raster, versions des fournisseurs et jeux de tests de sécurité restent des décisions de publication.
La topologie de production prévue est un serveur unique. Il peut héberger plusieurs clients avec isolation et quotas, mais sa capacité et son domaine de défaillance restent ceux d’un seul nœud.
| Profil | Position prévue en première version | Limites |
|---|---|---|
| Embarqué | Inclus | Un processus applicatif avec stockage local ; pas de processus serveur distinct. |
| Développement | Inclus | Amorçage d’un projet vierge et modes de source explicites. |
| Production sur serveur unique | Inclus | Un nœud. Durabilité POSIX d’abord ; durabilité sur stockage objet et prise en charge des sauvegardes dans le périmètre de la version. |
| Cluster | Exclu · profil ultérieur | Aucun engagement de sharding, de réplication, de parcours distribué ni de basculement. |
| Charge de travail isolée | Exclu | Aucun profil de déploiement pour charge de travail isolée qualifié séparément. |
Les choix d’environnement de déploiement, comme un centre de données client ou un cloud privé, sont distincts de ces profils d’exécution.
Le profil de production prévu associe tâches durables et planifications à des preuves opérationnelles sur un serveur unique. Il ne revendique ni cluster, ni basculement sur réplique, ni disponibilité inter-nœuds.
Sauvegardes planifiées complètes et incrémentales, restauration vérifiée et restauration à un instant donné, conservation/TTL et gels juridiques font partie des exigences incluses. Une sauvegarde terminée ne prouve pas qu’une application et ses données peuvent être restaurées.
L’observabilité de production et des objectifs de service déclarés relieraient les incidents à l’application et à la version concernées. Seules des classes de remédiation enregistrées et préautorisées peuvent agir, dans les limites de leur profil ; une autorité périmée ou révoquée doit refuser ou escalader.
Les décisions de déploiement canari et de retour arrière restent sous contrôle indépendant. L’agent qui propose une réparation ne peut ni approuver l’extension de sa propre autorité, ni modifier ses critères d’acceptation, ni activer son successeur.
Le déploiement progressif des schémas, des contrats et du backend est prévu pour le profil serveur unique. Une ABI C native stable et une frontière de fournisseurs supervisée permettent des intégrations déclarées sans ajouter le registre ouvert ni l’hôte de composants prévus ultérieurement.
La qualification de la version exige aussi la reprise après plantage, zéro perte de commits acquittés et des tests de restauration réussis dans des conditions déclarées. Les seuils chiffrés proposés figurent ci-dessous comme des tests, et non comme des résultats mesurés ou des niveaux de service.
Il s’agit d’hypothèses de charge proposées, en attente de ratification par l’auteur et de mesure par les partenaires de conception. « Mondial » décrit le sujet traité, pas une exécution distribuée.
| Dimension | Charge de travail de référence proposée |
|---|---|
| Entités du jumeau | 250 000 navires ; 5 000 ports et terminaux ; 2 millions d’unités de cargaison |
| Ingestion des positions | 25 000 rapports/s en régime soutenu ; 100 000 rapports/s en pic de 60 secondes |
| Conservation en pleine résolution | 90 jours ; environ 194 milliards d’échantillons et 2 To compressés |
| Conservation sous-échantillonnée | Un échantillon toutes les 5 minutes, jusqu’à 36 mois ; environ 79 milliards d’échantillons et 0,8 To |
| Événements et documents | 5 millions d’escales, d’avis et de manifestes par an |
| Plongements vectoriels | 768 dimensions float32 ; environ 15 Go/an bruts |
| Forme du graphe | Chemins de propriété, d’affrètement et d’exploitation jusqu’à une profondeur de 6 ; degré sortant moyen de 4 ; nœuds de port jusqu’à 100 000 arêtes |
| Concurrence interactive | 200 personnes et 50 clients machines |
| Matériel et mémoire | Classe de matériel de référence proposée à 32 vCPU ; rapport données/RAM d’environ 24:1. RAM, fournisseur et modèle de stockage non spécifiés. |
Le chiffre de 25 000 rapports/s en régime soutenu décrit cette charge de travail de référence. Le chiffre de 100 000 rapports/s en régime soutenu des critères d’acceptation est un critère de publication proposé plus strict ; 80 000 rapports/s sur ce matériel constitue un seuil distinct de réévaluation du périmètre.
Un calcul de conception théorique, à environ 10,3 octets compressés par échantillon, aboutit à environ 1 000 à 2 000 milliards d’échantillons (1 à 2 billions) et jusqu’à 20 Tio par nœud. Ce n’est pas un résultat de capacité mesuré.
≈10,3 octets
compressés par échantillon : la base du calcul de conception
1–2 billions
d’échantillons par nœud, soit environ 1 000 à 2 000 milliards, selon un calcul de conception théorique
≤20 Tio
par nœud à cette densité ; pas un résultat de capacité mesuré
10 Tio / 16 Gio
un cas de qualification proposé distinct : stockage par rapport à la RAM installée
Un cas de qualification proposé distinct utilise 10 Tio de stockage avec 16 Gio de RAM installée, pour des requêtes bornées par point, plage, page, échantillon et fenêtre d’affichage. Cela ne signifie pas que le corpus ou un index entier réside en mémoire, ni que chaque requête globale est interactive.
Avec le critère de publication plus strict de 100 000 rapports/s, 90 jours d’échantillons en pleine résolution représenteraient environ 780 milliards d’échantillons et 8 To. Douze mois représenteraient environ 3 200 milliards et 32 To, au-delà du centre de conception proposé pour un nœud unique. Une conservation plus longue exigerait un sous-échantillonnage ou un profil cluster ultérieur. L’export complet, le tri global et la reconstruction d’un index entier restent des traitements en flux ou des tâches durables.
Avant la 1.0, seule la non-réutilisation des identifiants stables attribués est garantie. Tous les autres engagements 1.x sont des intentions de version, et plusieurs détails restent à décider.
| Dimension | Avant la 1.0 | Comportement 1.x visé ou décision ouverte |
|---|---|---|
| Langage source | Aucune promesse de compatibilité 1.x avant la 1.0. | La grammaire 1.0 est figée ; le code source accepté par la 1.0 reste accepté par les versions 1.x ultérieures. |
| Descripteurs et catalogue | Les identifiants stables de types, de champs et autres identifiants attribués ne sont jamais réutilisés. | Une version 1.x ultérieure lit les descripteurs écrits par les versions 1.x antérieures. |
| Bytecode et plans | Aucune promesse générale de compatibilité. | Les plans physiques sont reconstruits lors des mises à niveau. Les tâches durables figent une référence d’exécution ; un environnement d’exécution plus récent la lit, la migre, la rejoue explicitement ou la refuse. Les points de contrôle arbitraires ne sont pas portables. |
| Décodage du stockage | Aucune promesse générale de compatibilité. | Les versions ultérieures conservent les décodeurs des blocs 1.x encore référencés. |
| Écriture du stockage | Aucune promesse générale de compatibilité. | La lecture rétrocompatible est déclarée par format. Le retour à une version antérieure n’est pas promis. |
| Protocole et API | Aucune promesse générale de compatibilité. | Ajouts uniquement au sein de la 1.x ; les changements incompatibles exigent une nouvelle version majeure du service. |
| Client généré | Aucune promesse générale de compatibilité. | Un client généré pour la 1.x compile avec les serveurs 1.x ultérieurs. |
| Frontend déclaratif | Aucune promesse générale de compatibilité. | Les types de descripteurs ne font que s’ajouter au sein de la 1.x. |
| Paquets et composants | Aucune promesse générale de compatibilité. | Les décodeurs conservés, les verrous et les interfaces de fournisseurs natifs retenues évoluent par ajouts compatibles. Un registre ouvert et un hôte de composants relèvent de travaux ultérieurs. |
| Mise à niveau progressive du cluster | Sans objet. | Sans objet : aucun profil cluster dans la 1.0. |
| Sauvegarde et restauration | Aucune promesse générale de compatibilité. | Une version 1.x ultérieure restaure les sauvegardes 1.x antérieures et rend compte d’un résultat de restauration vérifié. |
| Configuration opérationnelle | Aucune promesse générale de compatibilité. | Ajouts uniquement au sein de la 1.x ; une suppression exige une version de dépréciation. |
| Adaptateur de fournisseur d’IA | Aucune promesse générale de compatibilité. | Le schéma de chat portable et le protocole des workers évoluent par ajouts compatibles. Les artefacts exacts des fournisseurs figent leurs propres versions, sens de compatibilité et capacités. Aucun modèle ni aucune fonctionnalité d’un éditeur n’est sous-entendu. |
| Espace de travail agents et MCP | Durée de support encore à choisir. | Sens de compatibilité, négociation et comportement en cas d’échec exigent une décision de version. |
| Session et consignes d’agent | Durée de support encore à choisir. | Sens de compatibilité et comportement des points de contrôle exigent une décision de version. |
| Compétence IA versionnée | Durée de support encore à choisir. | Les deux sens de compatibilité et le comportement en cas d’échec exigent une décision de version. |
| Effets des fonctions publiques | Aucune promesse générale de compatibilité. | Ajouter un effet rompt le contrat de la fonction publique et exige une nouvelle version majeure du service ; cela n’accorde jamais d’autorité à soi seul. |
| Jeton de cohérence | Durée de support encore à choisir. | Le jeton fait partie du périmètre de services de la première version ; son contrat de compatibilité exige une décision de version. |
| Messages et catalogues localisés | Les identifiants stables de messages, de catalogues et de profils ne sont jamais réutilisés. | Les clés publiques et les arguments typés évoluent par ajouts compatibles ; les messages référencés restent lisibles. Paramètres régionaux, valeurs par défaut et durées de support des catalogues restent ouverts. |
La matrice de support de la version doit préciser, pour chaque ligne, les sens de lecture et d’écriture, les durées de support, la négociation et le comportement en cas d’échec. Aucune garantie de retour à une version antérieure ni de portabilité des points de contrôle arbitraires n’est sous-entendue.
Le contrat de chat prévu, indépendant des fournisseurs, couvre le contenu, les messages, les événements, les outils, les sorties structurées et des enregistrements durables de sessions et d’exécutions. Les capacités propres à un modèle ne sont jamais déduites d’un nom de point d’accès générique.
| Liaison prévue en première version | Limite de qualification |
|---|---|
| Fournisseur factice déterministe | Requis pour des tests reproductibles. |
| OpenAI Responses en direct | Un artefact de fournisseur exact et une matrice de capacités et de contrats figée ; aucun modèle d’éditeur n’est promis. |
| Anthropic Messages | Un artefact de fournisseur exact et une matrice de capacités et de contrats figée. |
| Ollama natif | Qualifié selon son contrat natif, et non selon son interface compatible OpenAI. |
| Point d’accès borné compatible OpenAI | Liaison typée au point d’accès, avec capacités sondées ; elle ne prétend pas être OpenAI. |
| Environnement d’exécution co-résident géré en externe | Uniquement des réservations bornées de ressources pour le client Cygnus ; l’environnement externe n’est pas compté dans la marge de Cygnus. |
| llama.cpp local certifié, géré par Cygnus | Membre CPU requis ; CUDA uniquement s’il est qualifié. Modèle, tokenizer, environnement d’exécution, matériel, configuration et enveloppe de ressources exacts exigent un certificat signé. |
Les points d’accès distants ou locaux exploités indépendamment n’héritent pas des garanties de RAM/VRAM du mode local géré. Le calcul natif de modèles, les agents natifs des fournisseurs au sens large, le repli automatique et l’usage illimité de l’IA sortent de ce profil. Les noms de fournisseurs et de produits désignent uniquement des interfaces ; ils n’impliquent ni partenariat ni recommandation.
Aucun critère ci-dessous n’est présenté comme validé. Les chiffres s’appliquent à des conditions déclarées de charge, de matériel et de cohérence ; « obligatoire » et « recommandé » restent distincts : 22 critères doivent être validés, 2 devraient l’être.
| Critère · preuve requise | Seuil proposé | Exigence · statut |
|---|---|---|
| 01 Partenaires de conception en production exécutant une charge de travail au profil de la référence | Au moins 3 | ObligatoirePas encore validé |
| 02 Système de référence en production avec historique conservé | Au moins 1, avec au moins 6 mois d’historique | ObligatoirePas encore validé |
| 03 Ingestion soutenue de positions sur la classe de matériel de référence proposée à 32 vCPU, avec cohérence transactionnelle des index | Au moins 100 000 rapports/s | ObligatoirePas encore validé |
| 04 Absorption des pics sans délestage ni croissance non bornée des files | 100 000 rapports/s pendant 60 secondes | ObligatoirePas encore validé |
| 05 Navires dans un polygone parmi 250 000 positions en direct | p99 de 150 ms au plus | ObligatoirePas encore validé |
| 06 Lecture de la trajectoire d’un navire sur 90 jours | p99 de 250 ms au plus | ObligatoirePas encore validé |
| 07 Recherche hybride creuse et dense top-20 sur 5 millions de documents | p99 de 300 ms au plus | ObligatoirePas encore validé |
| 08 Lecture du voisinage d’un jumeau, profondeur 3 et 500 nœuds au plus | p99 de 50 ms au plus | RecommandéPas encore validé |
| 09 Exactitude hors mémoire sans croissance non bornée de la mémoire | Jeu de données d’au moins 24 fois la taille de la RAM | ObligatoirePas encore validé |
| 10 Surcoût de l’autorisation au niveau de l’élément par rapport à une politique à granularité grossière | 2 fois au plus | ObligatoirePas encore validé |
| 11 Point de reprise des commits acquittés sur un serveur | Zéro commit acquitté perdu | ObligatoirePas encore validé |
| 12 Redémarrage avec un jeu de données de 3 Tio | Reprise des écritures faisant autorité en moins de 20 secondes | ObligatoirePas encore validé |
| 13 Tests planifiés de restauration vérifiée dans la fenêtre de publication | 100 % de réussite | ObligatoirePas encore validé |
| 14 Reprise après plantage à chaque étape du commit | 100 % des tests réussis | ObligatoirePas encore validé |
| 15 Évaluations d’agents sur projet vierge sans réparation humaine | Au moins 70 % de réussite dans les budgets déclarés | ObligatoirePas encore validé |
| 16 D’un projet vierge à une fonctionnalité de lecture/écriture de jumeau déployée et autorisée, avec client TypeScript généré et formulaire | 30 minutes au plus, piloté par un agent | RecommandéPas encore validé |
| 17 Suites de conformité obligatoires pour chaque profil inclus | 100 % de réussite | ObligatoirePas encore validé |
| 18 Spécifications figées et suites de conformité minimales | Substrat central, descripteurs d’identité stables et noyau menaces/sécurité ; descripteurs de modalités, langage, projet, représentation intermédiaire, plans, schéma, stockage, transactions, flux, verrou de paquets, localisation et outils de base ; services, MCP, fonctionnalités, interface, TypeScript généré, bundles de déploiement, flux de modifications et sécurité complète ; recherche et temps d’événement ; MCP guidé, projection de fonctionnalités figée, localisation de l’Explorer, LSP et débogage headless ; exploitation sur serveur unique, interface de fournisseurs natifs et chat borné. Modèle de menaces réexaminé à chaque critère inclus. | ObligatoirePas encore validé |
| 19 Exemples de documentation exécutés comme tests | 100% | ObligatoirePas encore validé |
| 20 Références de non-régression des performances, avec responsables | Chaque benchmark de chemin critique | ObligatoirePas encore validé |
| 21 Matrice complète de support et de compatibilité | Formats exacts, profils documents/médias/raster/fournisseurs, paramètres régionaux et catalogues retenus ; les 19 dimensions précisent les deux sens, les durées, la négociation et le comportement en cas d’échec ; aucune case ouverte | ObligatoirePas encore validé |
| 22 Identité de production et activation cryptographique | Fournisseur de clés externe qualifié et cérémonie du premier administrateur auditée ; aucun repli sur un fournisseur de développement ou de fichiers | ObligatoirePas encore validé |
| 22 Divulgation des failles de sécurité et opérations de publication | Contact surveillé, clé de chiffrement publique, security.txt, circuit d’avis de sécurité, calendrier de support et rôles de publication/retour arrière exercés | ObligatoirePas encore validé |
| 24 Acceptation complète du chat borné | Acceptation du cœur, des cinq adaptateurs de fournisseurs, de MCP, des connaissances, du local géré en externe, du local CPU géré et certifié, de la bibliothèque et du plancher de ressources | ObligatoirePas encore validé |
| 25 Catalogue de bibliothèques de première version | Chaque membre requis dispose d’une version mature approuvée ; les membres recommandés sont validés ou signalent un successeur et un écart | ObligatoirePas encore validé |
Le critère de publication de 100 000 rapports/s sur la classe de matériel proposée à 32 vCPU est distinct d’un objectif d’ingénierie plus exigeant sur une classe de matériel plus petite, non spécifiée. Les critères de sécurité, d’identité, de fournisseurs, de documentation et de matrice de support sont aussi nécessaires que le débit.
Les versions exactes des formats de documents, médias, raster, vecteurs, échanges en masse et fournisseurs, les paramètres régionaux de production, les durées de support des catalogues et plusieurs sens de compatibilité agents/sessions/compétences/jetons restent ouverts. Ils doivent être choisis et qualifiés avant la 1.0.
Tarifs, licences, offre commerciale, financement des fournisseurs, calendriers et dates de livraison ne sont pas non plus fixés. Un objectif proposé est un test à mener, pas un engagement client.
Relations, historique, localisation et recherche qui doivent fonctionner ensemble : nous la confronterons aux limites prévues de la première version et vous dirons en toute transparence où elle trouve sa place.
Ou écrivez-nous à contact@natusai.com
NatusAI