Feature engineering

A machine learning model can’t learn directly from raw source tables. Feature engineering is the AutoML sub-feature that transforms raw source tables into a clean, model-ready target table for machine learning training.

​

Key features

The feature engineering sub-feature provides the following:

• AI-generated feature recipes: Accepts a proposal describing your prediction problem and automatically designs a feature recipe and generates a SQL query from it.
• Built-in SQL validation: Validates generated SQL against Trino before presenting the proposal, so only working queries reach you.
• Configurable approval: Supports editing the recipe before committing. Nothing materializes without your approval.
• Data materialization: Materializes approved recipes to a target table.
• DataHub registration: Tags materialized target tables and records its lineage back to the source tables in DataHub.

​

How it works

The following sections explain the core concepts behind feature engineering in NexusOne.

​

What is a feature recipe?

At the core of feature engineering is something called a feature recipe. You design one by submitting a proposal to NexusOne. Before you submit one, it’s helpful to understand what a feature recipe is. As previously explained, a model can’t learn from raw source tables. A feature recipe is the specification that defines how to compute a clean, model-ready target table from source tables. An AI agent designs the feature recipe. The agent does this by inspecting your source tables and deciding which columns it wants to derive and add to a target table. The agent calls each of these derived columns a feature. It also writes a SQL expression for each one. The target table also contains the entity grain columns, which uniquely identify each row, and the label column, which is the outcome the model learns to predict. Neither are features. One example is a customer churn prediction model. Suppose your source tables contain the following columns:

• signup_date
• order_amount
• support_ticket_date

NexusOne can transform these source table columns into new columns/features in a target table such as:

• months_active: Computed from signup_date to represent how long the customer has been with the company
• avg_monthly_spend: Computed from order_amount to represent the average amount the customer spends per month
• tickets_last_30_days: Computed from support_ticket_date to represent the number of support tickets the customer raised in the last 30 days

These engineered features help the model learn patterns more effectively than the raw source table alone. Each feature in a feature recipe has the following core details:

• Name of the feature
• Description of why the feature is useful
• Data type of the feature
• SQL expression NexusOne runs during materialization to compute this column

​

Feature engineering proposals

To have NexusOne create a feature recipe, you must first create a feature engineering proposal. A feature engineering proposal is a request you send to NexusOne to design a feature recipe for your prediction problem. To create one, provide the following:

• Your prediction goal in plain language
• Source tables that hold your raw data
• Target table where NexusOne creates the model-ready dataset
• Entity grain columns that uniquely identify each row, which NexusOne carries into the target table as identifiers
• A label column that holds the outcome the model learns to predict

NexusOne then runs two AI agents in the background. The first agent designs the feature recipe and writes a SQL expression for each feature. The second agent assembles those expressions into a full query and validates it against Trino before presenting the proposal. Once you review and approve a proposal, NexusOne materializes the engineered features by running the full query against your source data and writing the results as real columns in a target table. That means the target table becomes an input dataset that’s model-ready, registered in DataHub, and ready for training by the NexusOne AutoML training sub-feature.

​

Use cases

These examples show how different industries can use NexusOne’s feature engineering capabilities:

• Retail: Prepare a demand forecasting dataset from sales history and product catalog data. Features might include recent sales trends and seasonal patterns.
• Financial services: Prepare a fraud detection dataset by combining transaction records with customer profiles. Features might include spending velocity and unusual transaction activity.