Before fully cutting the safety-review summarizer over to a newly fine-tuned model version, Meridian Line wants real production requests scored by the new version's output without those outputs ever being shown to actual safety reviewers, purely to compare quality against the incumbent. Which deployment pattern fits, and how does it differ from traffic splitting?

Shadow deployment (sometimes called shadow testing) sends a copy of live production requests to the new model version so its outputs can be logged and compared against the incumbent, while the response actually returned to the user always comes from the current production version — the new version's outputs are never user-facing. This is exactly Meridian's requirement: real traffic, real comparison, zero end-user exposure to the unproven version. Traffic splitting is a different mechanism: whatever percentage is assigned to a version genuinely determines the response some real users receive, so a 0% weight wouldn't 'silently return all traffic' — it would mean that version receives essentially none of the routed traffic, the opposite of what's being described, and even a nonzero split would violate the 'never shown to reviewers' requirement by definition. Claiming shadow deployment and traffic splitting are the same mechanism erases the distinction the question turns on: one exposes real users to the new version's output (in proportion to its weight) and one deliberately does not. 'Blue-green deployment' is a real pattern in general software deployment, but describing it as deleting the incumbent endpoint the instant a new version exists misdescribes it — blue-green keeps both environments live and switches traffic atomically, and inventing an instant-deletion behavior doesn't match either blue-green or this requirement. Exam framing: recognizing when the requirement is 'compare without exposing' versus 'expose a fraction' is part of choosing correctly among staged-promotion patterns.