NatusAICore and services
Typed language and execution, transactional graph and time-series storage, authentication and storage-path authorization, typed HTTP/RPC and streaming services, generated TypeScript client, API and MCP descriptors.
- Home
- Products
- NatusAI Cygnus
- Planned v1 scope
Cygnus · planned first releasePlanned v1A precise first release. Evidence before acceptance.
Cygnus 1.0 is a planned, gated release of a programmable temporal graph database. The scope below is a design and qualification plan; no release gate or performance target is presented as achieved.
Status: Cygnus 1.0 has not been accepted or released. Included capabilities, security, documentation, compatibility, deployment and recovery evidence must all pass before a public release.
First-release boundary
A single-node system of record with a controlled agent surface.
The planned release combines language, runtime, storage and services under one semantic model. A candidate implementation is not a public release.
Data and retrieval
The seven bounded modality profiles below, graph traversal, geospatial indexing, text/BM25 and sparse/dense retrieval, temporal windows, rollups and durable subscriptions.
Tools and experience
A selected Explorer surface, five frozen application patterns for twins, telemetry, event logs, geo tracks and resource CRUD; LSP core, VS Code client and bounded headless debugging.
Operations and AI
Durable jobs and schedules, single-server observability, backup, point-in-time recovery and verified restore; a bounded chat contract with exact-pinned provider qualification and independently controlled remediation.
Dependency order: core → service contracts and security → temporal, spatial and retrieval data → selected Explorer and agent tools → single-server operations and bounded chat. Data and secure services precede the larger agent interface.
Service and tooling contracts
Make the same typed model usable by people, clients and agents.
These are planned first-release requirements with separate conformance and security gates, not a claim that every surface is available today.
Services and managed files
Typed HTTP/RPC and streaming operations, change feeds, generated TypeScript clients, and versioned service descriptions for API and MCP use. A Blob-backed managed file service would provide transactional virtual directories and bounded transfer, without implicit parsing or host-filesystem access.
Durable human decisions
A first-party decision and approval queue would keep authoritative human choices beyond an agent session. An agent proposal and its evidence remain separate from permission to activate it.
Language and localization
The native baseline includes language tags, presentation context, typed message and catalog identity, and bounded formatting. Server and generated TypeScript clients must agree on pinned catalogs; exact production locales and support intervals remain open.
Explorer and developer tools
The selected authenticated Explorer covers Overview, Data/graph, Activity/logs, Functions/API/MCP, Access, and qualified Chat/provider setup. Its localization must pass typed-argument, RTL, pseudo-locale, accessibility, hostile-translation and server/client parity checks. The LSP core, thin VS Code client and bounded headless-debug contract are mandatory; an editor Debug Adapter Protocol integration is deferred.
The five frozen application patterns are twin entity, telemetry series, event log, geo track and resource CRUD. A general declarative UI system or browser language runtime is not part of this first release.
Data meaning and authority
The seams must close inside one system.
These are architectural requirements for the planned release, subject to conformance and security qualification.
What was true; what was known
Bitemporal access distinguishes a fact’s valid time from the time it entered the system. An as-of answer should be reproducible against both, including later corrections.
One transaction and declared derivatives
Strict-serializable transactions with fine-grained logical conflict detection are intended to keep entity, graph, time and declared transactional index or derived-resource changes in one commit epoch.
Authorization before disclosure
Access checks belong in storage and execution paths, including index scans, traversals and aggregates. Discovery is separate from read access; denied resources must not leak through counts, errors or existence hints. Search authorization occurs before ranking and top-k selection.
A declared public function effect describes potential behavior; it never grants permission by itself. Retrieved content and model output remain untrusted when an agent proposes a tool action.
Seven data families
Durable representation does not imply built-in interpretation.
Stored sources keep bounded access, versioned descriptors, classification, provenance, retention and authorization. Derived text, tiles or embeddings are explicitly versioned and never silently become the original.
| Modality | Planned first-release representation | Outside the first-release claim |
|---|---|---|
| Text | Bounded UTF-8 strings; large UTF-8 as streamed or range-read blobs; analyzer-versioned text/BM25 index. | Universal charset repair, source-changing implicit normalization or unbounded string materialization. |
| Documents | Authoritative source bytes with metadata and provenance; explicit text and chunk derivatives may be supplied or produced by a declared external provider. | Universal PDF/office parsing, silent OCR or treating extracted text as the source. |
| Image, audio and video | Source bytes, media metadata and digest; resumable bounded ingress, range streaming and explicitly versioned external derivatives. | Bundled decoders/transcoders, native video pipeline, thumbnails, frame extraction or inherent media similarity. |
| Time-series state | Point, batch and range access, regular/irregular extents and exact resolution; later in the included delivery sequence, event-time windows, watermarks, rollups and durable subscriptions. | Multiple independent events at one instant in a single series; use an event map for those. |
| Vector GIS | CRS-aware geo values/features, streamed large geometry where needed, exact predicates and indexed candidates with exact recheck. | Distributed spatial execution or a general PostGIS-compatible escape language. |
| Raster GIS | Source bytes with raster descriptor, bounded byte/range access and declared external tile or overview projections. | Bundled raster decoding, native reprojection/overview building or guaranteed random tile access from sequential formats. |
| Dense and sparse numeric | Bounded arrays and sparse arrays; minimal fixed-shape float tensor storage for provider-produced embeddings. | General tensor algebra, model execution, ONNX, training, quantization or device compute. |
Exact interchange formats, accepted document/media types, vector and raster profiles, provider versions and security fixtures remain release decisions.
Deployment profile
Scale up first; cluster is a later profile.
The planned production topology is one server. It may hold tenants with isolation and quotas, but its capacity and failure domain remain one node.
| Profile | Planned first-release position | Boundary |
|---|---|---|
| Embedded | Included | One application process with local storage; no separate server process. |
| Development | Included | Empty-project bootstrap and explicit source modes. |
| Production single-server | Included | One node. POSIX durability first; object-storage durability and backup support in the release scope. |
| Cluster | Excluded · later profile | No sharding, replication, distributed traversal or failover claim. |
| Isolated workload | Excluded | No separately qualified isolated-workload deployment profile. |
Deployment environment choices such as a customer data centre or private cloud are separate from these runtime profiles.
Single-server operations
Recovery and controlled change belong inside the release gate.
The planned production profile pairs durable jobs and schedules with operational evidence on one server. It makes no cluster, replica-failover or cross-node availability claim.
Back up, restore and retain
Full and incremental scheduled backups, verified restore and point-in-time recovery, retention/TTL and legal holds are included requirements. A completed backup does not prove that an application and its data can be restored.
Observe and respond
Production observability and declared service objectives would connect incidents to the affected application and release. Only registered, preauthorized remediation classes may act within their bounded profile; stale or revoked authority must refuse or escalate.
Promote independently
Canary and rollback decisions remain under independent control. The agent proposing a repair cannot approve its own authority expansion, change its acceptance criteria or activate its successor.
Change the running system
Rolling schema, contract and backend deployment is planned for the single-server profile. A stable native C ABI and supervised provider boundary allow declared integrations without adding the later open registry or component host.
Release qualification also requires crash recovery, zero loss of acknowledged commits and successful restore drills under declared conditions. The proposed numeric thresholds appear below as tests, not measured results or service levels.
A falsifiable example
The worldwide-twin reference workload.
These are proposed workload assumptions awaiting author ratification and design-partner measurement. “Worldwide” describes the subject matter, not distributed execution.
| Dimension | Proposed reference workload |
|---|---|
| Twin entities | 250,000 vessels; 5,000 ports and terminals; 2 million cargo units |
| Position ingest | 25,000 reports/s sustained; 100,000 reports/s for a 60-second burst |
| Full-fidelity retention | 90 days; about 194 billion samples and 2 TB compressed |
| Downsampled retention | One sample per 5 minutes to 36 months; about 79 billion samples and 0.8 TB |
| Events and documents | 5 million port calls, notices and manifests per year |
| Embeddings | 768 float32 dimensions; about 15 GB/year raw |
| Graph shape | Ownership, charter and operator paths to depth 6; mean out-degree 4; port nodes to 100,000 edges |
| Interactive concurrency | 200 people and 50 machine clients |
| Hardware and memory | Proposed 32-vCPU reference hardware class; about 24:1 dataset-to-RAM ratio. RAM, vendor and storage model are unspecified. |
The 25,000 reports/s sustained figure describes this reference workload. The 100,000 reports/s sustained figure in the acceptance gates is a stricter proposed release gate; 80,000 reports/s on that hardware is a separate scope-reassessment threshold.
Capacity and working set
Large retained histories need bounded operations.
Theoretical design arithmetic at about 10.3 compressed bytes per sample points to roughly 1–2 trillion samples and up to 20 TiB per node. This is not a measured capacity result.
≈10.3 bytes
compressed per sample: the basis of the design arithmetic
1–2 trillion
samples per node, roughly, in theoretical design arithmetic
≤20 TiB
per node at that density; not a measured capacity result
10 TiB / 16 GiB
a separate proposed qualification case: storage versus installed RAM
A separate proposed qualification case uses 10 TiB of storage with 16 GiB of installed RAM for bounded point, range, page, sample and viewport queries. It does not mean that the corpus or an entire index resides in memory, or that every global query is interactive.
At the stricter 100,000 reports/s release gate, 90 days of full-fidelity samples would be about 0.78 trillion samples and 8 TB. Twelve months would be about 3.2 trillion and 32 TB, beyond the proposed single-node design center. Longer retention would need downsampling or a later cluster profile. Full export, global sort and whole-index rebuild remain streaming or durable-job work.
Nineteen contracts
Version behavior must be explicit before release.
Before 1.0, only stable assigned identifiers are never repurposed. All other 1.x commitments are release intentions, and several details remain undecided.
| Dimension | Before 1.0 | Intended 1.x behavior or open decision |
|---|---|---|
| Source language | No 1.x compatibility promise before 1.0. | The 1.0 grammar is frozen; source accepted by 1.0 remains accepted by later 1.x. |
| Descriptors and catalog | Stable type, field and other assigned IDs are never repurposed. | A later 1.x reads descriptors written by earlier 1.x releases. |
| Bytecode and plans | No general compatibility promise. | Physical plans rebuild on upgrade. Durable jobs pin an execution reference; a newer runtime reads, migrates, explicitly replays, or refuses. Arbitrary checkpoints are not portable. |
| Storage decode | No general compatibility promise. | Later releases retain decoders for still-referenced 1.x blocks. |
| Storage write | No general compatibility promise. | Backward reading is declared per format. Downgrade is not promised. |
| Wire and API | No general compatibility promise. | Additive within 1.x; breaking changes require a new service major. |
| Generated client | No general compatibility promise. | A client generated for 1.x compiles against later 1.x servers. |
| Declarative frontend | No general compatibility promise. | Descriptor kinds are additive within 1.x. |
| Packages and components | No general compatibility promise. | Retained decoders, locks and selected native-provider interfaces add compatibly. An open registry and component host are later work. |
| Cluster rolling upgrade | Not applicable. | Not applicable: no cluster profile in 1.0. |
| Backup and restore | No general compatibility promise. | A later 1.x restores earlier 1.x backups and reports a verified restore result. |
| Operational configuration | No general compatibility promise. | Additive within 1.x; removal needs a deprecation release. |
| AI provider adapter | No general compatibility promise. | The portable chat schema and worker protocol add compatibly. Exact provider artifacts pin their own versions, directions and capabilities. No vendor model or feature is implied. |
| Agent and MCP workspace | Support interval still to be selected. | Version directions, negotiation and failure behavior need a release decision. |
| Agent session and guidance | Support interval still to be selected. | Version directions and checkpoint behavior need a release decision. |
| Versioned AI skill | Support interval still to be selected. | Both directions and failure behavior need a release decision. |
| Public function effects | No general compatibility promise. | Adding an effect breaks the public function contract and requires a new service major; it never grants authority by itself. |
| Consistency token | Support interval still to be selected. | The token is in the first-release service scope; its compatibility contract needs a release decision. |
| Localized messages and catalogs | Stable message, catalog and profile IDs are never repurposed. | Public keys and typed arguments add compatibly; referenced messages retain readers. Locales, defaults and catalog support intervals remain open. |
The release support matrix must specify both reading and writing directions, supported intervals, negotiation and failure for every row. No downgrade or arbitrary checkpoint-portability guarantee is implied.
Bounded chat and local AI
Each provider needs its own evidence.
The planned provider-neutral chat contract covers content, messages, events, tools, structured output and durable session/run records. Model-specific capabilities are never inherited from a generic endpoint name.
| Planned first-release binding | Qualification boundary |
|---|---|
| Deterministic fake provider | Required for reproducible tests. |
| Direct OpenAI Responses | An exact provider artifact and pinned capability/contract matrix; no vendor model is promised. |
| Anthropic Messages | An exact provider artifact and pinned capability/contract matrix. |
| Native Ollama | Qualified against its native contract, not its OpenAI-compatible surface. |
| Bounded OpenAI-compatible endpoint | Typed endpoint binding with probed capabilities; it does not claim OpenAI identity. |
| Externally managed co-resident runtime | Only bounded Cygnus client-resource claims; the external runtime is not counted as Cygnus headroom. |
| Certified Cygnus-managed local llama.cpp | CPU member required; CUDA only if qualified. Exact model, tokenizer, runtime, device, configuration and resource envelope require a signed certificate. |
Remote or independently operated local endpoints do not inherit managed-local RAM/VRAM guarantees. Native model compute, broad provider-native agents, automatic fallback and unlimited AI use are outside this profile. Provider and product names identify interfaces only; they imply no partnership or endorsement.
Twenty-five acceptance gates
Release requires measured evidence across the whole system.
No gate below is claimed as passed. The figures apply to declared workload, hardware and consistency conditions; must-pass and should-pass remain distinct: 22 gates must pass, 2 should pass.
| Gate · evidence required | Proposed threshold | Requirement · status |
|---|---|---|
| 01 Production design partners running the reference-shaped workload | At least 3 | Must passNot yet passed |
| 02 Production system of record with retained history | At least 1 with at least 6 months of history | Must passNot yet passed |
| 03 Sustained position ingest on the proposed 32-vCPU reference hardware class, with transactional index consistency | At least 100,000 reports/s | Must passNot yet passed |
| 04 Burst absorption without shedding or unbounded queue growth | 100,000 reports/s for 60 seconds | Must passNot yet passed |
| 05 Vessels inside a polygon over 250,000 live positions | p99 at most 150 ms | Must passNot yet passed |
| 06 90-day single-vessel track read | p99 at most 250 ms | Must passNot yet passed |
| 07 Hybrid sparse and dense top-20 retrieval over 5 million documents | p99 at most 300 ms | Must passNot yet passed |
| 08 Twin-neighborhood read, depth 3 and at most 500 nodes | p99 at most 50 ms | Should passNot yet passed |
| 09 Out-of-core correctness without unbounded memory growth | Dataset at least 24 times RAM | Must passNot yet passed |
| 10 Element-level authorization overhead against coarse-grained policy | At most 2 times | Must passNot yet passed |
| 11 Acknowledged-commit recovery point on one server | Zero acknowledged commits lost | Must passNot yet passed |
| 12 Restart with a 3 TiB dataset | Authoritative writes resume within 20 seconds | Must passNot yet passed |
| 13 Scheduled verified-restore drills in release window | 100% pass | Must passNot yet passed |
| 14 Crash recovery at every commit step | 100% of tests pass | Must passNot yet passed |
| 15 Empty-project agent evaluations without human repair | At least 70% succeed under declared budgets | Must passNot yet passed |
| 16 Empty project to deployed, authorized twin read/write feature with generated TypeScript client and form | At most 30 minutes, agent-driven | Should passNot yet passed |
| 17 Mandatory conformance suites for every included profile | 100% pass | Must passNot yet passed |
| 18 Frozen specifications and minimum conformance suites | Core substrate, stable identity descriptors and threat/security kernel; modality descriptors, language, project, intermediate representation, plans, schema, storage, transactions, streams, package lock, localization and core tools; services, MCP, features, UI, generated TypeScript, deployment bundles, change feeds and full security; search and event time; guided MCP, frozen feature projection, Explorer localization, LSP and headless debug; single-server operations, native-provider interface and bounded chat. Threat model revisited at every included gate. | Must passNot yet passed |
| 19 Documentation examples run as tests | 100% | Must passNot yet passed |
| 20 Performance regression baselines with owners | Every hot-path benchmark | Must passNot yet passed |
| 21 Complete support and compatibility matrix | Exact formats, document/media/raster/provider profiles, locales and catalogs selected; all 19 dimensions specify both directions, intervals, negotiation and failure; no open cells | Must passNot yet passed |
| 22 Production identity and cryptographic activation | Qualified external key provider and audited first-administrator ceremony; no development/file-provider fallback | Must passNot yet passed |
| 22 Security disclosure and release operations | Monitored contact, public encryption key, security.txt, advisory path, support calendar and exercised release/rollback roles | Must passNot yet passed |
| 24 Complete bounded chat acceptance | Core, all five provider adapters, MCP, knowledge, externally managed local, certified managed CPU local, library and resource-floor acceptance | Must passNot yet passed |
| 25 First-release library catalogue | Every required member has an approved mature release; recommended members pass or disclose a successor and deviation | Must passNot yet passed |
The 100,000 reports/s release gate on the proposed 32-vCPU hardware class is separate from a harder engineering target on a smaller, unspecified hardware class. Security, identity, provider, documentation and support-matrix gates are as necessary as throughput.
Still to be selected
A release matrix is part of the release.
The exact document, media, raster, vector, bulk-interchange and provider versions, production locales, catalog intervals and several agent/session/skill/token compatibility directions remain open. These must be selected and qualified before 1.0.
Pricing, licensing, commercial packaging, provider funding, schedules and delivery dates are also unselected. A proposed target is a test to run, not a customer commitment.
Keep exploring
Talk to our team
Bring a workload where the seams hurt.
Relationships, history, location and search that have to work together: we will map it against the planned first-release boundary and tell you honestly where it fits.
Or write to contact@natusai.com
