# The Hard Part of Predictive AI Isn’t the Model

I’ve spent most of my career building predictive systems on tabular data.

The highest-value AI systems I’ve seen in production aren’t LLMs. They’re predictive models that operate on structured operational data: customers, orders, shipments, transactions, support events, etc.

These systems quietly generate millions in value by:

- replacing expensive third-party services - improving operational decisions - turning predictions into products

Examples include:

- churn prediction - fraud detection - ETA prediction - inventory demand forecasting - operational anomaly detection

In practice, the model itself is rarely the bottleneck.

The real bottleneck is integrating signals from relational data.

# Why Tabular Data Is Hard

Most operational systems store data across many relational tables, not a single ML-ready dataset.

For example, consider a simple commerce schema:

customers --------- customer_id signup_date region industry

orders ------ order_id customer_id order_timestamp order_value

order_notifications ------------------- notification_id order_id notification_type timestamp

If you want to train a model predicting something like:

"Will this customer churn in the next 30 days?"

the model does NOT train directly on these tables.

Instead you must first construct a training table like:

customer_id num_orders_last_30_days avg_order_value days_since_last_order num_notifications_last_7_days notification_rate_per_order ... target_churn

Building this dataset requires:

- joins - aggregations - time windows - handling one-to-many relationships - preventing data leakage

For example:

num_orders_last_30_days = COUNT(orders WHERE order_timestamp >= now() - 30d)

num_notifications_last_7_days = COUNT(order_notifications WHERE timestamp >= now() - 7d)

This sounds simple, but at scale this quickly becomes:

- hundreds of features - dozens of tables - complex temporal joins

In most organizations this data preparation step dominates the project.

Not the model.

# Where Tabular Foundation Models Fit

Recently there has been a lot of excitement around tabular foundation models, such as:

- TabPFN - TabTransformer variants - other pretrained tabular architectures

These models are interesting because they can often produce strong predictions with very little tuning.

You can often train them with something as simple as:

model.fit(X_train, y_train)

and they work surprisingly well.

However, these models typically expect a single flat table.

Something like:

customer_id f1 f2 f3 f4 ... target

They generally do NOT operate directly on relational schemas.

So the fundamental bottleneck remains:

How do you turn relational data into a useful feature table?

# GraphReduce: Treating Relational Data as a Graph

This is where approaches like GraphReduce come in.

Relational schemas naturally form a graph structure.

Using the previous example:

Each edge represents a relationship where signals can propagate.

For example:

orders → customers notifications → orders → customers

GraphReduce treats the schema as a propagation graph.

Each table contributes signals that are aggregated upward.

Example propagation:

From order_notifications → orders:

notifications_per_order max_notification_delay notification_count

Then from orders → customers:

total_orders avg_order_value orders_last_30_days notification_rate_per_order

The result is a feature table at the target level:

customer_id orders_last_30_days avg_order_value notification_rate days_since_last_order ...

This table can then be fed directly into a predictive model.

# Why This Matters for Tabular Foundation Models

Tabular foundation models are strongest when operating on a well-constructed flat dataset.

GraphReduce helps produce that dataset automatically by:

- traversing relational graphs - aggregating signals - generating structured features

The pipeline becomes:

Relational DB ↓ GraphReduce (relational signal propagation) ↓ Unified feature table ↓ Tabular foundation model (e.g. TabPFN) ↓ Prediction

In practice this can dramatically increase the throughput of building predictive systems, because the hardest step (data integration) becomes much easier.

# Why This Is Still an Open Problem

Most AI discussion today focuses on models.

But for structured data systems, the real challenges are:

- relational structure - temporal aggregation - signal propagation - feature construction

Until those problems are solved, the modeling layer will always be limited.

Tabular foundation models may significantly reduce the modeling effort.

But relational data preparation remains the gating step.

The interesting opportunity is combining both.

# Example Implementation

Here is a simple end-to-end example combining relational aggregation with a tabular foundation model:

https://wesmadrigal.github.io/GraphReduce/end_to_end_examples/predictive_ai_tabpfn/

There is some similar research coming out of the University of Hong Kong: https://arxiv.org/pdf/2602.13697

Golf club firm owned by Trump's sons merges with drone manufacturer

Durdraw – ANSI art editor for Unix-like systems

Show HN: Focus music and Pomodoro app for lazer focus

Is AI killing open-source software?

Ragflow: fuses RAG with Agent capabilities to create context layer for LLMs

Dify: Production-ready platform for agentic workflow development

Show HN: I built a database of air fry times for 300+ foods

Workers report watching Ray-Ban Meta-shot footage of people using the bathroom

I built a time-travel debugger for AI agents

Autopsy – Open-source CLI that diagnoses production incidents in 30 seconds

Re-engineering our flow state

Anthropic sues US Government for calling it a risk

Anthropic Sues the Trump Administration

Why Most Valuable AI Systems Are Still Tabular Models

Now we have proof: dealing with difficult people does age you

HP 197A oscilloscope camera Instax conversion [video]

Contrarian view: Data centers vs. Meat

Show HN: Agentic CLI, Gideon Wins Nvidia GTC Golden Ticket for AI Innovation

Show HN: MindfulClaude – Guided breathing during Claude Code's thinking time

Hill-climbing ARC-AGI-3

MXSS: Mutation cross-site scripting explained

Reverse Engineering Action's Cheap Fichero Labelprinter

Show HN: I built an MCP server so Agents can launch RWAs and compliant tokens

Show HN: FeralDeps, local dependency and vulnerability scanner for Java projects

AI in Trump's 3-D Chess Match

Simplifying Git Worktrees

80M galaxies: Gigantic astronomical catalog viewable online

LocalPDF V3 – 100% local, browser-based PDF studio (Free and No Ads)

The Lobster Pot

I fixed the same Supabase issues 100 times in my agency for vibe coders

Show HN: Local Code Mode: Save 65-99% Context for MCP