Six months after launch, Meridian Line's evaluation team wants to build a fine-tuning dataset from real customs-compliance agent interactions, but discovers the endpoint was never configured to retain request/response content — only aggregate token counts were ever available. What should have been configured from the start to make this possible?
Select an answer to reveal the explanation.
Short Explanation
Token counts tell you how much was said, not what was said. If you want the actual conversations later, payload logging has to be turned on before those conversations happen — there's no way to retrieve content that was never captured.
Full Explanation
Payload logging is the AI Gateway control that retains the actual content of requests and responses, and it has to be enabled proactively — there's no way to retroactively recover conversation content that was never captured, since usage tracking alone only reports aggregate metrics like token counts, not the underlying text. Token counts cannot be reconstructed back into the original prompts and completions; the information simply wasn't retained. Rate limiting caps how many requests are allowed through in a time window — it has no relationship to whether content is retained or discarded, and a stricter limit wouldn't have changed what data was stored versus dropped. Claiming Model Serving never retains any content under any configuration is false — payload logging exists specifically to provide this capability, and the scenario's actual lesson is that it must be turned on ahead of time, not that it's unavailable. This is a case where the earlier point (payload logging is the source for eval/fine-tuning datasets) has a real consequence: the decision to enable it can't be made after the traffic you wanted has already come and gone. Exam framing: reinforces payload logging's purpose and adds the operational lesson that AI Gateway logging decisions are effectively 'configure before you need it.'