NatusAIModel and tensor compute
Tiled and sparse tensor layouts, algebra, compute graphs, model resources, ONNX, training, autodiff, GPU/NPU execution and distributed compute remain later work.
- Home
- Products
- NatusAI Cygnus
- Roadmap
Cygnus · later profiles & proposalsRoadmapWhat comes after a proven core. Scope follows evidence.
These are proposed or deferred capability families, not released features or a dated delivery schedule. The first release must earn its single-server claims before a wider profile is accepted.
Status: the optional first-party marketplace is a selected direction whose public operation remains gated. Cluster, managed-platform and governance profiles need separate evidence and decisions. No date is selected.
Later cluster profile Roadmap
Prove one node before distributing the system.
The later cluster profile would add shards, replication, failover, routing, rebalance, cross-shard transactions, distributed traversal, mixed-version upgrades and tenant relocation.
A multi-node or multi-PiB design target belongs here, never to Cygnus 1.0.
Scale-out acceptance would require distributed correctness, recovery and failure-domain evidence on representative workloads. Reserved format fields alone do not prove a cluster.
1 node
Cygnus 1.0 production topology: capacity and failure domain stay one server.
multi-PiB
A design target for the later cluster profile only, not a first-release claim.
Later AI and compute Roadmap
Broader AI requires separately qualified execution.
Provider-native workflows
Agent workflows, subagents, skills, plugins, hooks, collaboration/background tasks, advanced memory, generated compaction and automatic fallback are outside the first chat profile.
Additional bindings
Native or compatible vLLM, Ollama-compatible, Anthropic agent and Codex surfaces require their own qualification. Managed CUDA remains conditional on the exact certified envelope.
Models, provider artifacts and resource envelopes need pinned capability and security evidence. A remote provider does not supply a local resource guarantee. Provider and product names identify interfaces only.
Reusable ecosystem Roadmap
Find a verified fit; make a private candidate when none exists.
An optional first-party marketplace and library loop is a selected later product direction, with public operation still gated.
It is designed to discover exact compatible releases or return an explicit no-match, then prepare a module-selective private candidate where needed. Compilation, security, resource, compatibility and agent evaluation would precede separate maintainer approval and a signed immutable release.
A library release versions its modules together, while each application activates only the modules it needs, without pulling unused sibling code, dependencies, providers, permissions or resource profiles.
Approved artifacts and publishable evidence could be reused across applications. Customer data, private logic, prompts and provider keys would stay inside their access boundary. Agents could propose candidates but could not install, authorize, sign, approve or publish them on their own.
A broader managed-platform reference application is a separate, unratified proposal covering application provisioning, fleet control, commercial records, contribution campaigns and hosted self-update. Pricing, fees, rewards, billing and funding remain undecided.
Proposed data worlds and governance Proposed · not selected
Forkable worlds and independent verification need new fault models.
A post-v1 proposal, shown here as it appears in the current Cygnus scope. Nothing in this section is selected, scheduled or part of Cygnus 1.0.
Data worlds
Structurally shared data worlds, deterministic simulation, semantic three-way merge, retained-history accounting and explicit merge/drop lifecycles are deferred.
Independent verification
A proposed federation would use Byzantine-fault-tolerant finality over deterministic application transitions and a layout-independent semantic state commitment. Validators, full verifiers, archives and light verifiers have separate roles; a user could keep and verify an independently owned copy of complete public history without becoming a validator.
A qualifying governance workload
A proposed liquid-democracy application would need independently replayable proposal versions, eligibility snapshots, delegation grants and revocations, cycle and override rules, vote casts and supersessions, close semantics and tally certificates.
This is a post-v1 proposal. No consensus algorithm, validator governance, personhood system, token, public network, operated service or ballot privacy scheme is selected. Secret ballots require separately reviewed cryptography and must never publish plaintext votes; verified history alone does not establish voter legitimacy, fairness or election integrity.
Other deferred families
Keep adjacent work outside the first-release promise.
| Family | Later work |
|---|---|
| Document and media interpretation | Bundled general parsers, OCR, media decoding/transcoding, thumbnails, frame/tile extraction, native raster reprojection and overviews. |
| Optimization | JIT/AOT specialization, operator fusion, NUMA placement and adaptive layouts. |
| Developer and component tools | Debug Adapter Protocol, open package registry client and sandboxed component host. |
| Tenant mobility | Portable tenant export/import and cluster-dependent relocation. |
| UI and web runtime | General declarative UI beyond selected Explorer patterns, general server rendering and a browser-side language runtime. |
| Retention and time | Default per-subject cryptographic erasure and leap-second-aware scientific time scales. |
Falsifiable direction
The evidence can change the scope.
The following are proposed reassessment criteria, not achieved measurements or customer service levels. Meeting one would trigger a scope review rather than a promise to ship a replacement architecture.
| Signal | Proposed reason to reassess |
|---|---|
| Ingest | Below 80,000 sustained reports/s on the proposed 32-vCPU class with transactional index consistency. The release gate is separately 100,000 reports/s. |
| Query | p99 above 500 ms for 250,000 current positions in a polygon, or above 1,000 ms for a 90-day vessel track, at 24× dataset-to-RAM. |
| Policy cost | Element-level authorization above 3× coarse-grained p99. The proposed release gate is stricter at 2×. |
| Geo fit | More than 20% of design-partner spatial queries require an outside spatial language. |
| Agent completion | Fewer than 70% of declared empty-project evaluations succeed without human repair. |
| External-store escape | A partner needs another search, time-series or messaging store within 90 days for the reference workload. |
| Delivery exposure | The core, services and data milestones exceed a proposed 30-month interval after the initial milestone at achievable staffing; this is a reassessment criterion, not a delivery date. |
| Recovery | Any verified-restore drill fails or an acknowledged commit is lost in crash testing. |
Workload, hardware, consistency, staffing and test methods would need agreement before the criteria could guide a release decision.
Open decisions
Plans remain conditional.
No public delivery date, pricing, license, package, provider funding model or marketplace fee has been selected. Format, provider, locale and compatibility matrices are first-release decisions; later profiles need their own proof.
The first technical checkpoint is the complete Cygnus 1.0 acceptance evidence, including verified recovery and support contracts. Post-v1 scope is reassessed from actual design-partner use rather than assumed by this roadmap.
Keep exploring
Talk to our team
Scope follows evidence. So do our conversations.
Tell us which later profile matters to your workload. We share plans honestly, including what is not decided.
Or write to contact@natusai.com
