Model Decisioning inputs by consumption
Decision inputs have different lifecycles, and they do not all belong in the profile.
Generic diagram. It does not reproduce a client architecture.
A decision is fed by things that move at different speeds. Stable customer facts live in the profile. Data that changes on its own, such as stock or price, is looked up against a dataset at decision time. Page or session values arrive in the request itself.
Separating them keeps the profile bounded and lets the same decision be reused across channels. Check what each route stores first: on the edge, context sent in the request stays in the profile.
Production signals
- Profile contains page or session data.
- The same eligibility is copied across journeys.
- Changing a ranking requires editing every channel.
Recommended architecture
Classify each input by how long it lasts and who consumes it, before modeling it.
Centralize the decision, not every datum or the entire journey.
Check that dataset lookup is available before designing around it.
When not to apply it
- Do not migrate a working journey without value at request time or across channels.
- Do not assume the context sent in the request is ephemeral, because on the edge it stays in the profile.