Is a column the same as a feature?

Not always. A source column can become one, several or no model features after processing.

Is a column the same as a field?

The words often overlap, but “field” can also mean a particular value position within one record. Define usage in context.

Does column order matter?

It may matter to particular software interfaces, especially numerical arrays. Use an explicit mapping and validate the expected order.

AI Glossary / Governance, ethics and safety / Beginner

Column

Definition

A column is a named vertical part of a table that holds values for a particular attribute or field across its rows. In a structured database, the column also has a defined data type and may have constraints that govern which values are permitted.

What it means

In a table of deliveries, each row might represent one delivery while columns represent its identifier, dispatch date, weight and destination. Reading across a row gives the recorded attributes of that delivery; reading down a column gives values of the same attribute across deliveries.

In AI datasets, some columns become input features, another may contain the target to predict, and others may serve as identifiers or audit information. A column is not automatically a useful or appropriate feature merely because it is present.

The meaning belongs to the data definition, not just the heading. A column called “date” could mean booking date, dispatch date or arrival date. Without that distinction, an AI system or analyst can draw incorrect conclusions from otherwise well-formed values.

How it works

A table schema defines its columns, including names and types such as integer, text or date. Additional rules may require values, restrict ranges or identify keys. These controls help maintain structure, but they cannot fully determine whether the recorded facts are correct.

Operations select, calculate, join or transform columns. An AI preparation pipeline may encode a categorical column into several numerical features or combine several source columns into one derived feature. The number of model features therefore need not equal the number of source columns.

Missing values, units and time availability require explicit handling. A blank weight is not necessarily zero, and a value recorded after an outcome may be unsuitable for predicting that outcome. When moving data between spreadsheets, databases and model inputs, preserve names, types and alignment so that values retain their intended meaning.

Three practical examples

A demand dataset includes an order-date column used to create calendar features, while the later delivery-date column is withheld from an earlier forecasting decision.
A customer table stores a postal code as text so leading zeros are preserved and the value is not treated as a quantity to average.
A model pipeline converts one product-category column into several indicator features and documents the resulting feature order.

Think of it this way

Think of a paper form where the same question appears in the same position on every completed copy. A table column gathers the answers to that one question across copies.

The analogy is limited because database columns can contain more complex types, and a table's row meaning may differ from a simple form submission. The key point is consistency of meaning across values, not merely their visual alignment.

Worked example

Units change the calculation

Suppose an invented parcel table has columns parcel_id, weight_kg and delivery_days. Three rows contain weights 2, 4 and 6, with delivery times 1, 2 and 3. The mean weight is (2 + 4 + 6)/3 = 4 kilograms.

A new file arrives with a column labeled weight but values expressed in grams: 2,000, 4,000 and 6,000. If a pipeline maps it directly into weight_kg without conversion, the stored mean becomes 4,000 kilograms instead of 4. All values are valid numbers, so a basic numeric type check may pass.

The pipeline needs the source unit and an explicit conversion dividing by 1,000. A plausibility check can help reveal the mismatch. This example shows why a column's semantic definition and units are as important as its name and data type.

Illustrative case study

Fictional Rowan Retail trains a model from a spreadsheet whose third column is item count. A revised export inserts a new customer-reference column before it. The prediction script still reads the third position and silently supplies reference numbers where counts are expected.

The team changes the interface to map documented column names and validates the expected schema, types and ranges. It also records which source fields produce each model feature and tests a representative export before use.

The issue is not that reordering columns is inherently wrong. It is that the data contract between producer and consumer was implicit. The case illustrates how a small table change can alter AI behavior without changing the model itself.

Common misconceptions and mistakes

Every column should be fed into a model. Some contain targets, identifiers, unavailable future information or inappropriate data.
Numeric storage makes a value a meaningful quantity. Account numbers and postal codes can be identifiers.
A blank cell means zero. Missingness needs a defined interpretation.
Matching column names guarantees matching meaning. Units, timing and business definitions may differ.
A valid schema proves data accuracy. Structural checks do not verify every real-world fact.

Business use

Businesses should maintain a clear data dictionary for important columns, covering meaning, units, source, permitted values and when information becomes available. Identify owners for changes and define how downstream users learn about them. This makes analytics and AI pipelines easier to review and maintain.

For model work, document which columns are inputs, targets and supporting metadata. Check whether joins duplicate rows or misalign values and whether sensitive information is being exposed unnecessarily. Clear column definitions are a basic governance control because many sophisticated model failures begin with a simple misunderstanding of a field.

Check your understanding

A numeric column named customer_id contains values 1001, 1002 and 1003. Should its average automatically be treated as a meaningful customer characteristic?

Answer: No. Those values identify records; their numeric representation does not make arithmetic interpretation appropriate.

Related terms

Table
Schema
Data type
Feature
Missing values
Data leakage
Row
field
data dictionary
missing value

Learn next

Read schema and data dictionary. Choose five columns from a dataset and record each one's meaning, unit, type, missing-value interpretation and availability time. Then identify which are appropriate inputs for a proposed model.

Schema

Sources

PostgreSQL, Table Basics: https://www.postgresql.org/docs/current/ddl-basics.html. pandas, Intro to data structures: https://pandas.pydata.org/docs/user_guide/dsintro.html. These support table structure, types and alignment concepts. Parcel calculations and the retail export case are original illustrations.

Previous: Colorization (scribble-based) Next: Column space