Get better AI test cases by keeping Canon small, current and limited to documents your team agrees are correct.
Add Only What You’d Accept as Proof
Section titled “Add Only What You’d Accept as Proof”Ask one question about each document: if a test case cited this, would you accept it as proof of how the product should behave?
| Add to Canon | Leave in Files |
|---|---|
| Product requirement documents | Meeting notes and brainstorms |
| Feature specs and design docs | Draft specs still being discussed |
| API contracts | Bug reports and support tickets |
| Acceptance and exit criteria | Screenshots and recordings |
| Standards you must follow | Old versions kept for history |
The AI treats everything in Canon as correct. An old or draft spec gets cited just as confidently as the current one.
Write Down Outcomes, Not Just Features
Section titled “Write Down Outcomes, Not Just Features”The AI can only test what your document actually says. A spec that lists features without saying what should happen gives it nothing to check.
- Weak: “Users may edit shared steps.”
- Strong: “The Create Shared Step button stays disabled until the name is filled in.”
The strong sentence becomes a test case with a clear expected result. The weak one becomes a test case that just repeats the requirement.
If a spec is light on outcomes, the quickest fix is usually to add numbered steps and the exact error messages. Those turn directly into test steps and expected results.
Quick Checklist
Section titled “Quick Checklist”- Clear titles. Rename documents so a reviewer recognises them on a source tag. See Give the document a clear title.
- Check before you generate. Ask about two or three topics first. See Ask Canon.
- Keep it current. Upload new versions and remove old ones. See Update a document to a new version.
- Watch Grounding now and the passage count. A listed document isn’t always a used one. See Check the passage count.
- Keep workspace documents few. They affect every project. See Workspace documents.