Try the awkward case before you trust the routine
A rule earns its place by handling the situations that could send it in the wrong direction.
The easy case is usually easy to demonstrate.
An estimate was sent. No reply arrived. No reminder is queued. Prepare a follow-up draft.
Now change one fact: the estimate was already approved.
The illustration holds the fictional estimate reference and queued-message status constant. Changing only the approval status changes the next action: update the record instead of preparing a sales reminder.
The same polished reminder becomes inappropriate. We haven't made the writing task harder. We've changed the decision that should happen before the writing starts.
In our internal plumbing prototype, we used fictional cases like this to inspect the proposed process. Approved estimates, declined estimates, scope changes, queued messages and unknown status needed different handling. This was an internal exercise, not evidence of customer use or sales improvement.
A test case needs an expected result
“Try some examples” can become a tour of whichever outputs look convincing. A stronger review names the input condition and the behavior it should produce before examining the answer.
| Fictional condition | Expected behavior | Why it matters |
|---|---|---|
| Estimate approved; old reminder remains | Reconcile status; don't prepare the old sales follow-up | Current state overrides the stale reminder |
| Customer requests a scope change | Route the question to the authorized estimator | A writing assistant shouldn't invent revised terms |
| Message already queued | Inspect the queued action before adding another | Avoid duplicating work |
| Source unavailable; status unknown | Recover the source before deciding about contact | Missing evidence isn't evidence of no reply |
In testing language, cases that lead to the same expected behavior can form an equivalence class. You don't need every possible customer name to examine the approved-estimate branch. You do need a materially different case when a changed condition should change the action.
That is a practical design idea applied to our prototype, not a guarantee that these four cases cover a real business. Real use could reveal another branch.
Bring it back to your guide
Day 3 asked what a finished result would look like. Today's question goes further: under which conditions should the routine behave differently?
For our source-checking guide, try a missing comparison copy, an inaccessible page and a changed passage that does not affect the current advice. Write the expected outcome first. Then follow the instructions and see whether they lead there without extra explanation.
When you repair a discovered mistake, keep the case. Repeating that case after a later edit is a regression check: it asks whether a previously handled situation has broken again. It doesn't prove the whole routine correct, but it protects a lesson you have already paid attention to.
You can do this on paper before connecting any tool to a live account. In fact, the paper exercise may reveal that the difficult part is deciding what should happen, not generating the words that follow.
Which single changed fact would make your current routine take the wrong action? Start there.