A clearer conversation
before you commit.

NatusAI helps organisations connect information, understand how work operates, plan change and build focused applications around useful business context.

Aquila helps you understand processes, information flows and dependencies. Phoenix helps you plan and coordinate change. Sculptor helps you create an application or workflow for a defined need.

Cygnus is the unified database and backend product for connected information and backend services. Lyra is the frontend product for clear application experiences. Together they support Aquila, Phoenix and Sculptor, while remaining useful products in their own right.

Deployment can be shaped around your hosting and ownership priorities, including on-premises, a private cloud tenancy or an isolated environment. The practical choice depends on connectivity, operations, models, updates and support.

That is a deployment and policy question, not a slogan. We define the data routes, model providers, support access and logging for the scope, with the default routes and exceptions visible for review.

Potentially, where the application and policy allow it. External calls should be identified, classified and governed. A deployment can also use local or customer-selected model paths where those fit the requirements.

Access can be designed around roles, least privilege, data classification and the identity systems selected for the application. The exact permissions and integrations are agreed during scope and deployment.

Some connections may be configured from an existing integration surface; others are a project. We identify the systems, permissions, data routes and effort before the scope is agreed.

We inventory the sources, define the target context, prepare and reconcile the material, then validate it with the people who own the work. The result and any unresolved quality issues should be visible.

Retention, legal holds and deletion are scoped as data-lifecycle workflows. The plan should identify configured stores, indexes, embeddings, caches and backups, then report what was completed and what remains in scope.

You need accountable business owners and people who can operate the chosen deployment. The number and profile of roles depends on scope, infrastructure, integrations, model paths and the level of support you want.

Responsibilities are agreed with your team: business owners guide the outcome and information; technical owners manage deployment, access and integrations; users validate whether the workflow helps.

Cost depends on the first question, information preparation, integrations, deployment, training and ongoing operations. We scope those components rather than promise a universal price or savings figure.

Portability should be designed into the application and stated in the scope: which data, indexes, models, configuration, application source and evidence can be exported, in what formats and with what dependencies.

Support level, access method, response expectations, update process and incident responsibilities are part of the engagement terms. They should be explicit for the chosen deployment, especially an isolated one.

Any platform creates a supplier relationship and an operational dependency. Reduce surprises by documenting data ownership, export routes, application responsibilities, interfaces, update mechanics and the work required to change provider or deployment.