Building the Data Foundation for Repeatable AI

August 1st, 2022
Share:

Summary

The Problem: A global software company wanted to predict customer behavior from its own data. But each product captured a different part of the customer relationship, on a different schedule, and in a different format. Data scientists and analysts had to reconstruct account histories by hand, while model development depended on local code and siloed personal knowledge. Ghamut was brought in to design a repeatable process for turning the fragmented data into AI-ready data, and building a governance framework around the data-to-model lifecycle to ensure consistency, reproducibility, and effective deployment.

Our Approach: We developed a three-step process:

  1. Defining the Decision: We first established what models our client was looking to build, which actions they should guide, how far ahead they should predict, and where human judgment should enter.
  2. Building a Reusable Customer History: We converted fragmented, time-varying sources into a versioned feature store that preserved data ownership and provenance.
  3. Governing the Path to Use: We developed and implemented a process for peer review, reproducible model training, and integration of our outputs into common business tools.

The Impact: The engagement produced a data foundation and governance framework for AI development across the organization. It gave the company a repeatable way to transform distributed data into models that teams could inspect, compare, and deploy.




The Problem

Our client wanted to use AI to predict customer behavior, but its data ecosystem and model development process were too fragmented to support that ambition.

Like many large organizations, our client had grown through a series of strategic acquisitions, which had left customer knowledge scattered across individual product databases and siloed business units. Revenue could sit in one table, product activity in another, and account attributes in a third, each with its own structure and reporting schedule. The consequence was that answering a question as simple as “what did we know about this account in 2021?” required weeks of manual analytics work by a small number of employees with deep domain expertise.

Signals for one account, spread across three source systems and two years Account A-17 accumulates seven signals between 2020 and 2021. Three revenue figures sit in the revenue system, two region values in the external system, and sector attributes in the internal system, which has no value recorded for 2020. No single system holds the whole history. 2020 2021 Revenue External Internal $12K Product 1 $14K Product 1 $9K Product 2 North Region South Region Sector A Recorded Sector unknown Not yet recorded
Source A · Revenue
AccountProductTimeRevenue
A-17P12020$12K
A-17P12021$14K
A-17P22021$9K
Source B · External
AccountTimeRegion
A-172020North
A-172021South
Source C · Internal
AccountTimeSector
A-172020Unknown
A-172021A
Fig. 1: Our client collected customer data across multiple systems, business units, and time, but no source held the complete customer history. Color identifies the source system. The account, values, and labels are illustrative.

The same fragmentation we observed in the data also appeared in model development. Data scientists would regularly retrieve raw data, write custom scripts to restructure it, and train AI models on their company laptops before committing the results into one or more disjointed reporting systems. Local environments could not be reproduced, and new models were hard to compare against prior versions.

Our Approach

We created a reusable data infrastructure to support consistent and comparable model development across the organization.

1. Define the decision before designing the system: We conducted workshops and interviews with more than 30 stakeholders across business, product, and technical roles. The discussions established what customer behaviors the organization wanted to predict, who would use the predictions, and what prediction horizons were required.


2. Build a reusable customer history: We created a common representation for every observation: account, product, time, feature, value, owner, and source. Raw tables were then transformed in parallel into a versioned feature store, and pivoted into a consistent snapshot for a specific model or decision (see Fig. 2).

Raw · Source A
AcctProdTimeRevenue
A-17P12020$12K
A-17P12021$14K
A-17P22021$9K
Raw · Source B
AcctTimeRegion
A-172020North
A-172021South
Raw · Source C
AcctTimeSector
A-172020Unknown
A-172021A
Versioned feature store

Every feature keeps its owner and its source.

AcctProdTimeFeatureValueOwnerSource
A-17P12020Revenue$12KTeam AA
A-17P12021Revenue$14KTeam AA
A-17P22021Revenue$9KTeam AA
A-17All2020RegionNorthTeam BB
A-17All2021RegionSouthTeam BB
A-17All2021SectorATeam CC
Model-ready customer snapshot

What did we know about account A-17 in 2021?

AcctProdTimeRevenueRegionSector
A-17P12021$14KSouthA
A-17P22021$9KSouthA
Fig. 2: Disparate data tables were converted into one versioned representation that preserved feature ownership and source lineage, then assembled into a time-specific dataset for modeling.

3. Govern the path from data to business use: We added peer-review gates before data entered development, before an AI model moved to staging, and before the model reached production. Data and code moved through shared, containerized environments; models and their evaluations were stored centrally; and deployment followed a defined route back into sales and analytics systems (see Fig. 3).

Fig. 3: The development process connected shared data, compute, model storage, and business systems. Peer review made each transition recorded, reproducible, and comparable with the deployment it replaced.

The Impact

The result was a reusable system, and model development approach that accelerated AI development, organization-wide.

Data scientists could begin from shared, versioned customer histories instead of rediscovering source tables and rebuilding joins for each project. The feature store separated feature engineering from model development and allowed source transformations to proceed in parallel. Every feature retained its owner and source, making results traceable to the data that produced them, and model changes could be evaluated against the same review criteria before deployment.

Traceable dataEach feature retained its owner, source, and time context.
Comparable modelsEach proposed change was evaluated against the version already in use.
Reusable processThe workflow could support new models without rebuilding the foundation.

Prediction became something the company could do repeatedly, and iteratively because the system was organized around decisions, data lineage, review, and deployment. The same foundation was used to support AI models for customer acquisition, account expansion, cross-sell, and product strategy.

© 2026 Ghamut Corporation