NatusAIRelationships
Customers, equipment, contracts and events linked directly, so ownership, dependencies and causes are easy to follow.
Connected data foundation · Layer 01 · Connected foundationPlanned v1NatusAI Cygnus: one connected picture of your business, with its history
Cygnus is the planned data foundation of the NatusAI platform. It keeps assets, documents, locations, measurements and their relationships together, so people and approved AI assistants can answer questions that used to take days.
- Questions across silos answered while the decision is still open.
- See what was true, and what was known, on any past date: history your auditors can follow.
- Runs as one system on your own servers, with fewer moving parts to integrate and secure.
Planned v1 scope & 25 acceptance gates →Roadmap: later profiles →
What it does for the business
Six kinds of business data, one connected model
A sensor reading has a time, a place, an asset and a source. A contract refers to the same asset. Cygnus keeps these connections, so answers follow them instead of rebuilding them each time.
Facts and knowledge
Who operates what, which report describes which incident: facts tied to the things they describe.
Location
Positions, tracks and areas linked to the assets they belong to, and to their history.
Measurements over time
Readings kept beside the assets they describe, from one moment to years of history.
Search by meaning
Find information by what it says, then follow it back to the original source.
Exact search
Names, identifiers and passages, combined with relationships, place and time.
Ask what changed, and what was known then.
A vessel entered a storm area at 14:00. A corrected position arrived at 14:10. Cygnus is designed to reconstruct the 14:05 decision with what was known at the time, or to show the corrected picture. That is the history an auditor or supervisor asks for.
Programming close to the data
A language and query model built for the graph
Cygnus is planned to combine its own typed programming language with storage, execution and services. Business logic works with persistent entities and their relationships directly, reducing the translation between database rows, application objects and API responses.
Model once, use throughout
The same typed model carries data from durable storage into application logic and service contracts. Fewer mappings mean fewer places for types, field names and relationship definitions to drift.
Query through connected paths
Start from an indexed entry point, follow the relationships you need and constrain by time, space or search. The optimised query model aims to do that work close to storage and return only the requested result.
Serve the same business logic
Typed functions become application services and authorised tools. HTTP/RPC, streaming, generated TypeScript clients and MCP descriptors are part of the backend design, reducing separate adapter layers to maintain.
Less data movement. A smaller working set.
Load the part you need. Keep the rest on disk.
A large graph does not need to be loaded into memory in full. Persistent references let an operation resolve relevant nodes, index pages and time ranges as they are needed.
Looking at one vessel should not require loading every vessel, every document and the entire position history. Selective traversal and bounded reads are designed to keep memory use tied to the work being performed.
That is the route to faster connected queries and lower resource overhead: less materialisation, fewer transfers between services and less duplicated context. Actual gains depend on the graph, indexes, workload and hardware.
Illustrative access path
01 / Durable graph
Start with references and an indexed selection
Vessel · Cargo · Route · other vessels · other cargo · older ranges stay on disk.
Only references and an indexed selection are touched at first.
02 / Relevant working set
Resolve what this operation uses
Selected vessel → cargo → requested track
Resolve the connected data and time window this operation uses.
03 / Bounded result
A map view, a history slice or an answer
Page · sample · stream
Return a page, sample or stream. Large exports and rebuilds use bounded processing or durable jobs.
Storage, query and maintenance
From assembling tables to following connected data
Relational systems work well for structured records and SQL reporting. As a connected application adds history, maps, semantic retrieval and AI, the cost often shifts toward joins, object mapping and coordinating extra services. Cygnus is designed to reduce that overhead inside one programmable engine.
| Dimension | Tabular storage + application stack | Cygnus unified temporal graph (planned) |
|---|---|---|
| Data storage | Entities become rows; relationships use keys and often linking tables. Application code maps rows into objects. | Typed entities and persistent links share one model across storage, logic and services. |
| Connected queries | Joins reconstruct relationships at query time. Deep paths can add query and mapping complexity. | Indexed entry points and graph traversal follow stored relationships, with temporal and spatial constraints. |
| Memory & data movement | Efficient engines already use indexes and caches; broad joins and application-side processing can still create large intermediate results. | Resolve graph data on demand; use bounded ranges, pages and streams rather than materialising the entire connected dataset. |
| History & corrections | History tables, temporal extensions or event models must be designed and aligned with application queries. | Temporal state and bitemporal access belong to the model, preserving the distinction between valid time and knowledge time. |
| Geo, text & vectors | Extensions can add capabilities in one database; specialist services may need their own identity, indexing and synchronisation paths. | Spatial, time-series, text and vector resources connect to the same entities and versioned sources. |
| Query & application languages | SQL plus application code, mapping libraries and sometimes separate search or graph query languages. | One native typed language and optimised query model bring computation close to persistent graph structures. |
| Maintenance & evolution | Coordinate database schemas, mappings, service contracts and any separately operated retrieval stores. | Shared type descriptors and service contracts reduce duplicated definitions; migrations and index changes follow explicit version behaviour. |
| AI & access control | Typically add a tool gateway and chat layer, then align their permissions with the data paths they call. | Native MCP and a bounded chat contract use the same typed services, with authorisation in storage and execution paths. |
How to measure it: the intended advantage is faster relationship-heavy work with less mapping, synchronisation and resource overhead. Measure query latency, peak memory, disk I/O, ingest and maintenance effort on the same workload and hardware. A warehouse or mature SQL stack may remain the better fit for large tabular analytics or required extensions.
Native MCP & chat
AI can work with your data. And the context behind it.
An AI answer becomes more useful when it can connect the right document to the right entity, location and moment. Cygnus is planned to bring retrieval, callable business logic and conversation records into the backend model.
Native MCP tools
Model Context Protocol gives authorised agents a discoverable, typed way to use backend functions. Tool discovery and execution follow the caller’s permissions, with the same service contracts used by applications.
Chat as a backend capability
The planned provider-neutral chat contract covers messages, streaming events, tool calls, structured output and durable session/run records. Local or remote model bindings are selected and qualified explicitly for the deployment.
Answers with temporal evidence
Combine full-text and vector retrieval with graph, spatial and historical context. Keep references to source versions and the chosen time context so a person can inspect the evidence and understand how an answer was formed.
Data-access rules apply before disclosure and search ranking. Retrieved content and model output do not grant permission to act; protected actions require their own authority and, where specified, a human decision.
All the dimensions in one question
Follow a vessel through time and place
“Which cargo was on vessels inside the storm area yesterday, and which reports explain the risk?”
This proposed maritime workload brings the architecture together. The same approach can connect equipment, telemetry and maintenance in energy, manufacturing or infrastructure applications.
How the answer is built
Set the historical context
Select yesterday’s interval and whether the question uses what was known then or later corrected evidence.
Find the relevant positions
Use geospatial selection and time-series ranges to identify vessels whose tracks intersected the storm area.
Follow cargo and ownership
Traverse the vessel’s historical relationships to cargo, operators and ports, resolving the required parts of the graph.
Retrieve the supporting reports
Combine keyword and semantic search over authorised document versions, linked to the selected entities and time context.
Deliver an inspectable answer
A typed service or MCP tool returns the evidence. Chat can explain it while retaining the sources and relevant context.
Honest status
What you can use today, and what is on the roadmap
We separate what is proven from what is coming, and label both. NatusAI Cygnus is planned for its first release (v1).
What you can use today
- The engine behind our client projects is proven in delivery: a country-wide grid digital twin and a bank’s connected investigation data.
- Delivery engagements that build your connected data model with our team, in your environment.
What’s on the roadmap
Planned v1- Cygnus first release: one server, plus embedded and development profiles, released only after 25 defined acceptance tests pass.
- Later: multiple servers, with replication and failover. Scope follows evidence.
- Later: broader AI and compute options. No dates are published; we share plans under NDA.
How it connects
Cygnus holds the data and the business logic. NatusAI Lyra shows it, NatusAI Auriga and Aquila let AI work with it, NatusAI Orion builds applications on it, NatusAI Draco runs it and NatusAI Gemini recovers it.
For your technical team
What Cygnus is. A planned programmable temporal graph database: its own typed language, an optimised query model and a backend runtime. Graph, geospatial, vector, triple-store semantics, time series and full-text search share one model, with one identity, one transaction model and one authorisation boundary.
- Six data families: typed graph relationships; triples (RDF interchange and SPARQL compatibility are separate release decisions); CRS-aware geospatial indexing with exact recheck; regular and irregular time series with rollups and event-time windows; dense and sparse vectors linked to source versions; analyser-versioned full-text with BM25 and hybrid ranking.
- Bitemporal history: valid time (when it was true) and knowledge time (when the system learned it); as-of answers reproducible against both, including later corrections.
- Transactions and access: strict-serializable transactions keep entity, graph, time and declared index changes in one commit epoch. Authorisation sits in storage and execution paths, applied before search ranking and top-k selection; denied resources do not leak through counts or errors.
- AI access: native MCP descriptors and a provider-neutral chat contract (messages, streaming, tool calls, structured output, durable session records). Local or remote model bindings are qualified per deployment.
- Services: typed HTTP/RPC and streaming, change feeds, generated TypeScript clients, an Explorer surface, LSP and a VS Code client.
- Out-of-core by design: persistent references resolve only the nodes, index pages and time ranges an operation needs, so a large graph does not have to fit in memory.
- Honest fit: for large tabular analytics, a warehouse or mature SQL stack may remain the better choice.
| Profile | First release | Boundary |
|---|---|---|
| Embedded | Included | One application process with local storage. |
| Development | Included | Empty-project bootstrap and explicit source modes. |
| Production, single server | Included | One node; backup, point-in-time recovery and verified restore in scope. |
| Cluster | Excluded | No sharding, replication, distributed traversal or failover claim. |
| Isolated workload | Excluded | No separately qualified isolated-workload profile. |
| Gate | Proposed threshold | Status |
|---|---|---|
| Production design partners on the reference workload | At least 3 | Not yet passed |
| Production system of record with retained history | At least 1, with 6+ months of history | Not yet passed |
| Sustained position ingest, 32-vCPU reference class | ≥ 100,000 reports/s | Not yet passed |
| Vessels inside a polygon over 250,000 live positions | p99 ≤ 150 ms | Not yet passed |
| Hybrid top-20 retrieval over 5 million documents | p99 ≤ 300 ms | Not yet passed |
| Out-of-core correctness | Dataset ≥ 24 × RAM | Not yet passed |
| Element-level authorisation overhead | ≤ 2 × coarse-grained policy | Not yet passed |
| Acknowledged commits lost on one server | Zero | Not yet passed |
| Scheduled verified-restore drills | 100% pass | Not yet passed |
| Agent-driven empty-project evaluations without human repair | ≥ 70% succeed | Not yet passed |
Control by design
Sovereignty, governance and security at NatusAI How NatusAI Cygnus de-risks AI
Ownership
Runs on your servers as one system, with no separate search, graph and time-series services to license and secure.
Evidence
Answers keep references to the source version and the moment in time they used.
Access
Data-access rules apply before anything is shown or ranked. Retrieved text never grants an AI permission to act.
Recovery
Verified restore and point-in-time recovery are release requirements, not options.
Connected data at work
One connected model. Many real-world problems.
The issues, approaches and useful outcomes from our industry stories and reference architectures. Each example highlights the dimensions that make the problem a fit for the planned Cygnus unified model.
01 · Banking & financial services
Make relationships easier to investigate.
Accounts → Transactions → Investigation
- The issue
- Slow queries and departmental silos made it difficult to connect customers, transactions, documents and events.
- The connected approach
- Explore a shared relationship model with pattern analysis, transaction processing and questions across approved documents.
- What it enables
- A connected investigation workflow supports transaction monitoring, risk analysis and a fuller view of customer context.
Cygnus fitGraphTriplesTemporal historyFull-text
Explore financial services
02 · Energy & utilities
Understand a changing grid.
Grid assets → Meter readings → Maintenance
- The issue
- Network structure, consumption and generation sat in separate views, making changing conditions difficult to assess.
- The connected approach
- Connect the grid’s relationships with measurements, events and historical patterns in a shared operational model.
- What it enables
- A common picture supports monitoring, alerts, predictive analysis and better-informed maintenance and investment decisions.
Cygnus fitGraphGeospatialTime seriesTemporal history
Explore energy & utilities
03 · Manufacturing
Trace a signal back to the production line.
Equipment → Sensor history → Intervention
- The issue
- Machine, energy, quality and maintenance information was scattered across production and business systems.
- The connected approach
- A reference digital twin brings measurements and operating context together around equipment and processes.
- What it enables
- Live performance views, alerts and maintenance analysis help teams investigate changes earlier and plan interventions.
Cygnus fitGraphTime seriesTemporal history
Explore manufacturing
04 · OSINT
Turn scattered signals into a shared picture.
Places & events → Source reports → Assessment
- The issue
- Public reports, movement, weather and infrastructure signals are spread across separate sources.
- The connected approach
- NatusAI OSINT brings map layers and source-linked alerts into one workspace for exploring an event and its context.
- What it enables
- Analysts can inspect a region, compare sources and use optional AI assistance to explore questions before preparing an assessment.
Cygnus fitGeospatialGraphFull-textTemporal history
Explore OSINT
05 · Solar & infrastructure planning
See the potential of every roof.
Buildings → Solar conditions → Scenarios
- The issue
- Solar planning needs geometry, location and changing energy inputs together, with assumptions visible to the decision-maker.
- The connected approach
- Connect geographical assets, production estimates and grid context, with building-level controls for orientation, storage and costs.
- What it enables
- Teams can compare rooftop potential and explore planning scenarios while inspecting the assumptions behind each estimate.
Cygnus fitGeospatialGraphTime series
Explore energy planning
06 · Telecommunications
Bring context into every service request.
Customer → Service request → Human handoff
- The issue
- Recurring enquiries absorbed support capacity, while complex customer conversations waited.
- The connected approach
- Connect categorisation and prioritisation to customer and ticketing systems, with clear routes to a human agent.
- What it enables
- Less repetitive handling, a clearer response flow and more capacity for cases that need an experienced person.
Cygnus fitGraphFull-textTemporal historyChat
Explore telecommunications
07 · Trade & supply chains
Follow the consequences of disruption.
Trade flows → Dependencies → Disruption
- The issue
- A blocked route or disrupted supplier can affect a wider network that is hard to understand from isolated trade records.
- The connected approach
- A reference graph connects trade flows, dependencies and risks, with scenario exploration and plain-language questions.
- What it enables
- Analysts can explore cascading effects across shipping routes and supply relationships before deciding what to investigate next.
Cygnus fitGraphGeospatialTemporal historyChat
Explore global trade
These stories describe projects, explored workflows and reference architectures. The Cygnus fit labels map them to the planned product; they do not establish a released Cygnus deployment.
A paired foundation
Give connected data a clear interface.
NatusAI Lyra provides reusable web components for maps, graphs, search and application workflows. The wider Orion and Cygnus integration is part of the platform vision. Explore NatusAI Lyra
Works with
Layer 03 · ApplicationsAvailable
NatusAI Lyra
Reusable interface components for dashboards, maps, documents and AI conversations.
Explore NatusAI Lyra
Layer 02 · IntelligenceRoadmap
NatusAI Aquila
Turn documents into knowledge you can cite, with the source one click away.
Explore NatusAI Aquila
Layer 02 · IntelligenceRoadmap
NatusAI Auriga
AI assistants and tools that work within the permissions and budgets your people set.
Explore NatusAI Auriga
Questions
Questions about NatusAI Cygnus
Short answers for decision-makers. Your technical team will find the detail in the disclosure above.
Is NatusAI Cygnus available today?
Not yet. Cygnus is planned for a first release that is accepted only after its defined acceptance tests pass. The same engine as our client projects is already proven in delivery, and our team builds on it today.
Does a worldwide twin need many servers?
No. The first release targets one server. A worldwide data model can run on one node within its tested limits; global geography does not imply a cluster.
Does Cygnus replace our data warehouse?
Not necessarily. Cygnus is designed for connected, relationship-heavy work. For large tabular reporting, a warehouse or mature SQL stack may remain the better fit, and Cygnus can sit beside it.
Talk to our team
Which question takes your teams days to answer?
Bring one. We will show you how a connected model would answer it, and what it would take.
Or write to contact@natusai.com
