Map → contract → connect → test → gate → observe

Run a visible loop for classifying customer feedback into a human-reviewed weekly summary that is never auto-sent: prepare the approved inputs, request a bounded output, validate it against the evidence, revise one issue, and send it to the named human gate. Each pass should leave a small record: input version, prompt version, output, reviewer decision, and unresolved question.

Do not turn a draft step into an irreversible action. The workflow stops when the output is not valid JSON, confidence is low, the comment contains sensitive data, or any step would email, refund, or update a customer. A stop is useful information: it tells you which approval, source, or test is missing. Once the gate approves, archive only what policy permits and note what should be monitored after release.

Write a short record before you move on. For classifying customer feedback into a human-reviewed weekly summary that is never auto-sent, state the claim or choice under review, then name the evidence that supports it: the original comment, a versioned label guide, JSON validation, a reviewer decision, and weekly aggregate counts. Next, name what the evidence does not establish. This last line prevents a narrow test from becoming a broad promise. If another team member opened your record next month, they should be able to reproduce the review without trusting your memory.

Now make the trade-off visible. A support lead running a low-risk workflow with a small operations team may value speed, clarity, cost, control, or reassurance differently. Explain which of those mattered in the current version and why. Do not let a model choose the trade-off simply because it can produce a confident answer. The responsible owner decides whether the upside justifies the remaining uncertainty.

Finally, connect the decision to a next action. If the current evidence is enough, identify the smallest safe step forward. If it is not, request a specific source, approval, or test. The stop condition remains concrete: the output is not valid JSON, confidence is low, the comment contains sensitive data, or any step would email, refund, or update a customer. A documented pause is a successful outcome when it keeps a weak result from becoming a consequential one.