WORKING TEMPLATE · SIGNAL RECIPE
Signal Recipe Template: Strength, Freshness, Buyer, and Claim Rights
A signal becomes operational only when two people can apply the same rule and reach the same action. Use this template to make the source, freshness, buyer, claim, and fallback explicit.
THE SHORT VERSION
Key takeaways
- Define the recipe before collecting events at scale.
- Strength and TTL are event-specific hypotheses, not universal platform scores.
- Every recipe needs a no-signal fallback and an explicit blocked-claim boundary.
“Track hiring” is not a signal recipe. It does not define how many roles matter, which functions count, which source is trusted, when the event expires, who owns the problem, or what a message may say.
Copy this signal-recipe template
Recipe name/versionA stable identifier and revision date
Business hypothesisCompanies are more likely to need us when…
Account fitRequired company facts and explicit exclusions
Observable eventA rule two researchers can apply consistently
Accepted sourcesFirst-party, regulator, trusted publication, or defined provider
Evidence strengthBehavioral / attributive / inferred / none
Freshness TTLDays until event-specific language is blocked
Buyer ownerRole that owns the exposed problem and fallback role
Allowed claimExact specificity the source permits
Blocked claimMotive, budget, vendor replacement, or other unsupported leap
No-signal fallbackAudience-level problem statement
Dispatch policyReview lane, suppression gate, account budget, and autonomy level
Outcome learningReply classes and rejection reasons that change the recipe
Worked example: sales-team expansion
| Field | Example |
|---|---|
| Hypothesis | B2B SaaS teams expanding SDR headcount may need more reliable prospecting data. |
| Event | Five or more open SDR roles on the company careers site. |
| Strength | Attributive, medium. |
| TTL | 45 days from last verified opening. |
| Buyer | VP Sales; RevOps as adjacent owner. |
| Allowed | “I noticed the team is hiring several SDRs…” |
| Blocked | “You are struggling with data quality as you scale.” |
| Fallback | Role-level problem language without claiming a hiring event. |
Acceptance test before activation
- Can two reviewers classify the same source the same way?
- Can the system calculate expiry without human interpretation?
- Does the buyer rationale explain problem ownership?
- Is every specific opener traceable to a quote or event?
- Does expiry block event language while preserving history?
- Does send-time suppression still override an approved message?
- Do rejections and replies update the recipe version?
Start the recipe in review. Promote it only after repeated cases show stable evidence, buyer, and claim decisions.
COMMON QUESTIONS
Frequently asked questions
What is a signal recipe?
A signal recipe is a versioned rule that defines which accounts and observations qualify, which sources are acceptable, how long the observation remains fresh, who owns the exposed problem, and what action or language it permits.
How do I set signal strength?
Score the specificity of the observed behavior, source reliability, fit relevance, and buyer ownership separately. Do not use one opaque number to replace the underlying fields.
What is signal TTL?
TTL is the time window during which an observation may justify why-now language. After expiry, the historical fact can remain stored while the event-specific opener is blocked.
Should every recipe allow automated sending?
No. A new or sensitive recipe should begin with human review and earn narrow autonomy through consistent evidence and outcome quality.
SOURCE NOTES
Sources and further reading
Vendor-authored sources are used to document definitions, workflows, or platform policies—not as independent proof of product performance.
TURN THE FRAMEWORK INTO A SEARCH