The workflow before
Axim's data products combined retirement plan data from Judy Diamond with Bloomberg market data. Specific EINs were hard-coded into the pipelines, the code made far more API calls than it needed, and Docker builds pulled from public registries and unpinned Python packages, so a routine rebuild could fail overnight. Matching records across the two vendors had no shared key and no dependable logic.
What we built
We ran a review and rework sprint on the existing pipelines. We removed the hard-coded EINs and other fixed values and moved them into configuration, and cut redundant API calls.
We moved Axim's Docker images into its own registry and pinned every Python dependency, so the same code builds the same way every day.
We documented the data quality gaps and wrote a plan for matching Judy Diamond and Bloomberg records where no shared key exists, with the assertions needed to catch bad matches before they reach customers.
Before and after
| Measure | Before | After |
|---|---|---|
| Daily build failures from dependency drift | Recurring | Down about 80% |
| Hard-coded EINs in pipeline code | In the pipelines | 0, moved to configuration |
| Docker image source | Public registries | Axim's own registry |
What's next
The next step is building the cross-vendor matching logic from the plan. Clean, matched data is the foundation for an L2 tool that answers questions over Axim's combined plan and market data.
