A prompt registry tracks alias 'support@production'. The registry log shows: 14:00 alias points at v17; 14:35 promoted alias to v18; 15:02 promoted alias to v19; 15:18 incident: rolled alias back to v18; 15:25 incident continues: rolled alias back to v17; 15:50 incident resolved; 16:10 cherry picked the v18 only schema fix into v19 and promoted that as v20; alias updated. A request arrives at 16:15 reading 'support@production'. Predict the version id the runtime resolves.
A prompt-registry alias resolves by latest write wins: walk the log in order, and the final pointer state determines what the runtime reads. Here it is v20.
Think of a sticky note on a folder that says which version of the document inside is the official one. The folder might hold v17, v18, v19, v20 of the document, but the sticky note has only one version written on it at a time. Every time someone updates the sticky note, the old number is crossed out and a new one is written in. When a customer asks for the official version, the clerk reads the sticky note as it looks right now, not as it looked an hour ago. The whole sequence of updates does not matter to the clerk; only the latest one matters. A prompt registry alias works exactly like that sticky note.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
This question looks like a logic puzzle but it is really testing whether the candidate understands how prompt registries actually resolve aliases in production. The whole point of a registry-alias pattern is that resolution is simple: read the current pointer value, get the version. The history of how that pointer got to its current value is recorded in an audit log for human review, but the runtime resolver does not consult it.
What makes the question interesting is that the scenario includes a real incident with real rollbacks. Each rollback served traffic for some period of time, which has implications for trace tagging, postmortem reconstruction, and the discipline required to investigate what actually happened during the incident. The answer to 'what does the alias resolve to at 16:15' is the easy part. The harder questions live in the followups.
This walkthrough covers the resolution semantics, the operational subtleties that production engineers actually hit (cache propagation, cross-region replication, trace tagging), and the design philosophy behind the registry-alias pattern as a whole.
Mental model: the alias is a single mutable pointer with an audit history. Resolution reads the pointer; debugging reads the history. Keep the two clearly separated.
Latest-write-wins resolution
The semantics
A prompt-registry alias is a key-value store entry: the key is the alias name (support@production), the value is the version id (v17, v18, v19, v20). Writes overwrite the value; reads return the current value. There is no concept of stacking, merging, or replaying.
Walking the log for this scenario
- 14:00: alias = v17 (starting state).
- 14:35: alias = v18 (promotion).
- 15:02: alias = v19 (promotion).
- 15:18: alias = v18 (rollback).
- 15:25: alias = v17 (further rollback).
- 15:50: incident resolved, but the alias was not changed at this step. Still v17.
- 16:10: alias = v20 (cherry-pick hot-fix promoted).
A request at 16:15 reads the current value, which is v20.
Why the rollback chain does not affect the answer
Rollbacks are writes. The rollback to v17 at 15:25 was a real write that affected the alias for the next 45 minutes. But the write at 16:10 overwrote that value. The current resolution is determined entirely by the latest write.
Audit history vs runtime resolution
The full sequence (v17, v18, v19, v18, v17, v20) lives in the registry's audit log. The audit log is for human review during postmortem analysis. The runtime resolver only reads the current pointer value. Conflating the two leads to wrong intuitions about how the system behaves.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
Real products, models, and research that use this idea.
- LangSmith Hub implements named prompt versions with alias pointers; rollback is a single API call that flips the pointer.
- PromptLayer offers version control for prompts with alias-based resolution and audit-log history identical to this scenario.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you instrument so that an investigation of the 15:30 traffic can identify what prompt was actually used?
Tag every request span with prompt.version (the resolved version id) and prompt.alias (the alias that was resolved). Both are critical: the version id tells you what was executed, the alias tells you which deployment surface routed there. Without both, you can identify what ran but not why.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Adding up the rollback steps or trying to merge them. Aliases do not merge; they overwrite. Only the final pointer write matters at resolve time.
60 second bullets to scan on the way to the call.
Latest-write-wins as the resolution rule for prompt aliases
Why intermediate states served real traffic but do not affect current resolution
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.