Why contexts matter
A context gives operators one place to control the recommendation behavior for a surface:- which model family and retrieval algorithm should be preferred
- which ranking recipe should shape candidate sources, signals, discovery, and guardrails
- which pipeline stages should run for that surface
- which hard pre-query filters should narrow the candidate pool
- which rules should reshape already-scored results
- which model is currently serving after fallback resolution
context_id; operators can then tune the surface without changing application code every time.
How context control fits together
| Layer | Role |
|---|---|
| Context | Names the product surface and stores its recommendation defaults. |
| Recipe | Describes the ranking strategy for the surface. |
| Pipeline | Controls the runtime stages candidates move through before results return. |
| Rules | Applies post-scoring business logic such as boost, bury, pin, filter, cap, dedupe, and grouping. |
| Explainability | Shows why a user-item recommendation behaved the way it did. |
Where to go next
- Console Contexts for the operator workflow inside the context editor.
- Launch a New Context for a staged rollout checklist.
- Pipeline Config for runtime ranking stages.
- Rules Engine for post-scoring controls.
- Recommendation Control Demo Path for a buyer-facing proof path through contexts, rules, pipelines, and explainability.