I have a TypeScript service where one file defines the current AI provider registry and another file hardcodes model chains for a ranking engine.

The issue is that the ranking engine still references older model IDs while the provider registry has already been updated. That means the app now has two sources of truth for model identity.

For example the provider registry has already moved to newer models such as openai/gpt-4.1-mini and anthropic/claude-4-haiku while the ranking engine still uses older IDs such as openai/gpt-4o-mini and anthropic/claude-3.5-haiku.

This creates a few practical problems in production. Ranking behavior can drift from the rest of the platform. Fallback behavior can differ from what the provider layer is supposed to do. Short names in reports can get out of sync. Model upgrades require editing multiple files by hand.

This is the current shape in simplified form.

In aiProviders.ts I define the current provider registry:

export const PROVIDERS = [
  { model: 'openai/gpt-4.1-mini' },
  { model: 'anthropic/claude-4-haiku' },
  { model: 'google/gemini-2.5-flash' },
];

In cEngine.ts I still have a separate hardcoded model chain:

const RANKING_MODEL_CHAIN = [
  { model: 'openai/gpt-4o-mini', role: 'primary' },
  { model: 'anthropic/claude-3.5-haiku', role: 'fallback' },
  { model: 'google/gemini-2.0-flash-exp', role: 'fallback' },
];

There is also a separate short name mapping used for reporting so drift can happen there as well.

This still works if the old model IDs are still accepted upstream but it feels brittle and easy to break during future upgrades.

What is the cleanest pattern in TypeScript for preventing this kind of registry drift

Should feature specific services import provider definitions directly from a shared registry

Or is there a better pattern for keeping feature specific ordering while still having one source of truth for model identity labels and metadata

What I want is

one canonical place for model IDs

feature specific ordering still possible

type safety so invalid model references fail early

no duplicated display name or short name mapping if possible