The shape
Why negative examples matter most
Positive examples teach the signal what to catch. Negative examples teach it what to stop catching — and that’s where noisy signals come from. Three failure modes account for most of it: Seller statements matching instead of buyer statements. Your rep speculating “they’ll probably need a security review” is not the customer requiring one. Say so explicitly. Adjacent topics matching. A signal for “custom UI requirements” will happily match someone asking for your design system docs unless you rule it out. Hypotheticals matching. “We might want this someday” and “we need this to move forward” read similarly to a model and mean opposite things commercially.Be specific about whose words count
The single highest-leverage sentence in most instructions names the speaker:This signal tracks explicit statements from buyer-side stakeholders — such as product managers, designers, or technical leads.Without it, you’ll capture your own team’s internal chatter alongside genuine customer signal.
Scope the document types deliberately
Instructions and document types work together. A signal about formal requirements probably belongs ondocument, email, and transcript — not brain-dump, where people think out loud.
Narrowing document types is also the cheapest way to cut noise without touching the instructions at all.
Iterate against the preview
Draft, preview, read the misses, refine, preview again. The preview runs against real artifacts, so it tells you what the signal actually does rather than what you meant. Two questions to ask of every preview:- What did it catch that it shouldn’t have? Each of those is a missing negative example.
- What did it miss? Each of those is either a missing positive example or a document type you didn’t include.
Limits
Instructions can be long. Use the room — a signal with six well-chosen examples will outperform one with a single sentence every time.