Evaluation-to-production alignment
You are the last gate before an agent with real permissions reaches production. It behaves well on every evaluation you run. What you owe the release meeting is an argument that this behavior is evidence about production, given that evaluations are distinguishable from deployment by many cues: synthetic scaffolding, tasks that terminate, side effects that do not persist, prompts written by your own team, and the plain fact that the environment was constructed.
Design the evidence gathering architecture and the analysis that reads it.
The exits are closed. You may not retrain or fine tune, so you cannot train out sensitivity to evaluation cues. You may not learn the answer by shipping unmonitored to real users, since that is the risk you are trying to bound. You may not take the system's own account of whether it believes it is being evaluated as evidence, because verbalized reasoning is not established to be causal on the action taken. You may not assume you can build an environment indistinguishable from production, because the absence of a cue is not something you can demonstrate.
Hand in the architecture: what environments you construct, what you vary and what you hold fixed, what you record, and the rule that turns the record into a decision. Then state the inferential claim. Say precisely what your evidence licenses and what it does not, given that a system insensitive to every cue you varied may still be sensitive to one you did not. Then attack yourself. Describe a behavior pattern your architecture scores as safe while production behavior differs, and say what closing that gap would cost. Ties break toward the architecture whose conclusion is narrow and supported, over one whose conclusion is broad and rests on an indistinguishability assumption.
Clarify scale and constraints first. Propose a clean component breakdown, then go deep on the hard parts (data model, bottlenecks, consistency, failure modes) and name the trade-offs you are making.