Cygnus · profili successivi e proposteRoadmap

Cosa viene dopo un nucleo collaudato. Il perimetro segue le evidenze.

Name: NatusAI Cygnus
Brand: NatusAI

Queste sono famiglie di capacità proposte o rinviate, non funzionalità rilasciate né un calendario di consegna con date. La prima release deve dimostrare le proprie affermazioni sul singolo server prima che venga accettato un profilo più ampio.

Stato: il marketplace opzionale gestito in proprio è una direzione selezionata, il cui esercizio pubblico resta subordinato a criteri di accettazione. I profili cluster, di piattaforma gestita e di governance richiedono evidenze e decisioni separate. Non è stata selezionata alcuna data.

Scoprite i profili successivi Perimetro pianificato della v1

Cubi di vetro luminosi che contengono grafi di nodi connessi, collegati nello spazio: profili successivi che scalano oltre un singolo nodo

Profilo cluster successivo Roadmap

Dimostrare un nodo prima di distribuire il sistema.

Il profilo cluster successivo aggiungerebbe shard, replica, failover, instradamento, ribilanciamento, transazioni tra shard, attraversamento distribuito, aggiornamenti con versioni miste e rilocazione dei tenant.

Un obiettivo di progettazione multi-nodo o multi-PiB appartiene a questo profilo, mai a Cygnus 1.0.

L'accettazione dello scale-out richiederebbe evidenze di correttezza distribuita, di ripristino e sui domini di guasto, su carichi di lavoro rappresentativi. I soli campi di formato riservati non dimostrano un cluster.

1 nodo

Topologia di produzione di Cygnus 1.0: capacità e dominio di guasto restano un unico server.

multi-PiB

Un obiettivo di progettazione solo per il profilo cluster successivo, non un'affermazione sulla prima release.

IA e calcolo successivi Roadmap

Un'IA più ampia richiede un'esecuzione qualificata separatamente.

Calcolo su modelli e tensori

Layout tensoriali a tile e sparsi, algebra, grafi di calcolo, risorse di modello, ONNX, addestramento, autodiff, esecuzione su GPU/NPU e calcolo distribuito restano lavoro successivo.

Workflow nativi dei fornitori

Workflow di agenti, subagenti, skill, plugin, hook, attività collaborative o in background, memoria avanzata, compattazione generata e fallback automatico sono fuori dal primo profilo di chat.

Binding aggiuntivi

Interfacce vLLM native o compatibili, compatibili con Ollama, per agenti Anthropic e Codex richiedono una propria qualificazione. Il CUDA gestito resta subordinato all'esatto perimetro certificato.

Modelli, artefatti dei fornitori e perimetri di risorse richiedono evidenze fissate di capacità e sicurezza. Un fornitore remoto non offre una garanzia sulle risorse locali. I nomi di fornitori e prodotti identificano solo le interfacce.

Ecosistema riutilizzabile Roadmap

Trovare una soluzione verificata; creare un candidato privato quando non esiste.

Un marketplace opzionale gestito in proprio, con il relativo ciclo di librerie, è una direzione di prodotto successiva già selezionata, il cui esercizio pubblico resta subordinato a criteri di accettazione.

È progettato per individuare release compatibili esatte o restituire un esplicito «nessuna corrispondenza», e poi preparare, dove serve, un candidato privato con selezione dei moduli. Compilazione, sicurezza, risorse, compatibilità e valutazione da parte di agenti precederebbero un'approvazione separata dei maintainer e una release firmata e immutabile.

Una release di libreria versiona insieme i propri moduli, mentre ogni applicazione attiva solo i moduli che le servono, senza trascinare codice affine inutilizzato, dipendenze, fornitori, permessi o profili di risorse.

Artefatti approvati ed evidenze pubblicabili potrebbero essere riutilizzati tra applicazioni. Dati dei clienti, logica privata, prompt e chiavi dei fornitori resterebbero all'interno del loro perimetro di accesso. Gli agenti potrebbero proporre candidati, ma non installarli, autorizzarli, firmarli, approvarli o pubblicarli da soli.

Un'applicazione di riferimento più ampia per una piattaforma gestita è una proposta separata e non ratificata che copre provisioning delle applicazioni, controllo della flotta, registrazioni commerciali, campagne di contribuzione e auto-aggiornamento in hosting. Prezzi, commissioni, ricompense, fatturazione e finanziamento restano da decidere.

Mondi di dati e governance proposti Proposto · non selezionato

Mondi biforcabili e verifica indipendente richiedono nuovi modelli di guasto.

Una proposta successiva alla v1, mostrata qui così come compare nell'attuale perimetro di Cygnus. Nulla in questa sezione è selezionato, pianificato o parte di Cygnus 1.0.

Mondi di dati

Mondi di dati con condivisione strutturale, simulazione deterministica, merge semantico a tre vie, contabilizzazione dello storico conservato e cicli di vita espliciti di merge/drop sono rinviati.

Verifica indipendente

Una federazione proposta userebbe una finalità tollerante ai guasti bizantini su transizioni applicative deterministiche e un impegno sullo stato semantico indipendente dal layout. Validatori, verificatori completi, archivi e verificatori leggeri hanno ruoli separati; un utente potrebbe conservare e verificare una copia di proprietà indipendente dell'intero storico pubblico senza diventare validatore.

Un carico di lavoro di governance qualificante

Un'applicazione proposta di democrazia liquida richiederebbe versioni delle proposte riproducibili in modo indipendente, istantanee dell'idoneità, conferimenti e revoche di deleghe, regole su cicli e prevalenza, espressioni e sostituzioni di voto, semantica di chiusura e certificati di scrutinio.

Si tratta di una proposta successiva alla v1. Non è stato selezionato alcun algoritmo di consenso, governance dei validatori, sistema di identità personale, token, rete pubblica, servizio gestito o schema di segretezza del voto. Il voto segreto richiede una crittografia revisionata separatamente e non deve mai pubblicare voti in chiaro; uno storico verificato da solo non garantisce la legittimità degli elettori, l'equità o l'integrità di un'elezione.

Altre famiglie rinviate

Tenere il lavoro adiacente fuori dalla promessa della prima release.

Famiglie di capacità rinviate · lavoro successivo, non parte di Cygnus 1.0
Famiglia	Lavoro successivo
Interpretazione di documenti e media	Parser generali integrati, OCR, decodifica/transcodifica di media, miniature, estrazione di frame/tile, riproiezione raster nativa e overview.
Ottimizzazione	Specializzazione JIT/AOT, fusione degli operatori, posizionamento NUMA e layout adattivi.
Strumenti per sviluppatori e componenti	Debug Adapter Protocol, client per registry di pacchetti aperti e host di componenti in sandbox.
Mobilità dei tenant	Esportazione/importazione portabile dei tenant e rilocazione dipendente dal cluster.
UI e runtime web	UI dichiarativa generale oltre i pattern Explorer selezionati, rendering lato server generale e un runtime del linguaggio lato browser.
Conservazione e tempo	Cancellazione crittografica predefinita per soggetto e scale temporali scientifiche che tengono conto dei secondi intercalari.

Una direzione falsificabile

Le evidenze possono cambiare il perimetro.

Quelli che seguono sono criteri di rivalutazione proposti, non misurazioni ottenute né livelli di servizio per i clienti. Soddisfarne uno avvierebbe una revisione del perimetro, non la promessa di rilasciare un'architettura alternativa.

Otto segnali di rivalutazione · Obiettivi di qualificazione proposti, non risultati misurati, impegni di prodotto o livelli di servizio.
Segnale	Motivo proposto per la rivalutazione
Acquisizione	Meno di 80.000 rilevazioni/s sostenute sulla classe proposta da 32 vCPU, con coerenza transazionale degli indici. Il criterio di release è, separatamente, 100.000 rilevazioni/s.
Query	p99 oltre 500 ms per 250.000 posizioni attuali in un poligono, o oltre 1.000 ms per il tracciato di una nave su 90 giorni, con un rapporto dataset/RAM di 24×.
Costo delle policy	Autorizzazione a livello di elemento oltre 3× il p99 a grana grossa. Il criterio di release proposto è più severo: 2×.
Adeguatezza geo	Oltre il 20% delle query spaziali dei design partner richiede un linguaggio spaziale esterno.
Completamento da parte degli agenti	Meno del 70% delle valutazioni dichiarate su progetti vuoti riesce senza interventi umani.
Ricorso a store esterni	Un partner ha bisogno, entro 90 giorni, di un altro store di ricerca, serie temporali o messaggistica per il carico di riferimento.
Esposizione sui tempi di consegna	Le milestone di nucleo, servizi e dati superano un intervallo proposto di 30 mesi dalla milestone iniziale, con un organico realisticamente disponibile; è un criterio di rivalutazione, non una data di consegna.
Ripristino	Un qualsiasi test di ripristino verificato fallisce o un commit confermato va perso nei crash test.

Carico di lavoro, hardware, coerenza, organico e metodi di test andrebbero concordati prima che i criteri possano orientare una decisione di release.

Decisioni aperte

I piani restano condizionati.

Non è stata selezionata alcuna data di consegna pubblica, prezzo, licenza, pacchetto, modello di finanziamento dei fornitori o commissione del marketplace. Le matrici di formati, fornitori, impostazioni locali e compatibilità sono decisioni della prima release; i profili successivi richiedono prove proprie.

Il primo checkpoint tecnico è l'insieme completo delle evidenze di accettazione di Cygnus 1.0, compresi ripristino verificato e contratti di supporto. Il perimetro successivo alla v1 viene rivalutato in base all'uso reale dei design partner, non dato per scontato da questa roadmap.

Leggete il confine pianificato della v1 Parliamo del vostro carico di dati