Kärna och tjänster
Typat språk och exekvering, transaktionell lagring av graf och tidsserier, autentisering och behörighetskontroll i lagringsvägen, typade HTTP/RPC- och strömningstjänster, genererad TypeScript-klient, API- och MCP-deskriptorer.
Cygnus 1.0 är en planerad release av en programmerbar temporal grafdatabas, knuten till acceptanskrav. Omfattningen nedan är en design- och kvalificeringsplan; inget releasekrav och inget prestandamål presenteras som uppnått.
Status: Cygnus 1.0 har varken godkänts eller släppts. Belägg för ingående förmågor, säkerhet, dokumentation, kompatibilitet, driftsättning och återställning måste alla godkännas före en offentlig release.

Den planerade releasen samlar språk, körmiljö, lagring och tjänster under en semantisk modell. En kandidatimplementation är inte en offentlig release.
Typat språk och exekvering, transaktionell lagring av graf och tidsserier, autentisering och behörighetskontroll i lagringsvägen, typade HTTP/RPC- och strömningstjänster, genererad TypeScript-klient, API- och MCP-deskriptorer.
De sju avgränsade modalitetsprofilerna nedan, grafnavigering, geospatial indexering, text/BM25 och gles/tät hämtning, tidsfönster, aggregeringar och beständiga prenumerationer.
En utvald Explorer-yta, fem fastlåsta applikationsmönster för tvillingar, telemetri, händelseloggar, geospår och resurs-CRUD; LSP-kärna, VS Code-klient och avgränsad headless-felsökning.
Beständiga jobb och schemaläggning, observerbarhet på en server, säkerhetskopiering, återställning till valfri tidpunkt och verifierad återställning; ett avgränsat chattkontrakt med kvalificering av exakt fastställda leverantörsversioner och oberoende styrd åtgärdning.
Beroendeordning: kärna → tjänstekontrakt och säkerhet → temporala, rumsliga och hämtningsbara data → utvalda Explorer- och agentverktyg → drift på en server och avgränsad chatt. Data och säkra tjänster kommer före det större gränssnittet för agenter.
Det här är planerade krav för den första versionen med separata krav på överensstämmelse och säkerhet, inte ett påstående om att varje yta finns tillgänglig i dag.
Typade HTTP/RPC- och strömningsoperationer, ändringsflöden, genererade TypeScript-klienter och versionerade tjänstebeskrivningar för API och MCP. En Blob-baserad förvaltad filtjänst skulle ge transaktionella virtuella kataloger och avgränsad överföring, utan implicit parsning eller åtkomst till värdens filsystem.
En besluts- och godkännandekö i egen regi skulle bevara auktoritativa mänskliga val bortom en agentsession. Ett agentförslag och dess belägg hålls åtskilda från behörigheten att aktivera det.
Den inbyggda grunden omfattar språktaggar, presentationssammanhang, typade meddelanden och katalogidentitet samt avgränsad formatering. Servern och genererade TypeScript-klienter måste vara överens om fastställda kataloger; exakta språkinställningar för produktion och supportperioder är fortfarande öppna.
Den utvalda autentiserade Explorer-ytan omfattar Översikt, Data/graf, Aktivitet/loggar, Funktioner/API/MCP, Åtkomst och kvalificerad konfiguration av chatt och leverantörer. Lokaliseringen måste klara kontroller av typade argument, RTL, pseudospråk, tillgänglighet, fientliga översättningar och paritet mellan server och klient. LSP-kärnan, den tunna VS Code-klienten och det avgränsade kontraktet för headless-felsökning är obligatoriska; en integration med Debug Adapter Protocol i editorn är uppskjuten.
De fem fastlåsta applikationsmönstren är tvillingentitet, telemetriserie, händelselogg, geospår och resurs-CRUD. Ett generellt deklarativt UI-system eller en språkkörmiljö i webbläsaren ingår inte i den första versionen.
Det här är arkitekturkrav för den planerade releasen, med förbehåll för kvalificering av överensstämmelse och säkerhet.
Bitemporal åtkomst skiljer på när ett faktum var giltigt och när det kom in i systemet. Ett svar per tidpunkt (as-of) ska kunna återskapas mot båda, inklusive senare korrigeringar.
Strikt serialiserbara transaktioner med finkornig logisk konfliktdetektering är avsedda att hålla ändringar i entiteter, graf, tid och deklarerade transaktionella index eller härledda resurser inom en och samma commit-epok.
Åtkomstkontroller hör hemma i lagrings- och exekveringsvägarna, inklusive indexsökningar, traverseringar och aggregeringar. Upptäckt är skild från läsåtkomst; nekade resurser får inte läcka via antal, felmeddelanden eller tecken på att de finns. Behörighetskontrollen för sökning sker före rankning och top-k-urval.
En deklarerad effekt för en offentlig funktion beskriver möjligt beteende; den ger aldrig i sig behörighet. Hämtat innehåll och modellens utdata förblir otillförlitliga när en agent föreslår en verktygsåtgärd.
Lagrade källor behåller avgränsad åtkomst, versionerade deskriptorer, klassificering, ursprung, lagringstid och behörighet. Härledd text, rutor eller inbäddningar versioneras uttryckligen och blir aldrig i tysthet originalet.
| Modalitet | Planerad representation i första versionen | Utanför anspråken för första versionen |
|---|---|---|
| Text | Avgränsade UTF-8-strängar; stora UTF-8-texter som strömmade eller intervallästa blobbar; text/BM25-index med versionerade analysatorer. | Universell reparation av teckenkodning, implicit normalisering som ändrar källan eller obegränsad materialisering av strängar. |
| Dokument | Auktoritativa källbyte med metadata och ursprung; uttryckliga text- och segmentderivat kan tillhandahållas eller tas fram av en deklarerad extern leverantör. | Universell parsning av PDF- och Office-filer, OCR i tysthet eller att extraherad text behandlas som källan. |
| Bild, ljud och video | Källbyte, mediemetadata och kontrollsumma; återupptagbar avgränsad inläsning, strömning av intervall och uttryckligen versionerade externa derivat. | Medföljande avkodare/omkodare, inbyggd videopipeline, miniatyrbilder, extrahering av bildrutor eller inbyggd likhetsbedömning av media. |
| Tidsserietillstånd | Åtkomst per punkt, batch och intervall, regelbundna/oregelbundna omfång och exakt upplösning; senare i den ingående leveranssekvensen händelsetidsfönster, vattenmärken, aggregeringar och beständiga prenumerationer. | Flera oberoende händelser vid samma ögonblick i en och samma serie; använd en händelsekarta för sådana. |
| Vektor-GIS | CRS-medvetna geovärden/geoobjekt, strömmad stor geometri vid behov, exakta predikat och indexerade kandidater med exakt omkontroll. | Distribuerad rumslig exekvering eller ett generellt PostGIS-kompatibelt reservspråk. |
| Raster-GIS | Källbyte med rasterdeskriptor, avgränsad åtkomst per byte/intervall och deklarerade externa projektioner av rutor eller översiktsnivåer. | Medföljande rasteravkodning, inbyggd omprojicering/byggande av översiktsnivåer eller garanterad slumpmässig åtkomst till rutor i sekventiella format. |
| Täta och glesa numeriska data | Avgränsade arrayer och glesa arrayer; minimal lagring av flyttalstensorer med fast form för inbäddningar som tas fram av leverantörer. | Generell tensoralgebra, modellkörning, ONNX, träning, kvantisering eller beräkning på särskild hårdvara. |
Exakta utbytesformat, godtagna dokument- och medietyper, vektor- och rasterprofiler, leverantörsversioner och säkerhetsfixturer är fortfarande releasebeslut.
Den planerade produktionstopologin är en server. Den kan rymma flera kunder med isolering och kvoter, men dess kapacitet och feldomän är fortfarande en nod.
| Profil | Planerad position i första versionen | Avgränsning |
|---|---|---|
| Inbäddad | Ingår | En applikationsprocess med lokal lagring; ingen separat serverprocess. |
| Utveckling | Ingår | Uppstart från tomt projekt och explicita källlägen. |
| Produktion, en server | Ingår | En nod. POSIX-beständighet först; beständighet i objektlagring och stöd för säkerhetskopiering ingår i releaseomfattningen. |
| Kluster | Ingår inte · senare profil | Inga anspråk på sharding, replikering, distribuerad traversering eller failover. |
| Isolerad arbetslast | Ingår inte | Ingen separat kvalificerad driftprofil för isolerade arbetslaster. |
Val av driftmiljö, till exempel kundens datacenter eller ett privat moln, är skilda från de här driftprofilerna för körmiljön.
Den planerade produktionsprofilen kombinerar beständiga jobb och schemaläggning med driftbelägg på en server. Den gör inga anspråk på kluster, failover mellan repliker eller tillgänglighet över flera noder.
Schemalagda fullständiga och inkrementella säkerhetskopior, verifierad återställning och återställning till valfri tidpunkt, lagringstid/TTL och bevarandebeslut av rättsliga skäl är krav som ingår. En slutförd säkerhetskopiering bevisar inte att en applikation och dess data kan återställas.
Observerbarhet i produktion och deklarerade tjänstemål skulle koppla incidenter till den berörda applikationen och releasen. Endast registrerade, förhandsgodkända åtgärdsklasser får agera inom sin avgränsade profil; inaktuella eller återkallade befogenheter ska leda till vägran eller eskalering.
Beslut om canary-releaser och återställning till tidigare version förblir under oberoende kontroll. Den agent som föreslår en reparation kan inte godkänna utökning av sina egna befogenheter, ändra sina acceptanskriterier eller aktivera sin efterträdare.
Rullande driftsättning av scheman, kontrakt och backend är planerad för profilen med en server. Ett stabilt inbyggt C ABI och en övervakad leverantörsgräns möjliggör deklarerade integrationer utan att det senare öppna registret eller komponentvärden behöver läggas till.
Releasekvalificeringen kräver också kraschåterställning, noll förlorade bekräftade commits och lyckade återställningstester under deklarerade förhållanden. De föreslagna numeriska tröskelvärdena visas nedan som tester, inte som uppmätta resultat eller servicenivåer.
Det här är föreslagna antaganden om arbetslasten som ännu ska fastställas av upphovspersonen och mätas hos designpartner. ”Global” beskriver ämnesområdet, inte distribuerad exekvering.
| Dimension | Föreslagen referensarbetslast |
|---|---|
| Tvillingentiteter | 250 000 fartyg; 5 000 hamnar och terminaler; 2 miljoner lastenheter |
| Inläsning av positioner | 25 000 rapporter/s uthålligt; 100 000 rapporter/s under en topp på 60 sekunder |
| Lagring med full upplösning | 90 dagar; cirka 194 miljarder mätpunkter och 2 TB komprimerat |
| Lagring med nedsampling | En mätpunkt per 5 minuter upp till 36 månader; cirka 79 miljarder mätpunkter och 0,8 TB |
| Händelser och dokument | 5 miljoner hamnanlöp, meddelanden och manifest per år |
| Inbäddningar | 768 float32-dimensioner; cirka 15 GB/år okomprimerat |
| Grafens form | Vägar för ägarskap, befraktning och operatör till djup 6; genomsnittlig utgrad 4; hamnnoder med upp till 100 000 kanter |
| Interaktiv samtidighet | 200 personer och 50 maskinklienter |
| Hårdvara och minne | Föreslagen referensklass för hårdvara med 32 vCPU; förhållande mellan datamängd och RAM på cirka 24:1. RAM, leverantör och lagringsmodell är inte specificerade. |
Siffran 25 000 rapporter/s uthålligt beskriver den här referensarbetslasten. Siffran 100 000 rapporter/s uthålligt i acceptanskraven är ett strängare föreslaget releasekrav; 80 000 rapporter/s på den hårdvaran är ett separat tröskelvärde för omprövning av omfattningen.
Teoretisk designaritmetik med cirka 10,3 komprimerade byte per mätpunkt pekar på ungefär 1–2 biljoner mätpunkter och upp till 20 TiB per nod. Det är inte ett uppmätt kapacitetsresultat.
≈10,3 byte
komprimerat per mätpunkt: grunden för designaritmetiken
1–2 biljoner
mätpunkter per nod, ungefär, enligt teoretisk designaritmetik
≤20 TiB
per nod vid den tätheten; inte ett uppmätt kapacitetsresultat
10 TiB / 16 GiB
ett separat föreslaget kvalificeringsfall: lagring jämfört med installerat RAM
Ett separat föreslaget kvalificeringsfall använder 10 TiB lagring med 16 GiB installerat RAM för avgränsade frågor per punkt, intervall, sida, urval och vy. Det innebär inte att hela korpusen eller ett helt index ligger i minnet, eller att varje global fråga är interaktiv.
Vid det strängare releasekravet på 100 000 rapporter/s skulle 90 dagars mätpunkter med full upplösning bli cirka 0,78 biljoner mätpunkter och 8 TB. Tolv månader skulle bli cirka 3,2 biljoner och 32 TB, bortom det föreslagna designområdet för en nod. Längre lagring skulle kräva nedsampling eller en senare klusterprofil. Fullständig export, global sortering och ombyggnad av hela index förblir strömmande arbete eller beständiga jobb.
Före 1.0 gäller bara att stabila tilldelade identifierare aldrig återanvänds. Alla andra åtaganden för 1.x är releaseavsikter, och flera detaljer är ännu inte bestämda.
| Dimension | Före 1.0 | Avsett beteende i 1.x eller öppet beslut |
|---|---|---|
| Källspråk | Inget löfte om kompatibilitet i 1.x före 1.0. | Grammatiken i 1.0 är fastlåst; källkod som godtas av 1.0 godtas även av senare 1.x. |
| Deskriptorer och katalog | Stabila id:n för typer, fält och andra tilldelningar återanvänds aldrig. | En senare 1.x läser deskriptorer som skrivits av tidigare 1.x-releaser. |
| Bytekod och planer | Inget generellt löfte om kompatibilitet. | Fysiska planer byggs om vid uppgradering. Beständiga jobb låser en exekveringsreferens; en nyare körmiljö läser, migrerar, spelar uttryckligen upp igen eller vägrar. Godtyckliga kontrollpunkter är inte portabla. |
| Avkodning av lagring | Inget generellt löfte om kompatibilitet. | Senare releaser behåller avkodare för 1.x-block som fortfarande refereras. |
| Skrivning till lagring | Inget generellt löfte om kompatibilitet. | Bakåtläsning deklareras per format. Nedgradering utlovas inte. |
| Protokoll och API | Inget generellt löfte om kompatibilitet. | Endast tillägg inom 1.x; bakåtinkompatibla ändringar kräver en ny huvudversion av tjänsten. |
| Genererad klient | Inget generellt löfte om kompatibilitet. | En klient som genererats för 1.x kompilerar mot senare 1.x-servrar. |
| Deklarativ frontend | Inget generellt löfte om kompatibilitet. | Deskriptortyper utökas endast med tillägg inom 1.x. |
| Paket och komponenter | Inget generellt löfte om kompatibilitet. | Behållna avkodare, lås och utvalda gränssnitt för inbyggda leverantörer utökas kompatibelt. Ett öppet register och en komponentvärd är senare arbete. |
| Rullande uppgradering av kluster | Ej tillämpligt. | Ej tillämpligt: ingen klusterprofil i 1.0. |
| Säkerhetskopiering och återställning | Inget generellt löfte om kompatibilitet. | En senare 1.x återställer säkerhetskopior från tidigare 1.x och rapporterar ett verifierat återställningsresultat. |
| Driftkonfiguration | Inget generellt löfte om kompatibilitet. | Endast tillägg inom 1.x; borttagning kräver en release med utfasning. |
| Adapter för AI-leverantörer | Inget generellt löfte om kompatibilitet. | Det portabla chattschemat och arbetarprotokollet utökas kompatibelt. Exakta leverantörsartefakter låser sina egna versioner, riktningar och förmågor. Ingen leverantörs modell eller funktion utlovas. |
| Agent- och MCP-arbetsyta | Supportperioden återstår att välja. | Versionsriktningar, förhandling och felbeteende kräver ett releasebeslut. |
| Agentsession och vägledning | Supportperioden återstår att välja. | Versionsriktningar och beteende för kontrollpunkter kräver ett releasebeslut. |
| Versionerad AI-skill | Supportperioden återstår att välja. | Båda riktningarna och felbeteendet kräver ett releasebeslut. |
| Effekter för offentliga funktioner | Inget generellt löfte om kompatibilitet. | Att lägga till en effekt bryter kontraktet för den offentliga funktionen och kräver en ny huvudversion av tjänsten; det ger aldrig i sig befogenheter. |
| Konsistenstoken | Supportperioden återstår att välja. | Token ingår i tjänsteomfattningen för den första versionen; dess kompatibilitetskontrakt kräver ett releasebeslut. |
| Lokaliserade meddelanden och kataloger | Stabila id:n för meddelanden, kataloger och profiler återanvänds aldrig. | Offentliga nycklar och typade argument utökas kompatibelt; refererade meddelanden behåller sina läsare. Språkinställningar, standardvärden och supportperioder för kataloger är fortfarande öppna. |
Releasens supportmatris måste ange både läs- och skrivriktning, supportperioder, förhandling och felbeteende för varje rad. Ingen garanti om nedgradering eller portabilitet för godtyckliga kontrollpunkter utlovas.
Det planerade leverantörsneutrala chattkontraktet omfattar innehåll, meddelanden, händelser, verktyg, strukturerad utdata och beständiga poster för sessioner och körningar. Modellspecifika förmågor ärvs aldrig från ett generiskt namn på en slutpunkt.
| Planerad bindning i första versionen | Kvalificeringsgräns |
|---|---|
| Deterministisk simulerad leverantör | Krävs för reproducerbara tester. |
| Direkt OpenAI Responses | En exakt leverantörsartefakt och en fastställd matris för förmågor och kontrakt; ingen leverantörs modell utlovas. |
| Anthropic Messages | En exakt leverantörsartefakt och en fastställd matris för förmågor och kontrakt. |
| Inbyggd Ollama | Kvalificeras mot sitt inbyggda kontrakt, inte mot sitt OpenAI-kompatibla gränssnitt. |
| Avgränsad OpenAI-kompatibel slutpunkt | Typad slutpunktsbindning med testade förmågor; den utger sig inte för att vara OpenAI. |
| Externt förvaltad körmiljö på samma värd | Endast avgränsade resursanspråk för Cygnus-klienten; den externa körmiljön räknas inte som marginal för Cygnus. |
| Certifierad lokal llama.cpp som förvaltas av Cygnus | CPU-variant krävs; CUDA endast om den kvalificerats. Exakt modell, tokeniserare, körmiljö, enhet, konfiguration och resursram kräver ett signerat certifikat. |
Externa eller oberoende drivna lokala slutpunkter ärver inte garantierna för RAM/VRAM i den förvaltade lokala profilen. Inbyggd modellberäkning, breda leverantörsspecifika agenter, automatisk reservlösning och obegränsad AI-användning ligger utanför den här profilen. Leverantörs- och produktnamn anger endast gränssnitt; de innebär inget partnerskap eller stöd.
Inget av kraven nedan påstås vara uppfyllt. Siffrorna gäller deklarerade förhållanden för arbetslast, hårdvara och konsistens; ”måste” och ”bör” hålls åtskilda: 22 krav måste uppfyllas, 2 bör uppfyllas.
| Krav · belägg som krävs | Föreslaget tröskelvärde | Kravnivå · status |
|---|---|---|
| 01 Designpartner i produktion som kör en arbetslast med referensens form | Minst 3 | Måste uppfyllasÄnnu inte uppfyllt |
| 02 Produktionssystem för primärdata med bevarad historik | Minst 1 med minst 6 månaders historik | Måste uppfyllasÄnnu inte uppfyllt |
| 03 Uthållig inläsning av positioner på den föreslagna referensklassen för hårdvara med 32 vCPU, med transaktionell indexkonsistens | Minst 100 000 rapporter/s | Måste uppfyllasÄnnu inte uppfyllt |
| 04 Hantering av toppar utan bortfall eller obegränsad kötillväxt | 100 000 rapporter/s i 60 sekunder | Måste uppfyllasÄnnu inte uppfyllt |
| 05 Fartyg inom en polygon bland 250 000 aktuella positioner | p99 högst 150 ms | Måste uppfyllasÄnnu inte uppfyllt |
| 06 Läsning av ett enskilt fartygs spår över 90 dagar | p99 högst 250 ms | Måste uppfyllasÄnnu inte uppfyllt |
| 07 Hybrid gles och tät hämtning av topp 20 över 5 miljoner dokument | p99 högst 300 ms | Måste uppfyllasÄnnu inte uppfyllt |
| 08 Läsning av en tvillings grannskap, djup 3 och högst 500 noder | p99 högst 50 ms | Bör uppfyllasÄnnu inte uppfyllt |
| 09 Korrekthet out-of-core utan obegränsad minnestillväxt | Datamängd minst 24 gånger RAM | Måste uppfyllasÄnnu inte uppfyllt |
| 10 Merkostnad för behörighet på elementnivå jämfört med grovkornig policy | Högst 2 gånger | Måste uppfyllasÄnnu inte uppfyllt |
| 11 Återställningspunkt för bekräftade commits på en server | Noll förlorade bekräftade commits | Måste uppfyllasÄnnu inte uppfyllt |
| 12 Omstart med en datamängd på 3 TiB | Auktoritativa skrivningar återupptas inom 20 sekunder | Måste uppfyllasÄnnu inte uppfyllt |
| 13 Schemalagda tester av verifierad återställning under releasefönstret | 100 % godkända | Måste uppfyllasÄnnu inte uppfyllt |
| 14 Kraschåterställning i varje commit-steg | 100 % av testerna godkända | Måste uppfyllasÄnnu inte uppfyllt |
| 15 Agentutvärderingar från tomt projekt utan mänsklig reparation | Minst 70 % lyckas inom deklarerade budgetar | Måste uppfyllasÄnnu inte uppfyllt |
| 16 Från tomt projekt till driftsatt, behörighetsstyrd läs- och skrivfunktion för tvillingen med genererad TypeScript-klient och formulär | Högst 30 minuter, agentdrivet | Bör uppfyllasÄnnu inte uppfyllt |
| 17 Obligatoriska sviter för överensstämmelse för varje ingående profil | 100 % godkända | Måste uppfyllasÄnnu inte uppfyllt |
| 18 Fastlåsta specifikationer och minimisviter för överensstämmelse | Kärnsubstrat, stabila identitetsdeskriptorer och kärna för hot och säkerhet; modalitetsdeskriptorer, språk, projekt, mellanrepresentation, planer, schema, lagring, transaktioner, strömmar, paketlås, lokalisering och kärnverktyg; tjänster, MCP, funktioner, UI, genererad TypeScript, driftpaket, ändringsflöden och full säkerhet; sökning och händelsetid; guidad MCP, fastlåst funktionsprojektion, lokalisering av Explorer, LSP och headless-felsökning; drift på en server, gränssnitt för inbyggda leverantörer och avgränsad chatt. Hotmodellen ses över vid varje ingående krav. | Måste uppfyllasÄnnu inte uppfyllt |
| 19 Dokumentationsexempel körs som tester | 100% | Måste uppfyllasÄnnu inte uppfyllt |
| 20 Baslinjer för prestandaregression med ansvariga | Varje prestandatest för kritiska vägar | Måste uppfyllasÄnnu inte uppfyllt |
| 21 Fullständig support- och kompatibilitetsmatris | Exakta format, profiler för dokument, media, raster och leverantörer, språkinställningar och kataloger valda; alla 19 dimensioner anger båda riktningarna, perioder, förhandling och felbeteende; inga öppna celler | Måste uppfyllasÄnnu inte uppfyllt |
| 22 Produktionsidentitet och kryptografisk aktivering | Kvalificerad extern nyckelleverantör och granskad ceremoni för den första administratören; ingen reservlösning med utvecklings- eller filleverantör | Måste uppfyllasÄnnu inte uppfyllt |
| 22 Rapportering av säkerhetsbrister och releasedrift | Bevakad kontaktväg, offentlig krypteringsnyckel, security.txt, väg för säkerhetsmeddelanden, supportkalender och inövade roller för release och återställning till tidigare version | Måste uppfyllasÄnnu inte uppfyllt |
| 24 Fullständigt godkännande av avgränsad chatt | Godkännande av kärna, alla fem leverantörsadaptrar, MCP, kunskap, externt förvaltad lokal körning, certifierad förvaltad lokal CPU-körning, bibliotek och resursgolv | Måste uppfyllasÄnnu inte uppfyllt |
| 25 Bibliotekskatalog för första versionen | Varje obligatorisk komponent har en godkänd mogen release; rekommenderade komponenter klarar kraven eller anger en efterträdare och avvikelse | Måste uppfyllasÄnnu inte uppfyllt |
Releasekravet på 100 000 rapporter/s på den föreslagna hårdvaruklassen med 32 vCPU är skilt från ett svårare tekniskt mål på en mindre, ospecificerad hårdvaruklass. Krav på säkerhet, identitet, leverantörer, dokumentation och supportmatris är lika nödvändiga som genomströmning.
De exakta versionerna för dokument, media, raster, vektorer, massutbyte och leverantörer, språkinställningar för produktion, katalogperioder och flera kompatibilitetsriktningar för agenter, sessioner, skills och token är fortfarande öppna. De måste väljas och kvalificeras före 1.0.
Priser, licensiering, kommersiell paketering, finansiering av leverantörer, tidsplaner och leveransdatum är inte heller valda. Ett föreslaget mål är ett test som ska köras, inte ett åtagande gentemot kunder.
Relationer, historik, plats och sökning som måste fungera tillsammans: vi jämför det med den planerade gränsen för första versionen och säger ärligt var det passar.
Eller skriv till contact@natusai.com
