Admin overview
Admin configuration lives under Admin. The first-run prompt sends new admins to Users, which is a reasonable default but not the setup order.
Recommended order
Section titled “Recommended order”- Providers — an LLM provider, or nothing else works.
- Connectors — a data source, then introspect it.
- Scopes — at least one, or nobody can be granted access.
- Users — accounts, roles, and scope grants.
- Everything below — governance, tuning, and optional surfaces.
Steps 1–4 are the quickstart. Only after a data source is introspected does the Registry have anything in it, and only after that is most of the product worth configuring.
The sections
Section titled “The sections”| Section | What it is for |
|---|---|
| Users | Accounts, roles, and scope grants |
| Providers | LLM providers, the SEMANTIX models, and reindexing |
| Connectors | Data sources, from templates or custom MCP |
| MCP servers | Custom MCP servers beyond the templates |
| Entity Registry | Introspection, entity trust, metric certification |
| Scopes | Creating and curating context scopes |
| Power BI import | Bringing metrics in from .pbip projects |
| Security | SSO configuration |
| DSPy | Tuning the metric-generation pipeline |
| Agents | Custom agents for open mode |
| Anomaly profiles | What counts as an anomaly |
| Experimental | Feature flags |
Optional, and often later
Section titled “Optional, and often later”DSPy, anomaly profiles, agents, and Power BI import all assume you already have data. Tuning metric generation before you have metrics is optimising a pipeline that has nothing to run on, and creating anomaly profiles before any metric is scheduled means tuning thresholds nothing is checked against.
Get a scope with certified metrics first. Then these sections start making sense.