Recommendation lifecycle and verification
Read a recommendation's timeline, separate what the customer claimed from what the estate proves, and understand how ZopNight verifies adoption instead of trusting a status field.
5 lessons. 1 quiz.
Read in order, or jump to what you need.
The recommendation timeline
By the end of this lesson, you will be able to read the per-recommendation History drawer, interpret each event type, and explain which engine bookkeeping is deliberately withheld from the customer surface.
Status is a claim, evidence is a fact
By the end of this lesson, you will be able to distinguish the status and resolution_state columns, interpret the six ways they disagree, and explain why both error directions are live in real estates.
Frozen baselines and declared observables
By the end of this lesson, you will be able to explain why a verification baseline is written once and never recomputed, describe what a rule declares as its finding observable, and reject "the rule stopped firing" as evidence.
The seven verification buckets
By the end of this lesson, you will be able to route any recommendation to its verification bucket, explain why the bucket is derived from the lever rather than the category, and treat abstaining as a first-class outcome.
Rule versions, retirement and supersede
By the end of this lesson, you will be able to explain what cuts a new rule version, predict how existing recommendations are routed when one does, and distinguish a catalog change from a customer outcome.
Module quiz.
Take it once the lessons are done.