> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.nvidia.com/sdgm/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/sdgm/_mcp/server.

# Core Concepts

> Understand structured inputs, relational context, targets, prediction time, and results before building a Kumo workflow.

Kumo workflows connect source records, a prediction task, and model outputs. These concepts help you prepare inputs and interpret results across Structured Data Models, Structured Data Models Client, and Kumo Engine. The APIs and supported input types differ by path.

## Libraries and Models

A **library** provides the programming interface and data preparation workflow. A **model** uses prepared inputs to produce predictions. Structured Data Models runs supported pretrained models in Python. Kumo Engine fits and scores a model for a task. The Structured Data Models Client tab documents Kumo Relational Client, which prepares requests for a model served by a NIM.

Select the library based on execution and setup needs, then check that its model supports your data and task. Refer to [Choose a Library or Tool](/about-nvidia-kumo/overview#choose-how-to-run).

## Column Semantics

A data type describes how a column’s values are stored; a semantic type describes their role. An integer might be a measurement, category, or identifier. Treating a customer identifier as a numerical measurement changes what information the model receives.

Inspect column metadata and choose appropriate preprocessing before prediction. A representation that can store text or categories does not guarantee that every model accepts them directly.

See [Structured Data Models table semantics](https://nvidia.github.io/structured-data-models/tensor.html) and [Structured Data Models Client data types](/kumo-relational/user-guide/prepare-data/data-types).

## Entities and Relationships

An **entity** is a record you may want to score, such as a customer or product. Event records capture activity, such as orders. Primary and foreign keys connect these records across tables.

For relational workflows, a **graph** describes those connections. The model uses sampled related records as context for a target entity. Single-table workflows do not require the same graph structure.

For example, customer records can link to orders, and order records can link to products. These relationships provide information beyond a customer's own row. See [Kumo Engine graphs](/kumo-engine/user-code-guide/set-up-a-graph/graphs) and [Structured Data Models Client graph creation](/kumo-relational/user-guide/build-a-relational-graph/graph-creation).

## Targets and Prediction Populations

The **target** is the outcome you want to predict. The **population** is the set of rows or entities for which you need predictions. Classification predicts categories; regression estimates numerical values.

For a customer task, the population might be active customers, while the target is whether each customer places an order during a specified future window. Define both before preparing labeled examples.

Kumo Engine and Structured Data Models Client use Predictive Query Language (PQL) to express tasks. Structured Data Models uses its model and tensor interfaces; PQL is not a shared requirement. See [Kumo Engine predictive queries](/kumo-engine/user-code-guide/train-a-model/predictive-queries) and [Structured Data Models Client prediction types](/kumo-relational/user-guide/make-predictions/prediction-types).

## Training and Inference Context

**Training examples** are labeled records used to fit model parameters. **Inference context** supplies examples to a pretrained model while it predicts unknown outcomes.

Kumo Engine trains a model for the selected task and retains a fitted model artifact. The in-context learning models in Structured Data Models and the relational model accessed through Structured Data Models Client use labeled examples as inference context, without fitting a separate model for each task.

These workflows still require data preparation and suitable examples. The number and format of context records depend on the selected model. See [Relational in-context learning](/kumo-relational/about-kumo-relational/introduction).

## Prediction Time and History

The **prediction time** marks when an outcome is estimated. For temporal tasks, historical records provide context and later outcomes can provide labels.

Configure time columns and sampling boundaries so the selected context reflects the history available at prediction time. You must also check that source features do not contain later information; sampling boundaries alone do not validate every feature.

See [Structured Data Models Client time columns](/kumo-relational/user-guide/prepare-data/time-columns). Temporal behavior depends on the model and task.

## Prediction Results

Result structure depends on the task and library. Classification can produce several class scores for an entity; regression produces numerical estimates or quantiles according to the model.

Preserve identifiers and timestamps when joining results back to source records. Do not assume that every result contains exactly one row per entity or uses the same container type.

Structured Data Models returns typed tensor outputs. Kumo Engine stores prediction artifacts and provides a DataFrame view when results fit in memory.

Kumo Relational Client returns a pandas DataFrame by default. When explanations are requested, it returns an `Explanation` object containing the prediction DataFrame. See [Kumo Engine predictions](/kumo-engine/user-code-guide/making-predictions) and [Structured Data Models Client result contracts](/kumo-relational/user-guide/work-with-prediction-results/prediction-results).

## Next Steps

Review [Workflow Overview](/about-nvidia-kumo/architecture) to understand execution and data movement, or return to [Overview](/about-nvidia-kumo/overview) to choose a getting-started path.