Last verified: September 16, 2026
What You Can Now Do
Context Memo now lets you filter and select offers based on memo type affinity, choosing which types of memos are most relevant to each offer directly in the offers view. The offers list is no longer a flat inventory where every offer looks equally applicable to every memo. Each offer now carries an affinity to the memo types it actually fits, and you can filter the list down to just those matches before you attach anything. The decision this changes is the one you make at publish time: instead of defaulting to the same offer across a memo set, you pick the offer that belongs with that memo type.
Where It Is in Context Memo
Offers view. The offers picker in that screen now reads from a memo-type affinity table, so each offer displays the memo types it's suited for and the list can be filtered by type. The same affinity data is available through the offers coverage API, so if you pull offer coverage into a dashboard or a downstream workflow, the memo-type dimension is now in the response alongside the coverage fields you already consume.
How to Use It
- Open the offers view. Every offer in the list now shows its memo-type affinity. Offers with no affinity set are visible and unfiltered, so nothing you already had configured disappears.
- Set affinity on each offer. Select the memo types the offer is relevant to. This is what populates the affinity table the picker and the API both read from.
- Filter the list by memo type. Choose the type you're about to publish and the list narrows to offers with a matching affinity. What's left is the shortlist worth choosing from.
- Select the offer and continue publishing. The selection behaves exactly as before. Only the candidate set in front of you has changed.
- Query the offers coverage API for the same view. Request offer coverage with the memo-type filter to get the recommended set programmatically. Useful if you assign offers in bulk or audit coverage by type outside the UI.
- Re-run the filter when you add a new memo type to your strategy. Gaps show up immediately as types with thin or empty offer coverage.
Why We Built It
Customers told us they wanted to match offers to the memo types they actually publish, instead of treating all offers the same way. Before this, the picker gave you the full offer list with no signal about fit, so the work of deciding which offer belonged on which kind of memo happened in a spreadsheet or in someone's head. That cost two ways. Offers got attached to memos where the reader intent didn't match, which weakens the conversion path on a page you spent real effort making citation-grade. And coverage gaps stayed invisible: there was no way to see that an entire memo type had no suitable offer behind it until someone noticed after the fact.
What It Does Not Do Yet
Affinity is defined at the memo type level, not per individual memo. If two memos of the same type need different offers, you still make that call manually at selection time.
Affinity also has to be set by you. We don't infer it from memo content or from citation and traffic performance, and the filter doesn't rerank offers by how they've performed in AI-sourced sessions. The recommendation is only as good as the affinity table behind it, so the first pass through your offers list is worth doing deliberately rather than in bulk.
Filtering surfaces in the offers view and the offers coverage API. It isn't yet applied automatically during auto-memo generation, so memos created that way still take whatever offer selection logic you had configured before this release.
