Prompt and scope
You own an enterprise AI assistant. Sometimes it should answer, sometimes clarify, and sometimes refuse or escalate. Define the routing policy, target user, and success metrics. Explain how you handle wrong answers, over-refusal, privacy risk, human capacity, and launch validation.
Recent public Copilot PM interview material combines AI depth, product judgment, and evaluation design. The OpenAI Model Spec also connects expressing uncertainty with how a user may act, the cost of being wrong, and missing information. The product challenge is therefore turning uncertainty into a user-visible and operable decision policy.
What the interviewer is testing
- Whether you define the user task, risk tier, and acceptable error before discussing models.
- Whether answer, clarify, refuse, and escalate are mutually exclusive, observable states.
- Whether you distinguish internal model signals from answer quality and safe user action.
- Whether you measure helpfulness, harmful errors, over-refusal, human cost, and wait time together.
- Whether you validate with staged rollout, offline evaluation, and real feedback instead of one average satisfaction score.
Clarifications to ask first
- Who is the primary user? Assume an employee with access to organization knowledge, but not authority to make high-risk decisions for the user.
- Which tasks may be automated? Assume low-risk retrieval and drafting are allowed; high-risk actions need confirmation or human review.
- What is the human-team capacity? Assume shifts and response targets exist; every uncertain request cannot be escalated.
- Which failure is more costly? If unspecified, tier wrong answers and over-refusal by risk rather than optimizing one global rate.
- Will conversations be retained for improvement? Clarify redaction, access, retention, and opt-out before measuring.
30-second answer
I would route by task risk and evidence: answer low-risk requests with sufficient evidence; ask a minimal clarifying question when missing context changes the answer; refuse and offer a safe next step for high-risk, unauthorized, or unverifiable requests; escalate when professional judgment or a complex case requires a human. A model-reported probability is only one signal, not a truth guarantee. I would measure correct-helpful rate, severe error rate, clarification resolution, over-refusal, escalation rate, and response time by task and user segment, then validate with a staged rollout.
Step-by-step deep dive
Step 1: Build a task and risk matrix
Classify tasks by impact and mark whether they require organization permissions, fresh facts, or an irreversible action. Low-risk retrieval can tolerate minor wording issues; payments, compliance, medical, or permission changes need a higher evidence threshold. The matrix controls routing instead of a vague belief that the model is capable.
Step 2: Define four outcome contracts
answer includes evidence scope, freshness, and an editable result. clarify asks only questions that can change the answer. refuse states the boundary and a safe alternative. escalate explains why, carries the minimum context, and states the human response target. Every outcome gets a reason code for evaluation and appeals.
Step 3: Establish evidence and uncertainty signals
Evidence may come from authorized retrieval, structured business state, or human confirmation. Do not expose a model self-score as a “correctness percentage”; evaluate calibration, coverage, and error cost with labeled data for each risk tier. When evidence is insufficient, clarification or escalation is a product behavior, not a hidden model failure.
Step 4: Control clarification cost
Each question should reduce a material uncertainty. Ask about the object, time range, or permission scope before asking open-ended questions. Set a question limit, then offer options or escalate. Track the number of clarification turns, resolution after clarification, and abandonment.
Step 5: Design refusal and escalation
Separate unsafe, unauthorized, under-specified, and service-failure refusals because their next steps differ. An escalation carries minimum necessary context and an expected wait. When the queue is full, prioritize high-impact cases; low-risk requests can receive an editable draft or a self-service path.
Step 6: Build an evaluation set and metric tree
Include normal, ambiguous, adversarial, permission-boundary, and high-risk long-tail requests. The top-level goal is useful behavior without unacceptable harm. Break it into correct-helpful rate, severe error rate, over-refusal, clarification resolution, successful escalation, handling time, and cost. Slice every metric by task, user, language, and permission.
Step 7: Plan rollout, rollback, and appeals
Start with low-risk tasks and internal users. Predefine severe-error, over-refusal, and human-capacity thresholds. Stop expansion or roll back the policy version when a threshold is crossed. Let users mark an answer as wrong, unresolved, or incorrectly refused; route high-impact cases to review and add them to the evaluation set.
Step 8: Protect privacy and iterate
Store policy version, reason code, and only the necessary redacted evidence. Restrict raw conversation access. Training and evaluation data need retention, deletion, and access-audit rules. Compare every policy change on a fixed regression set across helpfulness, harm, refusal, and human cost so one local metric cannot hide a regression.
High-quality sample answer
I would define this as a risk-tiered decision product. Answer low-risk tasks with authorized evidence; ask the fewest clarifying questions when missing context changes the answer; refuse high-risk, unauthorized, or unverifiable requests with a safe next step; and escalate professional judgment or complex disputes with the minimum necessary context. An internal probability is only a signal, not a user-facing accuracy promise. I would build an evaluation set covering normal, ambiguous, adversarial, and high-risk cases, then segment correct-helpful rate, severe errors, over-refusal, post-clarification resolution, escalation wait, and cost. I would launch in low-risk cohorts with explicit stop thresholds, rollback versions, and an appeal path, while retaining policy and evidence records under access and retention controls.
Common mistakes
- Comparing model sizes before defining user tasks and error costs.
- Showing a model self-score as an accuracy promise.
- Asking endless clarifying questions that increase abandonment.
- Escalating every uncertain request without a human-capacity policy.
- Measuring only average satisfaction instead of severe errors, over-refusal, and segments.
- Refusing without a reason or next step, leaving users unable to finish or appeal.
- Retaining raw conversations indefinitely for training without access, redaction, or deletion controls.
Follow-up questions and answers
The business wants the lowest possible escalation rate. How do you respond?
Clarify whether the goal is fewer unnecessary escalations or fewer escalations of every kind. Expand automation for low-risk, well-evidenced tasks while keeping a high-risk floor. Use severe errors and human remediation cost to show why escalation rate alone can create hidden losses.
The user says, “Skip the explanation and execute it for me.” What do you do?
Separate irreversible actions from editable suggestions. Show a summary and confirmation for low-risk actions; require explicit authorization and auditability for payment, permission, or external-send actions. User preference cannot bypass authorization or safety boundaries.
How do you know a clarification question is valuable?
Compare answer quality and resolution before and after the question on offline data. Record information gain, extra turns, and abandonment. Remove questions that do not change routing or the answer; offer choices when a high-value question is hard to answer.
Accuracy improves after a model upgrade, but complaints rise. How do you investigate?
Slice by risk, user group, language, permission, and policy version to separate wrong answers, tone changes, over-refusal, and escalation delay. Freeze expansion, replay high-impact cases, compare old and new evaluation sets with real feedback, then roll back, limit the cohort, or adjust routing thresholds.