NatusAIKerne og tjenester
Typet sprog og udførelse, transaktionel lagring af graf og tidsserier, autentificering og autorisation i lagringsstien, typede HTTP/RPC- og streamingtjenester, genereret TypeScript-klient samt API- og MCP-beskrivelser.
- Forside
- Produkter
- NatusAI Cygnus
- Planlagt omfang af v1
Cygnus · planlagt første versionPlanlagt v1En præcis første version. Dokumentation før accept.
Cygnus 1.0 er en planlagt version af en programmerbar temporal grafdatabase, som først frigives, når fastlagte krav er opfyldt. Omfanget nedenfor er en plan for design og kvalificering; intet acceptkriterium eller ydelsesmål præsenteres som opnået.
Status: Cygnus 1.0 er hverken godkendt eller frigivet. Omfattede kapabiliteter, sikkerhed, dokumentation, kompatibilitet, udrulning og dokumentation for gendannelse skal alle bestå, før en offentlig version frigives.
Afgrænsning af første version
Et autoritativt system på én node med en kontrolleret flade for agenter.
Den planlagte version samler sprog, runtime, lagring og tjenester under én semantisk model. En kandidatimplementering er ikke en offentlig version.
Data og søgning
De syv afgrænsede modalitetsprofiler nedenfor, graftraversering, geospatial indeksering, tekst/BM25 og sparse/dense søgning, tidsvinduer, aggregeringer og varige abonnementer.
Værktøjer og oplevelse
En udvalgt Explorer-flade, fem fastfrosne applikationsmønstre til tvillinger, telemetri, hændelseslogge, geografiske spor og ressource-CRUD; LSP-kerne, VS Code-klient og afgrænset headless debugging.
Drift og AI
Varige jobs og tidsplaner, observerbarhed på én server, backup, gendannelse til et bestemt tidspunkt og verificeret gendannelse; en afgrænset chatkontrakt med kvalificering af præcist fastlåste leverandører og uafhængigt styret afhjælpning.
Rækkefølge: kerne → tjenestekontrakter og sikkerhed → temporale, geografiske og søgbare data → udvalgte Explorer- og agentværktøjer → drift på én server og afgrænset chat. Data og sikre tjenester kommer før den større agentflade.
Kontrakter for tjenester og værktøjer
Gør den samme typede model brugbar for mennesker, klienter og agenter.
Dette er planlagte krav til første version med særskilte krav til overensstemmelse og sikkerhed – ikke en påstand om, at alle flader er tilgængelige i dag.
Tjenester og administrerede filer
Typede HTTP/RPC- og streamingoperationer, ændringsfeeds, genererede TypeScript-klienter og versionerede tjenestebeskrivelser til brug via API og MCP. En Blob-baseret administreret filtjeneste ville give transaktionelle virtuelle mapper og afgrænset overførsel – uden implicit parsing eller adgang til værtens filsystem.
Varige menneskelige beslutninger
En indbygget kø til beslutninger og godkendelser ville bevare autoritative menneskelige valg ud over en agentsession. Et agentforslag og dokumentationen bag det holdes adskilt fra tilladelsen til at aktivere det.
Sprog og lokalisering
Den indbyggede basis omfatter sprogtags, præsentationskontekst, typet identitet for beskeder og kataloger samt afgrænset formatering. Serveren og genererede TypeScript-klienter skal være enige om fastlåste kataloger; de præcise sprogindstillinger i produktion og supportperioder er fortsat åbne.
Explorer og udviklerværktøjer
Den udvalgte, autentificerede Explorer dækker Oversigt, Data/graf, Aktivitet/logge, Funktioner/API/MCP, Adgang og kvalificeret opsætning af chat/leverandør. Lokaliseringen skal bestå kontroller af typede argumenter, RTL, pseudosprog, tilgængelighed, fjendtlige oversættelser og paritet mellem server og klient. LSP-kernen, den tynde VS Code-klient og den afgrænsede kontrakt for headless debugging er obligatoriske; en integration med Debug Adapter Protocol i editoren er udskudt.
De fem fastfrosne applikationsmønstre er tvillingentitet, telemetriserie, hændelseslog, geografisk spor og ressource-CRUD. Et generelt deklarativt UI-system eller en sprog-runtime i browseren er ikke en del af den første version.
Databetydning og beføjelser
Sømmene skal lukkes inden for ét system.
Dette er arkitektoniske krav til den planlagte version, med forbehold for kvalificering af overensstemmelse og sikkerhed.
Hvad der var sandt; hvad man vidste
Bitemporal adgang skelner mellem en kendsgernings gyldighedstid og det tidspunkt, hvor den kom ind i systemet. Et as-of-svar skal kunne reproduceres mod begge, inklusive senere rettelser.
Én transaktion og erklærede afledninger
Strict-serializable transaktioner med finkornet logisk konfliktdetektion skal holde ændringer i entiteter, graf, tid og erklærede transaktionelle indeks eller afledte ressourcer i én commit-epoke.
Autorisation før visning
Adgangskontrol hører hjemme i lagrings- og udførelsesstierne, inklusive indeksscanninger, traverseringer og aggregeringer. Opdagelse er adskilt fra læseadgang; ressourcer, der nægtes adgang til, må ikke lække via antal, fejl eller antydninger af, at de findes. Autorisation af søgning sker før rangering og top-k-udvælgelse.
En erklæret virkning af en offentlig funktion beskriver mulig adfærd; den giver aldrig tilladelse i sig selv. Hentet indhold og modeloutput forbliver upålidelige, når en agent foreslår en værktøjshandling.
Syv datafamilier
Varig lagring betyder ikke indbygget fortolkning.
Lagrede kilder bevarer afgrænset adgang, versionerede beskrivelser, klassificering, oprindelse, opbevaring og autorisation. Afledt tekst, fliser eller embeddings versioneres eksplicit og bliver aldrig ubemærket til originalen.
| Modalitet | Planlagt repræsentation i første version | Uden for påstanden for første version |
|---|---|---|
| Tekst | Afgrænsede UTF-8-strenge; store UTF-8-data som streamede blobs eller blobs med intervallæsning; tekst/BM25-indeks versioneret efter analysator. | Universel reparation af tegnsæt, implicit normalisering, der ændrer kilden, eller ubegrænset materialisering af strenge. |
| Dokumenter | Autoritative kildebytes med metadata og oprindelse; eksplicitte tekst- og chunk-afledninger kan leveres eller produceres af en erklæret ekstern leverandør. | Universel parsing af PDF/Office, OCR i det skjulte eller behandling af udtrukket tekst som kilden. |
| Billede, lyd og video | Kildebytes, mediemetadata og digest; afgrænset indlæsning, der kan genoptages, intervalstreaming og eksplicit versionerede eksterne afledninger. | Medfølgende dekodere/omkodere, indbygget videopipeline, miniaturer, udtræk af frames eller iboende mediesimilaritet. |
| Tilstand i tidsserier | Adgang til punkter, batches og intervaller, regelmæssige/uregelmæssige udstrækninger og præcis opløsning; senere i den omfattede leveranceplan: hændelsestidsvinduer, watermarks, aggregeringer og varige abonnementer. | Flere uafhængige hændelser på samme tidspunkt i én serie; brug et hændelseskort til dem. |
| Vektor-GIS | CRS-bevidste geoværdier/-features, streamet stor geometri, hvor det er nødvendigt, præcise prædikater og indekserede kandidater med præcis efterkontrol. | Distribueret geografisk udførelse eller et generelt PostGIS-kompatibelt sprog som nødudgang. |
| Raster-GIS | Kildebytes med rasterbeskrivelse, afgrænset adgang til bytes/intervaller og erklærede eksterne flise- eller oversigtsprojektioner. | Medfølgende rasterdekodning, indbygget reprojektion/opbygning af oversigter eller garanteret vilkårlig adgang til fliser fra sekventielle formater. |
| Tætte og sparse numeriske data | Afgrænsede arrays og sparse arrays; minimal lagring af float-tensorer med fast form til embeddings produceret af leverandører. | Generel tensoralgebra, modeludførelse, ONNX, træning, kvantisering eller beregning på enheder. |
Præcise udvekslingsformater, accepterede dokument- og medietyper, vektor- og rasterprofiler, leverandørversioner og sikkerhedsfixtures er fortsat beslutninger for versionen.
Driftsprofil
Skalér op først; klynge er en senere profil.
Den planlagte produktionstopologi er én server. Den kan rumme flere kundemiljøer med isolation og kvoter, men kapacitet og fejldomæne forbliver én node.
| Profil | Planlagt placering i første version | Afgrænsning |
|---|---|---|
| Indlejret | Inkluderet | Én applikationsproces med lokal lagring; ingen separat serverproces. |
| Udvikling | Inkluderet | Opstart af tomt projekt og eksplicitte kildetilstande. |
| Produktion, én server | Inkluderet | Én node. POSIX-holdbarhed først; holdbarhed og backup via objektlagring er med i versionens omfang. |
| Klynge | Udeladt · senere profil | Ingen påstand om sharding, replikering, distribueret traversering eller failover. |
| Isoleret arbejdsbelastning | Udeladt | Ingen særskilt kvalificeret driftsprofil til isolerede arbejdsbelastninger. |
Valg af driftsmiljø, fx kundens eget datacenter eller en privat cloud, er adskilt fra disse runtime-profiler.
Drift på én server
Gendannelse og kontrolleret ændring hører med i kravene til versionen.
Den planlagte produktionsprofil kombinerer varige jobs og tidsplaner med driftsdokumentation på én server. Den fremsætter ingen påstand om klynge, failover til replika eller tilgængelighed på tværs af noder.
Tag backup, gendan og opbevar
Fulde og inkrementelle backups efter tidsplan, verificeret gendannelse og gendannelse til et bestemt tidspunkt, opbevaring/TTL og juridiske tilbageholdelser er omfattede krav. En gennemført backup beviser ikke, at en applikation og dens data kan gendannes.
Observér og reagér
Observerbarhed i produktion og erklærede servicemål ville koble hændelser til den berørte applikation og version. Kun registrerede, forhåndsgodkendte typer af afhjælpning må handle inden for deres afgrænsede profil; forældede eller tilbagekaldte beføjelser skal afvise eller eskalere.
Frigiv uafhængigt
Beslutninger om canary og rollback forbliver under uafhængig kontrol. Den agent, der foreslår en reparation, kan ikke godkende udvidelsen af sine egne beføjelser, ændre sine acceptkriterier eller aktivere sin efterfølger.
Ændr det kørende system
Løbende udrulning af skemaer, kontrakter og backend er planlagt for profilen med én server. Et stabilt indbygget C ABI og en overvåget leverandørgrænse muliggør erklærede integrationer uden at tilføje det senere åbne register eller komponentværten.
Kvalificering af versionen kræver også gendannelse efter nedbrud, nul tab af kvitterede commits og vellykkede gendannelsestest under erklærede betingelser. De foreslåede taltærskler står nedenfor som test – ikke som målte resultater eller serviceniveauer.
Et eksempel, der kan afkræftes
Referencearbejdsbelastningen for en verdensomspændende tvilling.
Dette er foreslåede antagelser om arbejdsbelastningen, som afventer forfatterens ratificering og designpartneres målinger. »Verdensomspændende« beskriver emnet, ikke distribueret udførelse.
| Dimension | Foreslået referencearbejdsbelastning |
|---|---|
| Tvillingentiteter | 250.000 skibe; 5.000 havne og terminaler; 2 millioner lastenheder |
| Indlæsning af positioner | 25.000 rapporter/s vedvarende; 100.000 rapporter/s i en spidsbelastning på 60 sekunder |
| Opbevaring i fuld opløsning | 90 dage; ca. 194 milliarder målepunkter og 2 TB komprimeret |
| Opbevaring i reduceret opløsning | Ét målepunkt pr. 5 minutter op til 36 måneder; ca. 79 milliarder målepunkter og 0,8 TB |
| Hændelser og dokumenter | 5 millioner havneanløb, meddelelser og manifester om året |
| Embeddings | 768 float32-dimensioner; ca. 15 GB/år ukomprimeret |
| Grafens form | Stier for ejerskab, befragtning og operatør op til dybde 6; gennemsnitlig udgrad 4; havnenoder med op til 100.000 kanter |
| Interaktiv samtidighed | 200 personer og 50 maskinklienter |
| Hardware og hukommelse | Foreslået referencehardwareklasse med 32 vCPU; forhold mellem datasæt og RAM på ca. 24:1. RAM, leverandør og lagringsmodel er ikke specificeret. |
Tallet på 25.000 vedvarende rapporter/s beskriver denne referencearbejdsbelastning. Tallet på 100.000 vedvarende rapporter/s i acceptkriterierne er et strengere foreslået krav til versionen; 80.000 rapporter/s på den hardware er en særskilt tærskel for revurdering af omfanget.
Kapacitet og arbejdssæt
Store opbevarede historikker kræver afgrænsede operationer.
Teoretisk designberegning med ca. 10,3 komprimerede bytes pr. målepunkt peger på omkring 1–2 billioner målepunkter og op til 20 TiB pr. node. Det er ikke et målt kapacitetsresultat.
≈10,3 bytes
komprimeret pr. målepunkt: grundlaget for designberegningen
1–2 billioner
målepunkter pr. node, omtrentligt, i teoretisk designberegning
≤20 TiB
pr. node ved den tæthed; ikke et målt kapacitetsresultat
10 TiB / 16 GiB
et særskilt foreslået kvalificeringstilfælde: lagring over for installeret RAM
Et særskilt foreslået kvalificeringstilfælde bruger 10 TiB lagring med 16 GiB installeret RAM til afgrænsede forespørgsler på punkter, intervaller, sider, stikprøver og visningsudsnit. Det betyder ikke, at datakorpusset eller et helt indeks ligger i hukommelsen, eller at alle globale forespørgsler er interaktive.
Ved det strengere acceptkriterium på 100.000 rapporter/s ville 90 dages målepunkter i fuld opløsning udgøre ca. 0,78 billioner målepunkter og 8 TB. Tolv måneder ville udgøre ca. 3,2 billioner og 32 TB – ud over det foreslåede designcentrum for én node. Længere opbevaring ville kræve reduceret opløsning eller en senere klyngeprofil. Fuld eksport, global sortering og genopbygning af hele indekset forbliver streaming- eller varigt jobarbejde.
Nitten kontrakter
Versionsadfærden skal være eksplicit før frigivelse.
Før 1.0 er det kun stabile, tildelte identifikatorer, der aldrig genbruges. Alle andre forpligtelser for 1.x er hensigter for versionen, og flere detaljer er endnu ikke besluttet.
| Dimension | Før 1.0 | Tilsigtet adfærd i 1.x eller åben beslutning |
|---|---|---|
| Kildesprog | Intet løfte om kompatibilitet i 1.x før 1.0. | Grammatikken i 1.0 er fastfrosset; kildekode, som 1.0 accepterer, accepteres også af senere 1.x-versioner. |
| Beskrivelser og katalog | Stabile id’er for typer, felter og andre tildelte id’er genbruges aldrig. | En senere 1.x-version læser beskrivelser skrevet af tidligere 1.x-versioner. |
| Bytekode og planer | Intet generelt løfte om kompatibilitet. | Fysiske planer genopbygges ved opgradering. Varige jobs fastlåser en udførelsesreference; en nyere runtime læser, migrerer, genafspiller eksplicit eller afviser. Vilkårlige checkpoints er ikke portable. |
| Afkodning af lagring | Intet generelt løfte om kompatibilitet. | Senere versioner bevarer dekodere til 1.x-blokke, der stadig refereres til. |
| Skrivning til lagring | Intet generelt løfte om kompatibilitet. | Bagudlæsning erklæres pr. format. Nedgradering loves ikke. |
| Protokol og API | Intet generelt løfte om kompatibilitet. | Kun tilføjelser inden for 1.x; ændringer, der bryder kompatibiliteten, kræver en ny hovedversion af tjenesten. |
| Genereret klient | Intet generelt løfte om kompatibilitet. | En klient genereret til 1.x kan kompileres mod senere 1.x-servere. |
| Deklarativ frontend | Intet generelt løfte om kompatibilitet. | Typer af beskrivelser udvides kun med tilføjelser inden for 1.x. |
| Pakker og komponenter | Intet generelt løfte om kompatibilitet. | Bevarede dekodere, låse og udvalgte grænseflader til indbyggede leverandører udvides kompatibelt. Et åbent register og en komponentvært er senere arbejde. |
| Løbende opgradering af klynge | Ikke relevant. | Ikke relevant: ingen klyngeprofil i 1.0. |
| Backup og gendannelse | Intet generelt løfte om kompatibilitet. | En senere 1.x-version gendanner backups fra tidligere 1.x-versioner og rapporterer et verificeret gendannelsesresultat. |
| Driftskonfiguration | Intet generelt løfte om kompatibilitet. | Kun tilføjelser inden for 1.x; fjernelse kræver en version, der først udfaser. |
| Adapter til AI-leverandør | Intet generelt løfte om kompatibilitet. | Det portable chatskema og worker-protokollen udvides kompatibelt. Præcise leverandørartefakter fastlåser deres egne versioner, retninger og kapabiliteter. Ingen leverandørs model eller funktion er underforstået. |
| Arbejdsområde for agenter og MCP | Supportperioden er endnu ikke valgt. | Versionsretninger, forhandling og fejladfærd kræver en beslutning for versionen. |
| Agentsession og vejledning | Supportperioden er endnu ikke valgt. | Versionsretninger og checkpoint-adfærd kræver en beslutning for versionen. |
| Versioneret AI-skill | Supportperioden er endnu ikke valgt. | Begge retninger og fejladfærd kræver en beslutning for versionen. |
| Virkninger af offentlige funktioner | Intet generelt løfte om kompatibilitet. | At tilføje en virkning bryder den offentlige funktionskontrakt og kræver en ny hovedversion af tjenesten; det giver aldrig beføjelser i sig selv. |
| Konsistenstoken | Supportperioden er endnu ikke valgt. | Tokenet er med i tjenesteomfanget for første version; kompatibilitetskontrakten for det kræver en beslutning for versionen. |
| Lokaliserede beskeder og kataloger | Stabile id’er for beskeder, kataloger og profiler genbruges aldrig. | Offentlige nøgler og typede argumenter udvides kompatibelt; beskeder, der refereres til, kan fortsat læses. Sprogindstillinger, standarder og supportperioder for kataloger er fortsat åbne. |
Versionens supportmatrix skal for hver række angive både læse- og skriveretning, understøttede perioder, forhandling og fejl. Der er ingen underforstået garanti for nedgradering eller portabilitet af vilkårlige checkpoints.
Afgrænset chat og lokal AI
Hver leverandør kræver sin egen dokumentation.
Den planlagte leverandørneutrale chatkontrakt dækker indhold, beskeder, hændelser, værktøjer, struktureret output og varige registreringer af sessioner og kørsler. Modelspecifikke kapabiliteter arves aldrig fra navnet på et generisk endpoint.
| Planlagt binding i første version | Grænse for kvalificering |
|---|---|
| Deterministisk testleverandør | Påkrævet til reproducerbare test. |
| Direkte OpenAI Responses | Et præcist leverandørartefakt og en fastlåst matrix over kapabiliteter/kontrakter; ingen leverandørs model loves. |
| Anthropic Messages | Et præcist leverandørartefakt og en fastlåst matrix over kapabiliteter/kontrakter. |
| Indbygget Ollama | Kvalificeret mod sin egen kontrakt, ikke mod sin OpenAI-kompatible flade. |
| Afgrænset OpenAI-kompatibelt endpoint | Typet endpoint-binding med afprøvede kapabiliteter; den påstår ikke at være OpenAI. |
| Eksternt administreret runtime på samme maskine | Kun afgrænsede krav til ressourcer for Cygnus-klienten; den eksterne runtime tælles ikke med i Cygnus’ frie kapacitet. |
| Certificeret lokal llama.cpp administreret af Cygnus | CPU-variant påkrævet; CUDA kun, hvis den er kvalificeret. Præcis model, tokenizer, runtime, enhed, konfiguration og ressourceramme kræver et signeret certifikat. |
Eksterne eller uafhængigt drevne lokale endpoints arver ikke garantierne for RAM/VRAM i den administrerede lokale profil. Indbygget modelberegning, brede leverandørspecifikke agenter, automatisk fallback og ubegrænset brug af AI ligger uden for denne profil. Leverandør- og produktnavne identificerer kun grænseflader; de indebærer hverken partnerskab eller anbefaling.
Femogtyve acceptkriterier
Frigivelse kræver målt dokumentation på tværs af hele systemet.
Intet kriterium nedenfor påstås at være bestået. Tallene gælder for erklærede betingelser for arbejdsbelastning, hardware og konsistens; skal-krav og bør-krav holdes adskilt: 22 kriterier skal bestås, 2 bør bestås.
| Kriterium · krævet dokumentation | Foreslået tærskel | Krav · status |
|---|---|---|
| 01 Designpartnere i produktion med en arbejdsbelastning formet som referencen | Mindst 3 | Skal beståsEndnu ikke bestået |
| 02 Autoritativt produktionssystem med opbevaret historik | Mindst 1 med mindst 6 måneders historik | Skal beståsEndnu ikke bestået |
| 03 Vedvarende indlæsning af positioner på den foreslåede referencehardwareklasse med 32 vCPU og transaktionel konsistens i indeks | Mindst 100.000 rapporter/s | Skal beståsEndnu ikke bestået |
| 04 Absorbering af spidsbelastning uden frasortering eller ubegrænset køvækst | 100.000 rapporter/s i 60 sekunder | Skal beståsEndnu ikke bestået |
| 05 Skibe inden for en polygon blandt 250.000 live-positioner | p99 højst 150 ms | Skal beståsEndnu ikke bestået |
| 06 Læsning af ét skibs spor over 90 dage | p99 højst 250 ms | Skal beståsEndnu ikke bestået |
| 07 Hybrid sparse og dense top-20-søgning i 5 millioner dokumenter | p99 højst 300 ms | Skal beståsEndnu ikke bestået |
| 08 Læsning af en tvillings naboskab, dybde 3 og højst 500 noder | p99 højst 50 ms | Bør beståsEndnu ikke bestået |
| 09 Korrekthed ved out-of-core-drift uden ubegrænset hukommelsesvækst | Datasæt mindst 24 gange RAM | Skal beståsEndnu ikke bestået |
| 10 Overhead ved autorisation på elementniveau sammenlignet med grovkornet politik | Højst 2 gange | Skal beståsEndnu ikke bestået |
| 11 Gendannelsespunkt for kvitterede commits på én server | Nul kvitterede commits tabt | Skal beståsEndnu ikke bestået |
| 12 Genstart med et datasæt på 3 TiB | Autoritative skrivninger genoptages inden for 20 sekunder | Skal beståsEndnu ikke bestået |
| 13 Planlagte test af verificeret gendannelse i frigivelsesvinduet | 100 % bestået | Skal beståsEndnu ikke bestået |
| 14 Gendannelse efter nedbrud ved hvert commit-trin | 100 % af testene bestået | Skal beståsEndnu ikke bestået |
| 15 Agentevalueringer af tomme projekter uden menneskelig reparation | Mindst 70 % lykkes inden for erklærede budgetter | Skal beståsEndnu ikke bestået |
| 16 Fra tomt projekt til udrullet, autoriseret læse-/skrivefunktion for en tvilling med genereret TypeScript-klient og formular | Højst 30 minutter, agentdrevet | Bør beståsEndnu ikke bestået |
| 17 Obligatoriske overensstemmelsestest for hver omfattet profil | 100 % bestået | Skal beståsEndnu ikke bestået |
| 18 Fastfrosne specifikationer og minimale overensstemmelsestest | Kernesubstrat, stabile identitetsbeskrivelser og trussels-/sikkerhedskerne; modalitetsbeskrivelser, sprog, projekt, mellemrepræsentation, planer, skema, lagring, transaktioner, strømme, pakkelås, lokalisering og kerneværktøjer; tjenester, MCP, features, UI, genereret TypeScript, udrulningspakker, ændringsfeeds og fuld sikkerhed; søgning og hændelsestid; guidet MCP, fastfrosset feature-projektion, lokalisering af Explorer, LSP og headless debugging; drift på én server, grænseflade til indbyggede leverandører og afgrænset chat. Trusselsmodellen gennemgås igen ved hvert omfattet kriterium. | Skal beståsEndnu ikke bestået |
| 19 Eksempler i dokumentationen køres som test | 100% | Skal beståsEndnu ikke bestået |
| 20 Baselines for ydelsesregression med ejere | Hver benchmark for kritiske stier | Skal beståsEndnu ikke bestået |
| 21 Komplet support- og kompatibilitetsmatrix | Præcise formater, profiler for dokumenter/medier/raster/leverandører, sprogindstillinger og kataloger valgt; alle 19 dimensioner angiver begge retninger, perioder, forhandling og fejl; ingen åbne felter | Skal beståsEndnu ikke bestået |
| 22 Identitet i produktion og kryptografisk aktivering | Kvalificeret ekstern nøgleleverandør og revideret ceremoni for den første administrator; ingen fallback til udviklings-/filleverandør | Skal beståsEndnu ikke bestået |
| 22 Rapportering af sikkerhedsfund og frigivelsesdrift | Overvåget kontaktpunkt, offentlig krypteringsnøgle, security.txt, proces for sikkerhedsmeddelelser, supportkalender og afprøvede roller for frigivelse/rollback | Skal beståsEndnu ikke bestået |
| 24 Komplet accept af den afgrænsede chat | Accept af kerne, alle fem leverandøradaptere, MCP, viden, eksternt administreret lokal drift, certificeret administreret lokal CPU-drift, bibliotek og minimumsressourcer | Skal beståsEndnu ikke bestået |
| 25 Bibliotekskatalog for første version | Hvert påkrævet medlem har en godkendt, moden version; anbefalede medlemmer består eller oplyser en efterfølger og en afvigelse | Skal beståsEndnu ikke bestået |
Kravet om 100.000 rapporter/s på den foreslåede hardwareklasse med 32 vCPU er adskilt fra et sværere teknisk mål på en mindre, uspecificeret hardwareklasse. Kriterierne for sikkerhed, identitet, leverandører, dokumentation og supportmatrix er lige så nødvendige som gennemløb.
Endnu ikke valgt
En versionsmatrix er en del af versionen.
De præcise versioner for dokumenter, medier, raster, vektor, masseudveksling og leverandører, sprogindstillinger i produktion, katalogperioder og flere kompatibilitetsretninger for agenter/sessioner/skills/tokens er fortsat åbne. De skal vælges og kvalificeres før 1.0.
Priser, licensering, kommerciel pakning, finansiering af leverandører, tidsplaner og leveringsdatoer er heller ikke valgt. Et foreslået mål er en test, der skal køres, ikke en forpligtelse over for kunder.
Udforsk videre
Tal med vores team
Tag en arbejdsbelastning med, hvor sømmene gør ondt.
Relationer, historik, placering og søgning, der skal fungere sammen: Vi holder det op mod den planlagte afgrænsning af første version og fortæller dig ærligt, hvor det passer.
Eller skriv til contact@natusai.com
