System Sources

Data components normally bind to a table. Some do not: a runs grid, an audit log, or a global-search result list reads from a platform endpoint that is not one of your tables.

You can bind such a component inline with dataSource: { system: { endpoint: … } }. The moment two components read the same endpoint, that raw path is duplicated in your config. app.systemSources declares each endpoint once, under a name:

systemSources:
  - name: runs
    endpoint: /api/admin/automations/runs
  - name: failed-runs
    endpoint: /api/admin/automations/runs
    query:
      status: failed

Components then reference the name:

- type: data-table
  dataSource:
    systemSource: runs

Entry Properties

A catalog entry is a drop-in for the inline system form — a referencing component reads exactly the same fields it would have read inline, so switching between the two never changes the component.

Two Sources, One Endpoint

query is what makes named sources worth declaring. The same endpoint with different static parameters becomes two distinct, self-describing sources:

systemSources:
  - name: open-tickets
    endpoint: /api/admin/tickets
    query:
      status: open
  - name: closed-tickets
    endpoint: /api/admin/tickets
    query:
      status: closed

Each is then one word at the binding site, and the filter lives in one place rather than being restated in every component.

Which Components Accept One

Any data-bound component: data-table, list, gallery, kanban, calendar, chart, kpi and data-timeline. See Data Components for what each renders.

Cursor Feeds

Some platform endpoints paginate by cursor rather than by page number: each response carries a token for the rows after the ones it returned, and reports no total. Automation runs, the audit log and agent conversations all read this way — a feed still being written to has no stable count to report.

A grid bound to such a source gets a different surface from the numbered pager:

This holds even when the component declares pagination. A pageSize still sets how many rows each request asks for, but the pager it would otherwise draw is not rendered and no total is shown. That is not a gap to work around: a cursor endpoint never reports how many rows exist, so any x of N on screen would be a number the server never sent — and an operator reads a displayed total as a count.

Appending rather than replacing follows from the same shape. A cursor only moves forward, so swapping the first page out for the second would put rows the reader has already seen out of reach for the rest of the session.

Changing the search term, the sort or a filter starts a different sequence, so the accumulated rows and the token are both dropped and the feed restarts from the top. Load more carries the active search and sort into the next request, so a continuation never silently widens back to the unfiltered feed.

Page Size

query can set the page size for the endpoint itself:

systemSources:
  - name: recent-runs
    endpoint: /api/admin/automations/runs
    query:
      limit: '5'

A limit declared this way wins over the component's own pagination.pageSize. Naming it on the source is the author saying what a page of this endpoint is, which is the more specific statement — and it applies to every component bound to the source, so two grids reading the same feed cannot disagree about how much they ask for.

Leave limit out and the component's pageSize is used instead.

Validation

• The catalog must declare at least one source when present.
• Every name must be unique — a duplicate would make a reference ambiguous.
• Every { systemSource: <name> } reference must point at a declared entry.

All three are checked when the config is decoded, so sovrium validate catches a typo'd reference offline, before the app boots.

Related Pages

• Data Binding — the dataSource module, table binding, and the inline system form.
• Data Components — the components that consume a source.
• Pages Overview — where a bound component sits in the page tree.
• API Reference — the endpoints a system source can read.
• Admin Dashboard — the operator console built from these bindings.