Consent Belongs in the Decision Path, Where Suppress Is One of Several Trust Actions That Can Change a Score

Allow a trust action to suppress a candidate and the scoring call inherits that action's inputs. Consent for the current channel, a fatigue count for that offer, and the journey stage held in cross-session memory all have to resolve before a score comes back ^[1][3][4]. The article puts them there on purpose. Its stated principle is that governance must influence ranking before an experience is delivered ^[7].

The five trust actions are not equal in implementation cost ^[3][16]. Show and suppress are a flag on the candidate. Soften implies a lower-intensity variant of the same offer already exists. Delay implies somewhere to hold the candidate and a trigger to re-evaluate it. Generic fallback implies a default that is acceptable on every channel the platform serves.

The tier router is the part I would copy first. Rules, small models, classical ML and an optional LLM sit behind one policy-selected interface, each testable and operable on its own ^[2][17]. The worked scenario lists provider unavailability alongside consent and fatigue as a reason the relevant upgrade should not ship ^[8]. Under this design an LLM outage becomes a tier downgrade instead of a failed recommendation request.

The explanation payload is only useful if the five fields stay comparable over time ^[5][18]. The selected tier and the trust action are enumerations. The rules fired are identifiers, and identifiers are only useful at audit time if a policy edit does not renumber them.

Consent has to be readable per customer per channel on the request path before score-time governance means what it says. The fatigue counter must reflect this session, not last night's batch. And the YAML must have a review path, because externalizing the policy moves suppression out of code review and into a file with its own queue in front of it ^[6]. Where consent arrives in a nightly CRM export, a suppression decision made inside scoring is asserting a freshness the data does not have. The article's own account of the status quo is that these answers sit scattered across logs, CRM data, dashboards and model prompts while the recommendation returns only an identifier and a score ^[11].

The evidence here is one practitioner's pattern, drawn from work with architecture, MarTech engineering, data and analytics, product, business and governance teams ^[12]. In that account, models ranked relevant offers fine and inference routing lived in scattered application logic ^[12][13]. No latency, cost or uplift figures accompany the pattern ^[15], so the case for moving governance ahead of ranking rests on traceability. As the article puts it: "This is not primarily a model problem. It is an architecture problem." ^[10]