Define slice acceptance before you chase features

The quality bar for this project is not whether the output feels polished in a chat window. Review it in the conditions faced by a mentor reviewing whether a learner can make sound engineering trade-offs. Check completeness, fidelity to the supplied facts, accessibility, and whether the result helps the next person take the intended action. Use a simple score: pass, revise, or cannot judge yet.

a source-linked answer, a small held-out question set, trace records, and a milestone demo are the evidence set. Compare the output directly against them. A claim that seems likely but cannot be checked is an unknown, not a pass. Record one reason for every revision; that note will reveal whether the problem was missing context, an unclear request, or a constraint the tool cannot meet.

Write a short record before you move on. For a personal knowledge assistant that answers questions from approved notes with citations, state the claim or choice under review, then name the evidence that supports it: a source-linked answer, a small held-out question set, trace records, and a milestone demo. 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 mentor reviewing whether a learner can make sound engineering trade-offs 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: a citation cannot point to a source span, the evaluation set is missing, or a proposed feature has no user need. A documented pause is a successful outcome when it keeps a weak result from becoming a consequential one.