> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nexalytica.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Data Modelling and Schema Drift Monitoring in Nexalytica
> Build curated data models on your raw tables, accept AI-suggested relationships, and get alerted when upstream schema changes break your assumptions.
Raw tables are a starting point — a data model is how you shape them into something every analyst, dashboard, and agent can reason about the same way. Nexalytica's Data Modelling tools let you describe how a source's tables relate to each other and what its columns mean, so joins and definitions are captured once instead of everyone rediscovering them. Schema Drift monitoring watches for upstream structural changes and routes alerts to the right people before anything breaks.
Data Modelling is labelled **Beta**. Behaviour and UI controls may change between releases.
Each data source has **one model**, and it is created for you automatically — there is no gallery of models to manage and no "New model" step. The model is always **ephemeral**: it lives as a definition only, and Nexalytica queries your source live (federated) rather than copying your data onto its own infrastructure. For that reason there is no "materialize" step and no choice of storage type.
## Getting there
Open a data source, go to its **Schema** tab (the Schema Explorer), and click **Open Data Modelling UI**. Nexalytica opens the source's model straight away (creating it the first time). A **Back to Schema Explorer** link returns you to the plain table/column browser. You can also reach the same surface directly from the Data Modelling route for a source.
## Schema Explorer
The starting point is the read-only Schema Explorer. Nothing here modifies your source data — it's for inspection before (or after) you describe relationships.
| Panel | Contents |
| ------------------------- | --------------------------------------------------------------------- |
| **Left — Table list** | All tables in the connected source, with row counts and column counts |
| **Right — Column detail** | Column names, data types, and live sample rows for the selected table |
## Inside the model editor
The editor is a three-part workspace: an **Entities / Suggestions** sidebar on the left, a **canvas** in the middle, and a **Properties** panel on the right.
| Control / Button | What it does |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Entities** list (left) | The physical tables on this source. Click one to drop it onto the canvas as a box. |
| **Suggestions** list (left) | AI-proposed relationships between the tables on your canvas, each shown as a card. |
| **Apply all** (Suggestions) | Accepts every pending suggestion at once. |
| **Refresh** (Suggestions) | Re-runs the suggestion engine to propose relationships for the tables you've added. |
| Per-suggestion **✓ / ✗** | Accept or discard a single proposed relationship. |
| Canvas | The working area: tables are boxes, relationships are lines between them. Drag tables to arrange them, and draw a line between two tables to create a relationship. |
| **Zoom in / Zoom out / Fit view** (canvas toolbar) | Navigate the canvas. |
| **Description** (Properties → Model Properties) | A free-text description of the model; this feeds the agent's understanding of the data. |
| **Relationships** list (Properties) | The relationships currently in the model, with the option to select or delete each one. |
| **Save Model** | Saves your changes (entities, relationships, and description). Stays disabled until there are unsaved edits; prompts you to confirm before discarding unsaved work if you leave. |
There is no separate step to publish or store the model — saving is all that's needed, and the source is queried live whenever an agent, dashboard, or chat uses it.
## Schema Drift
Schema Drift monitors your connected sources for structural changes — dropped columns, renamed tables, changed data types — and surfaces them as alerts before downstream models and dashboards break.
### Alert anatomy
Each drift alert records:
| Field | Description |
| ------------------ | ----------------------------------------------------------- |
| **Severity** | `Info` · `Warning` · `Critical` |
| **First detected** | Timestamp when the change was first observed |
| **Times seen** | How many consecutive sync checks have confirmed the change |
| **Before / After** | Structured comparison of the previous and current structure |
### Triage alerts
The active triage queue. Every unresolved alert appears here.
| Action | How to trigger | Effect |
| ---------------------- | -------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **View** | Click the alert row or the View button | Opens the structured detail: tables/columns added, removed, or changed, and any primary-key changes |
| **View snapshot diff** | Button inside alert detail | Side-by-side comparison of the captured structure before and after the change |
| **Acknowledge** | Acknowledge button (available when status is Open) | Marks the alert as seen. You can add an optional note. Logged to the audit trail. |
| **Resolve** | Resolve button | Closes the alert. Logged to the audit trail. |
A complete log of all alerts regardless of current status. Use this tab to audit past drift events and trace the history of a particular source's structural changes.
Point-in-time captures of a source's structure. Each snapshot shows the capture timestamp and the source it belongs to. Use snapshots as reference baselines when investigating drift alerts.
Configure how and when drift notifications are delivered. See [Drift Policy](#drift-policy) below.
#### Alert statuses
| Status | Meaning |
| ----------------- | ----------------------------------------------------------------------------- |
| **Open** | Newly detected; awaiting triage |
| **Acknowledged** | Seen and noted; not yet resolved |
| **Resolved** | Closed by a reviewer |
| **Auto-resolved** | Automatically closed when the source structure returned to its previous state |
### Drift Policy
The Drift Policy tab controls who gets notified and under what conditions.
| Control | Options |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Recipients** | Source owner · Creator · Department admins · Org admins |
| **Custom emails** | Additional recipients outside the role list |
| **Severity threshold** | `Info` — notify on every structural change · `Warning` — skip minor additions, notify on significant changes · `Critical` — notify only on breaking changes such as dropped columns or renamed tables |
| **Quiet hours** | Defer notifications during a specified time window; set the timezone to match your team |
Click **Save** to apply changes or **Reset** to revert to the last saved state.
If no recipients are selected, drift is still recorded and visible in the Open Alerts tab — but no email notifications are sent. The policy form displays a warning when you save with no recipients configured.
## Permissions reference
* Curate the source's model — add tables, draw and edit relationships, write the model description
* Accept or dismiss AI-suggested relationships
* Acknowledge and resolve drift alerts
* Configure the Drift Policy
* Browse the Schema Explorer (read-only)
* Open and inspect the model (read-only; no editing)
* Review alerts and History tab (read-only; no acknowledge or resolve)