Cygnus · prima release pianificataV1 previstaCygnus 1.0 è una release pianificata, soggetta a criteri di accettazione, di un database a grafo temporale programmabile. Il perimetro che segue è un piano di progettazione e qualificazione; nessun criterio di release né obiettivo prestazionale viene presentato come raggiunto.
Stato: Cygnus 1.0 non è stato accettato né rilasciato. Le evidenze su capacità incluse, sicurezza, documentazione, compatibilità, deployment e ripristino devono risultare tutte positive prima di una release pubblica.
La release pianificata riunisce linguaggio, runtime, storage e servizi sotto un unico modello semantico. Un'implementazione candidata non è una release pubblica.
Linguaggio ed esecuzione tipizzati, storage transazionale per grafo e serie temporali, autenticazione e autorizzazione nei percorsi di storage, servizi HTTP/RPC e di streaming tipizzati, client TypeScript generato, descrittori API e MCP.
I sette profili di modalità delimitati descritti sotto, attraversamento del grafo, indicizzazione geospaziale, recupero testuale/BM25 e sparse/dense, finestre temporali, aggregazioni (rollup) e sottoscrizioni persistenti.
Una superficie Explorer selezionata, cinque pattern applicativi congelati per gemelli, telemetria, log di eventi, tracciati geografici e CRUD di risorse; nucleo LSP, client VS Code e debugging headless delimitato.
Job e pianificazioni persistenti, osservabilità su singolo server, backup, ripristino point-in-time e ripristino verificato; un contratto di chat delimitato con qualificazione dei fornitori a versione esattamente fissata e una correzione degli errori controllata in modo indipendente.
Ordine delle dipendenze: nucleo → contratti dei servizi e sicurezza → dati temporali, spaziali e di recupero → Explorer selezionato e strumenti per agenti → operatività su singolo server e chat delimitata. Dati e servizi sicuri precedono l'interfaccia per agenti più ampia.
Si tratta di requisiti pianificati per la prima release, con criteri separati di conformità e sicurezza, non dell'affermazione che ogni interfaccia sia disponibile oggi.
Operazioni HTTP/RPC e di streaming tipizzate, change feed, client TypeScript generati e descrizioni dei servizi versionate per l'uso tramite API e MCP. Un servizio di file gestiti basato su Blob fornirebbe directory virtuali transazionali e trasferimenti delimitati, senza parsing implicito né accesso al filesystem dell'host.
Una coda nativa di decisioni e approvazioni conserverebbe le scelte umane autorevoli oltre la durata di una sessione dell'agente. La proposta di un agente e le relative evidenze restano separate dal permesso di attivarla.
La base nativa comprende tag di lingua, contesto di presentazione, identità tipizzata di messaggi e cataloghi e formattazione delimitata. Il server e i client TypeScript generati devono concordare su cataloghi fissati; le impostazioni locali esatte per la produzione e gli intervalli di supporto restano aperti.
L'Explorer autenticato selezionato copre Panoramica, Dati/grafo, Attività/log, Funzioni/API/MCP, Accessi e configurazione qualificata di chat/fornitori. La sua localizzazione deve superare controlli su argomenti tipizzati, RTL, pseudo-locale, accessibilità, traduzioni ostili e parità server/client. Il nucleo LSP, il client VS Code leggero e il contratto di debugging headless delimitato sono obbligatori; l'integrazione con il Debug Adapter Protocol di un editor è rinviata.
I cinque pattern applicativi congelati sono entità del gemello, serie di telemetria, log di eventi, tracciato geografico e CRUD di risorse. Un sistema di UI dichiarativa generale o un runtime del linguaggio nel browser non fanno parte di questa prima release.
Si tratta di requisiti architetturali per la release pianificata, soggetti a qualificazione di conformità e sicurezza.
L'accesso bitemporale distingue il tempo di validità di un fatto dal momento in cui è entrato nel sistema. Una risposta «as-of» dovrebbe essere riproducibile rispetto a entrambi, comprese le correzioni successive.
Le transazioni strict-serializable con rilevamento fine dei conflitti logici sono pensate per mantenere in un'unica commit epoch le modifiche a entità, grafo, tempo e indici transazionali o risorse derivate dichiarati.
I controlli di accesso risiedono nei percorsi di storage e di esecuzione, comprese scansioni degli indici, attraversamenti e aggregazioni. L'individuazione è separata dall'accesso in lettura; le risorse negate non devono trapelare tramite conteggi, errori o indizi sulla loro esistenza. L'autorizzazione della ricerca avviene prima del ranking e della selezione top-k.
L'effetto dichiarato di una funzione pubblica descrive un comportamento potenziale; non concede mai, da solo, un permesso. I contenuti recuperati e l'output del modello restano non attendibili quando un agente propone un'azione con uno strumento.
Le fonti archiviate mantengono accesso delimitato, descrittori versionati, classificazione, provenienza, conservazione e autorizzazione. Testi, tile o embedding derivati sono versionati esplicitamente e non diventano mai, in modo silenzioso, l'originale.
| Modalità | Rappresentazione pianificata per la prima release | Fuori dalle affermazioni della prima release |
|---|---|---|
| Testo | Stringhe UTF-8 delimitate; UTF-8 di grandi dimensioni come blob in streaming o letti per intervalli; indice testuale/BM25 versionato per analizzatore. | Riparazione universale dei set di caratteri, normalizzazione implicita che modifica la fonte o materializzazione illimitata delle stringhe. |
| Documenti | Byte della fonte autorevoli con metadati e provenienza; derivati espliciti di testo e chunk possono essere forniti o prodotti da un fornitore esterno dichiarato. | Parsing universale di PDF/documenti office, OCR silenzioso o trattamento del testo estratto come fonte. |
| Immagini, audio e video | Byte della fonte, metadati dei media e digest; acquisizione delimitata e ripristinabile, streaming per intervalli e derivati esterni versionati esplicitamente. | Decoder/transcoder integrati, pipeline video nativa, miniature, estrazione di frame o similarità intrinseca tra media. |
| Stato di serie temporali | Accesso puntuale, a batch e per intervalli, estensioni regolari/irregolari e risoluzione esatta; più avanti nella sequenza di consegna inclusa, finestre sul tempo dell'evento, watermark, aggregazioni (rollup) e sottoscrizioni persistenti. | Più eventi indipendenti nello stesso istante in un'unica serie; per questi si usa una mappa di eventi. |
| GIS vettoriale | Valori/feature geografici consapevoli del CRS, geometrie di grandi dimensioni in streaming dove serve, predicati esatti e candidati indicizzati con ricontrollo esatto. | Esecuzione spaziale distribuita o un linguaggio di fuga generale compatibile con PostGIS. |
| GIS raster | Byte della fonte con descrittore raster, accesso delimitato per byte/intervalli e proiezioni esterne dichiarate di tile o overview. | Decodifica raster integrata, riproiezione/costruzione di overview native o accesso casuale garantito alle tile da formati sequenziali. |
| Numerici densi e sparsi | Array delimitati e array sparsi; archiviazione minima di tensori float a forma fissa per gli embedding prodotti dai fornitori. | Algebra tensoriale generale, esecuzione di modelli, ONNX, addestramento, quantizzazione o calcolo su dispositivi. |
Formati di interscambio esatti, tipi di documenti/media accettati, profili vettoriali e raster, versioni dei fornitori e fixture di sicurezza restano decisioni di release.
La topologia di produzione pianificata è un unico server. Può ospitare tenant con isolamento e quote, ma la sua capacità e il suo dominio di guasto restano un unico nodo.
| Profilo | Posizione pianificata per la prima release | Confine |
|---|---|---|
| Embedded | Incluso | Un unico processo applicativo con storage locale; nessun processo server separato. |
| Sviluppo | Incluso | Avvio da progetto vuoto e modalità di origine esplicite. |
| Produzione su singolo server | Incluso | Un nodo. Prima la durabilità POSIX; durabilità su object storage e supporto al backup nel perimetro della release. |
| Cluster | Escluso · profilo successivo | Nessuna affermazione su sharding, replica, attraversamento distribuito o failover. |
| Carico di lavoro isolato | Escluso | Nessun profilo di deployment per carichi isolati qualificato separatamente. |
Le scelte sull'ambiente di deployment, come un data center del cliente o un cloud privato, sono separate da questi profili di runtime.
Il profilo di produzione pianificato abbina job e pianificazioni persistenti a evidenze operative su un unico server. Non afferma nulla su cluster, failover delle repliche o disponibilità tra nodi.
Backup pianificati completi e incrementali, ripristino verificato e ripristino point-in-time, conservazione/TTL e blocchi per finalità legali (legal hold) sono requisiti inclusi. Un backup completato non dimostra che un'applicazione e i suoi dati possano essere ripristinati.
L'osservabilità di produzione e gli obiettivi di servizio dichiarati collegherebbero gli incidenti all'applicazione e alla release interessate. Solo classi di correzione registrate e preautorizzate possono agire entro il loro profilo delimitato; un'autorità scaduta o revocata deve rifiutare o fare escalation.
Le decisioni di canary e rollback restano sotto controllo indipendente. L'agente che propone una riparazione non può approvare l'ampliamento della propria autorità, modificare i propri criteri di accettazione né attivare il proprio successore.
Per il profilo su singolo server è previsto il deployment progressivo (rolling) di schemi, contratti e backend. Un'ABI C nativa stabile e un confine supervisionato verso i fornitori consentono integrazioni dichiarate senza aggiungere il registry aperto o l'host di componenti previsti in seguito.
La qualificazione della release richiede inoltre ripristino dopo crash, zero perdite di commit confermati e test di ripristino superati in condizioni dichiarate. Le soglie numeriche proposte compaiono più sotto come test, non come risultati misurati o livelli di servizio.
Queste sono ipotesi di carico proposte, in attesa di ratifica da parte dell'autore e di misurazione con i design partner. «Mondiale» descrive l'oggetto, non un'esecuzione distribuita.
| Dimensione | Carico di riferimento proposto |
|---|---|
| Entità del gemello | 250.000 navi; 5.000 porti e terminal; 2 milioni di unità di carico |
| Acquisizione delle posizioni | 25.000 rilevazioni/s sostenute; 100.000 rilevazioni/s per un picco di 60 secondi |
| Conservazione a piena fedeltà | 90 giorni; circa 194 miliardi di campioni e 2 TB compressi |
| Conservazione sottocampionata | Un campione ogni 5 minuti fino a 36 mesi; circa 79 miliardi di campioni e 0,8 TB |
| Eventi e documenti | 5 milioni di scali portuali, avvisi e manifesti all'anno |
| Embedding | 768 dimensioni float32; circa 15 GB/anno non compressi |
| Forma del grafo | Percorsi di proprietà, noleggio e operatore fino a profondità 6; grado uscente medio 4; nodi portuali fino a 100.000 archi |
| Concorrenza interattiva | 200 persone e 50 client automatici |
| Hardware e memoria | Classe hardware di riferimento proposta da 32 vCPU; rapporto dataset/RAM di circa 24:1. RAM, fornitore e modello di storage non sono specificati. |
Il valore di 25.000 rilevazioni/s sostenute descrive questo carico di riferimento. Il valore di 100.000 rilevazioni/s sostenute nei criteri di accettazione è un criterio di release proposto più severo; 80.000 rilevazioni/s su quell'hardware sono una soglia separata di rivalutazione del perimetro.
Un calcolo teorico di progettazione, con circa 10,3 byte compressi per campione, indica all'incirca 1–2 mila miliardi di campioni e fino a 20 TiB per nodo. Non è un risultato di capacità misurato.
≈10,3 byte
compressi per campione: la base del calcolo di progettazione
1–2 mila miliardi
campioni per nodo, all'incirca, secondo il calcolo teorico di progettazione
≤20 TiB
per nodo a quella densità; non è un risultato di capacità misurato
10 TiB / 16 GiB
un caso di qualificazione proposto separato: storage rispetto alla RAM installata
Un caso di qualificazione proposto separato usa 10 TiB di storage con 16 GiB di RAM installata per query delimitate puntuali, per intervalli, per pagina, per campione e per viewport. Non significa che il corpus o un intero indice risiedano in memoria, né che ogni query globale sia interattiva.
Con il criterio di release più severo di 100.000 rilevazioni/s, 90 giorni di campioni a piena fedeltà corrisponderebbero a circa 780 miliardi di campioni e 8 TB. Dodici mesi corrisponderebbero a circa 3,2 mila miliardi e 32 TB, oltre il centro di progettazione proposto per il singolo nodo. Una conservazione più lunga richiederebbe sottocampionamento o un profilo cluster successivo. Esportazione completa, ordinamento globale e ricostruzione dell'intero indice restano lavoro in streaming o tramite job persistenti.
Prima della 1.0, solo gli identificatori stabili assegnati non vengono mai riutilizzati. Tutti gli altri impegni 1.x sono intenzioni di release, e diversi dettagli restano da decidere.
| Dimensione | Prima della 1.0 | Comportamento 1.x previsto o decisione aperta |
|---|---|---|
| Linguaggio sorgente | Nessuna promessa di compatibilità 1.x prima della 1.0. | La grammatica della 1.0 è congelata; il codice accettato dalla 1.0 resta accettato dalle 1.x successive. |
| Descrittori e catalogo | Gli ID stabili assegnati a tipi, campi e altri elementi non vengono mai riutilizzati. | Una 1.x successiva legge i descrittori scritti dalle release 1.x precedenti. |
| Bytecode e piani | Nessuna promessa generale di compatibilità. | I piani fisici vengono ricostruiti all'aggiornamento. I job persistenti fissano un riferimento di esecuzione; un runtime più recente legge, migra, riesegue esplicitamente o rifiuta. I checkpoint arbitrari non sono portabili. |
| Decodifica dello storage | Nessuna promessa generale di compatibilità. | Le release successive mantengono i decoder per i blocchi 1.x ancora referenziati. |
| Scrittura dello storage | Nessuna promessa generale di compatibilità. | La lettura all'indietro è dichiarata per ciascun formato. Il downgrade non è promesso. |
| Protocollo e API | Nessuna promessa generale di compatibilità. | Solo aggiunte all'interno della 1.x; le modifiche incompatibili richiedono una nuova versione major del servizio. |
| Client generato | Nessuna promessa generale di compatibilità. | Un client generato per la 1.x compila con i server 1.x successivi. |
| Frontend dichiarativo | Nessuna promessa generale di compatibilità. | I tipi di descrittore sono solo additivi all'interno della 1.x. |
| Pacchetti e componenti | Nessuna promessa generale di compatibilità. | Decoder mantenuti, lock e interfacce selezionate verso fornitori nativi si aggiungono in modo compatibile. Un registry aperto e un host di componenti sono lavoro successivo. |
| Aggiornamento progressivo del cluster | Non applicabile. | Non applicabile: nessun profilo cluster nella 1.0. |
| Backup e ripristino | Nessuna promessa generale di compatibilità. | Una 1.x successiva ripristina i backup delle 1.x precedenti e riporta un esito di ripristino verificato. |
| Configurazione operativa | Nessuna promessa generale di compatibilità. | Solo aggiunte all'interno della 1.x; una rimozione richiede una release di deprecazione. |
| Adattatore per fornitori di IA | Nessuna promessa generale di compatibilità. | Lo schema di chat portabile e il protocollo dei worker si estendono in modo compatibile. Gli artefatti esatti dei fornitori fissano versioni, direzioni e capacità proprie. Nessun modello o funzionalità di un fornitore è sottinteso. |
| Spazio di lavoro per agenti e MCP | Intervallo di supporto ancora da selezionare. | Direzioni di versione, negoziazione e comportamento in caso di errore richiedono una decisione di release. |
| Sessione e istruzioni dell'agente | Intervallo di supporto ancora da selezionare. | Direzioni di versione e comportamento dei checkpoint richiedono una decisione di release. |
| Skill IA versionata | Intervallo di supporto ancora da selezionare. | Entrambe le direzioni e il comportamento in caso di errore richiedono una decisione di release. |
| Effetti delle funzioni pubbliche | Nessuna promessa generale di compatibilità. | Aggiungere un effetto rompe il contratto della funzione pubblica e richiede una nuova versione major del servizio; non conferisce mai, da solo, un'autorità. |
| Token di coerenza | Intervallo di supporto ancora da selezionare. | Il token rientra nel perimetro dei servizi della prima release; il suo contratto di compatibilità richiede una decisione di release. |
| Messaggi e cataloghi localizzati | Gli ID stabili di messaggi, cataloghi e profili non vengono mai riutilizzati. | Chiavi pubbliche e argomenti tipizzati si aggiungono in modo compatibile; i messaggi referenziati restano leggibili. Impostazioni locali, valori predefiniti e intervalli di supporto dei cataloghi restano aperti. |
La matrice di supporto della release deve specificare, per ogni riga, entrambe le direzioni di lettura e scrittura, gli intervalli supportati, la negoziazione e il comportamento in caso di errore. Non è sottintesa alcuna garanzia di downgrade o di portabilità di checkpoint arbitrari.
Il contratto di chat pianificato, neutrale rispetto al fornitore, copre contenuti, messaggi, eventi, strumenti, output strutturato e record persistenti di sessione e di esecuzione. Le capacità specifiche di un modello non vengono mai ereditate dal nome generico di un endpoint.
| Binding pianificato per la prima release | Confine della qualificazione |
|---|---|
| Fornitore fittizio deterministico | Necessario per test riproducibili. |
| OpenAI Responses diretto | Un artefatto esatto del fornitore e una matrice fissata di capacità/contratto; nessun modello del fornitore è promesso. |
| Anthropic Messages | Un artefatto esatto del fornitore e una matrice fissata di capacità/contratto. |
| Ollama nativo | Qualificato rispetto al suo contratto nativo, non alla sua interfaccia compatibile con OpenAI. |
| Endpoint delimitato compatibile con OpenAI | Binding tipizzato all'endpoint con capacità verificate tramite probing; non dichiara l'identità OpenAI. |
| Runtime co-residente gestito esternamente | Solo affermazioni delimitate sulle risorse client di Cygnus; il runtime esterno non viene conteggiato come margine di Cygnus. |
| llama.cpp locale certificato e gestito da Cygnus | Membro CPU obbligatorio; CUDA solo se qualificato. Modello, tokenizer, runtime, dispositivo, configurazione e perimetro di risorse esatti richiedono un certificato firmato. |
Gli endpoint remoti o locali gestiti in modo indipendente non ereditano le garanzie di RAM/VRAM del locale gestito. Calcolo nativo dei modelli, agenti nativi dei fornitori ad ampio spettro, fallback automatico e uso illimitato dell'IA sono fuori da questo profilo. I nomi di fornitori e prodotti identificano solo le interfacce; non implicano alcuna partnership o approvazione.
Nessuno dei criteri seguenti viene dichiarato superato. I valori si riferiscono a condizioni dichiarate di carico, hardware e coerenza; obbligatori e raccomandati restano distinti: 22 criteri sono obbligatori, 2 raccomandati.
| Criterio · evidenza richiesta | Soglia proposta | Requisito · stato |
|---|---|---|
| 01 Design partner in produzione con un carico conforme a quello di riferimento | Almeno 3 | ObbligatorioNon ancora superato |
| 02 System of record in produzione con storico conservato | Almeno 1, con almeno 6 mesi di storico | ObbligatorioNon ancora superato |
| 03 Acquisizione continua di posizioni sulla classe hardware di riferimento proposta da 32 vCPU, con coerenza transazionale degli indici | Almeno 100.000 rilevazioni/s | ObbligatorioNon ancora superato |
| 04 Assorbimento dei picchi senza scarti né crescita illimitata delle code | 100.000 rilevazioni/s per 60 secondi | ObbligatorioNon ancora superato |
| 05 Navi all'interno di un poligono su 250.000 posizioni in tempo reale | p99 al massimo 150 ms | ObbligatorioNon ancora superato |
| 06 Lettura del tracciato di una singola nave su 90 giorni | p99 al massimo 250 ms | ObbligatorioNon ancora superato |
| 07 Recupero ibrido sparse e dense top-20 su 5 milioni di documenti | p99 al massimo 300 ms | ObbligatorioNon ancora superato |
| 08 Lettura dell'intorno di un gemello, profondità 3 e al massimo 500 nodi | p99 al massimo 50 ms | RaccomandatoNon ancora superato |
| 09 Correttezza out-of-core senza crescita illimitata della memoria | Dataset almeno 24 volte la RAM | ObbligatorioNon ancora superato |
| 10 Overhead dell'autorizzazione a livello di elemento rispetto a una policy a grana grossa | Al massimo 2 volte | ObbligatorioNon ancora superato |
| 11 Punto di ripristino dei commit confermati su un server | Zero commit confermati persi | ObbligatorioNon ancora superato |
| 12 Riavvio con un dataset di 3 TiB | Le scritture autorevoli riprendono entro 20 secondi | ObbligatorioNon ancora superato |
| 13 Test pianificati di ripristino verificato nella finestra di release | 100% superati | ObbligatorioNon ancora superato |
| 14 Ripristino dopo crash a ogni fase di commit | 100% dei test superati | ObbligatorioNon ancora superato |
| 15 Valutazioni di agenti su progetti vuoti senza interventi umani | Almeno il 70% riuscite entro budget dichiarati | ObbligatorioNon ancora superato |
| 16 Da progetto vuoto a funzionalità di lettura/scrittura del gemello, autorizzata e in deployment, con client TypeScript generato e modulo | Al massimo 30 minuti, guidato da agenti | RaccomandatoNon ancora superato |
| 17 Suite di conformità obbligatorie per ogni profilo incluso | 100% superati | ObbligatorioNon ancora superato |
| 18 Specifiche congelate e suite minime di conformità | Substrato del nucleo, descrittori di identità stabili e kernel di minacce/sicurezza; descrittori di modalità, linguaggio, progetto, rappresentazione intermedia, piani, schema, storage, transazioni, stream, lock dei pacchetti, localizzazione e strumenti di base; servizi, MCP, funzionalità, UI, TypeScript generato, bundle di deployment, change feed e sicurezza completa; ricerca e tempo degli eventi; MCP guidato, proiezione congelata delle funzionalità, localizzazione dell'Explorer, LSP e debug headless; operatività su singolo server, interfaccia verso fornitori nativi e chat delimitata. Modello delle minacce rivisto a ogni criterio incluso. | ObbligatorioNon ancora superato |
| 19 Esempi della documentazione eseguiti come test | 100% | ObbligatorioNon ancora superato |
| 20 Baseline di regressione delle prestazioni con responsabili | Ogni benchmark dei percorsi critici | ObbligatorioNon ancora superato |
| 21 Matrice completa di supporto e compatibilità | Formati esatti, profili di documenti/media/raster/fornitori, impostazioni locali e cataloghi selezionati; tutte le 19 dimensioni specificano entrambe le direzioni, intervalli, negoziazione e comportamento in caso di errore; nessuna cella aperta | ObbligatorioNon ancora superato |
| 22 Identità di produzione e attivazione crittografica | Fornitore di chiavi esterno qualificato e cerimonia del primo amministratore sottoposta ad audit; nessun ripiego su provider di sviluppo o su file | ObbligatorioNon ancora superato |
| 22 Divulgazione delle vulnerabilità e operazioni di release | Contatto monitorato, chiave di cifratura pubblica, security.txt, percorso per gli avvisi di sicurezza, calendario di supporto e ruoli di release/rollback già esercitati | ObbligatorioNon ancora superato |
| 24 Accettazione completa della chat delimitata | Accettazione di nucleo, tutti e cinque gli adattatori per fornitori, MCP, conoscenza, locale gestito esternamente, locale CPU gestito e certificato, libreria e soglia minima di risorse | ObbligatorioNon ancora superato |
| 25 Catalogo delle librerie della prima release | Ogni membro obbligatorio ha una release matura approvata; i membri raccomandati superano i test o dichiarano un successore e lo scostamento | ObbligatorioNon ancora superato |
Il criterio di release di 100.000 rilevazioni/s sulla classe hardware proposta da 32 vCPU è separato da un obiettivo di ingegneria più impegnativo su una classe hardware più piccola e non specificata. I criteri su sicurezza, identità, fornitori, documentazione e matrice di supporto sono necessari quanto il throughput.
Restano aperte le versioni esatte di documenti, media, raster, vettoriali, interscambio massivo e fornitori, le impostazioni locali di produzione, gli intervalli dei cataloghi e diverse direzioni di compatibilità per agenti, sessioni, skill e token. Devono essere selezionate e qualificate prima della 1.0.
Anche prezzi, licenze, pacchetti commerciali, finanziamento dei fornitori, calendari e date di consegna non sono selezionati. Un obiettivo proposto è un test da eseguire, non un impegno verso i clienti.
Relazioni, storico, posizione e ricerca che devono funzionare insieme: lo confronteremo con il confine pianificato della prima release e vi diremo con onestà dove si colloca.
Oppure scriveteci a contact@natusai.com
NatusAI