What, when, why and how
Prediction unit and downstream action
- what
- A prediction unit names exactly what receives a score, at which time and for which horizon. A downstream policy turns that score into an action.
- when
- Use this at the beginning of every product ML design and whenever the product changes what a score controls.
- why
- “Build a fraud model” leaves the target, timing and error costs ambiguous. A model can rank risk well while an unsuitable action policy harms legitimate users.
- how
- Write a tuple: entity, decision time, horizon, available inputs, output, action and fallback. For a transaction, score before authorization; allow, challenge or review under a versioned policy. Do not confuse a score with a calibrated probability.
Product objective, proxy and guardrail
- what
- The product objective is the outcome you value. A proxy is an earlier measurable signal. A guardrail limits an unacceptable consequence.
- when
- Use these when selecting targets, comparing designs and defining release evidence.
- why
- Optimizing a convenient proxy can reduce user value. More flagged transactions may mean more legitimate users blocked, not less fraud.
- how
- Connect avoided loss to an adjudicated outcome window, track friction on legitimate users separately, and declare review capacity. Monitor fast signals now and mature outcomes later; avoid calling delayed evidence real-time.
Non-ML baseline and complexity budget
- what
- A baseline is a complete, useful policy against which a learned system is evaluated. It may use rules, popularity, recency or a simple statistical model.
- when
- Start with a baseline when labels are sparse, a new product lacks history, or the main risk is operational correctness.
- why
- Without a working reference, extra complexity cannot be justified and there is no dependable degraded mode.
- how
- For the exercise, review high-value transactions from newly created accounts. Version the rule and log eligible transactions, actions and outcomes. Compare quality, workload and latency before adding a learned score.
Define one decision end to end
Synthetic scenario: a service evaluates 10,000 transactions each day. It has a maximum review budget of 100 cases/day. The product wants to reduce realized fraud loss while avoiding unnecessary challenges. These are authored assumptions, not live company numbers.
Unit: one authorization attempt. Decision time: immediately before authorization. Target: adjudicated fraud within 30 days. Output: a score and reason/version metadata. Action: allow, challenge or queue for review. An unavailable risk service falls back to the agreed bounded rule; the product owner must approve its harm trade-off.
| Clarifying question | Assumed answer | Design consequence |
|---|---|---|
| Can authorization wait for a human? | No. Review is asynchronous. | Do not block every request on review queue completion. |
| Which outcomes are available? | Adjudications mature after 30 days. | Exclude immature examples from final quality estimates. |
| How many cases can reviewers process? | 100/day. | Evaluate workload at the selected threshold. |
| What if an action changes? | A challenge changes observed outcomes. | Log action/exposure; labels reflect the intervention policy. |
Work the baseline before proposing a model
Assume the rule sends 80 of 10,000 transactions to review. Once outcomes mature, 20 of the 80 are confirmed fraud; 20 additional frauds were outside the review set. Review precision = 20/80 = 25%. Observed recall = 20/40 = 50%, only under the explicit exercise assumption that all 10,000 outcomes were independently ascertained. If only reviewed transactions receive labels, that recall is not identifiable from these records.
A hypothetical learned candidate sends 150 cases/day, with 30 confirmed frauds. Precision is 20%, and workload exceeds capacity by 50. “More frauds caught” is insufficient: the proposed policy is not operationally feasible. Choose a threshold on validation data or change review staffing with explicit cost and ownership; evaluate the resulting policy on held-out mature data.
An all-allow baseline has zero review load but catches no fraud by review. A review-everything policy exceeds capacity by 9,900. Neither extreme establishes a useful operating point. Record value-weighted losses as well as counts before selecting among feasible policies.
Change the assumptions and revise the design
If the review budget falls from 100 to 25, cap admission and discuss a top-risk queue or selective challenges. This is a new policy and needs its own quality estimate; do not reuse the 80-case operating point.
If the target changes from transaction fraud to account takeover over seven days, change the unit, label window and feature history. A transaction-level random split can put one account’s attack into both training and evaluation. Revisit entity/time separation.
Failure: reviewers label only cases proposed by the rule. A learned model trained on these cases inherits selection bias. Keep label provenance, sample permitted audit cases outside the rule and explain what remains unobserved.
Own the decision contract
Log prediction ID, transaction ID, available feature version, model/rule version, action-policy version and decision time. Outcomes reference the prediction or transaction under a declared attribution rule. An owner for review capacity and an owner for decision latency must agree on fallback and overload behavior.
The rule is preferable when a model does not reliably improve outcomes at feasible workload, when the label process is untrustworthy, or when serving cost exceeds the expected benefit. A trained model is justified by evidence, not a fashionable architecture.
Diagrams and relationships
A score informs a versioned decision. Delayed outcomes are separate evidence, not inputs to the original request.
Scroll horizontally on smaller screens, or enlarge the diagram.
Engineer, Senior and Staff follow-ups
These are teaching lenses. Each answer changes the scope of reasoning; they are not official employer leveling criteria.
Engineer: Why is the 25% review precision not the probability that any transaction is fraudulent?
Its denominator is reviewed transactions selected by the rule. It describes that selected population. Overall prevalence in this fully labeled exercise is 40/10,000 = 0.4%; a per-transaction probability requires a suitable model and calibration evidence.
Engineer: What should a failed risk-service request return?
Return an explicit degraded-mode decision under the versioned fallback policy, with a reason and trace ID. Do not silently return a zero risk score; that would look like a successful model prediction and contaminate monitoring.
Senior: How do you decide whether to ship a higher-recall candidate?
Compare at feasible review volume and agreed harm/cost guardrails using held-out mature labels. Validate feature/model compatibility and observe shadow latency before controlled exposure. Keep a compatible rollback bundle; offline recall alone cannot establish product lift.
Senior: Why can challenged transactions change future training data?
The challenge changes user behavior and may prevent the fraud outcome. An absent loss after a challenge is not proof the original transaction was legitimate. Log the action and preserve the label’s meaning under that policy.
Staff: Who resolves conflict between fraud prevention and conversion?
Name product/risk owners, quantify losses and legitimate-user friction under explicit assumptions, and agree on constrained objectives and review capacity. Record which harm is acceptable, who can change policy, and how long-term evidence can reverse the decision.
Staff: How would you migrate two teams to a shared risk platform?
Version prediction and policy contracts separately, retain per-team action ownership, and dual-log comparable decisions before cutover. Agree on label attribution, capacity quotas and rollback. A common score does not imply identical thresholds or outcomes across products.
Practice and self-review
Your practice draft
Design risk review for a product with only 25 review slots/day. State the unit, label window, baseline, measurable goals, overload behavior and evidence needed for a learned replacement.
Saved locally on this device. The worked answer does not score your draft. Existing lesson notes and completion are separate.
Progressive hints
Hint 1
Define the decision time and whether review is synchronous.
Hint 2
Compute workload before discussing model complexity.
Hint 3
Separate missing labels from confirmed legitimate transactions and name the policy owner.
Reveal worked answer guidance
A coherent answer first clarifies authorization latency and outcome availability. It proposes a bounded rule with explicit ties and queue aging, logs all eligible decisions, and treats selected-label recall as unknown. It chooses a validation operating point within 25/day, evaluates mature held-out outcomes and friction, then specifies a staged rollout and fallback. Different policies are valid if their assumptions, harms and evidence are explicit.
Evidence to check in your answer
- Prediction/action/horizon are explicit.
- The baseline fits review capacity.
- At least one proxy failure is demonstrated.
- Selection bias and ownership have a concrete next action.
For each item, record Missing, Prompted, Independent or Adaptive evidence. Adaptive means you can revise the reasoning under a changed constraint. Reading completion and readiness are separate.
Sources and verification scope
Original synthetic examples and reference calculations. Sources support narrowly scoped background; they do not establish production performance or independent chapter review.
Rules of Machine Learning ↗ · Baseline/infrastructure and training-serving consistency principles; dated examples are not current architecture claims.
Primary background links checked during authoring on 2026-10-19. Arithmetic, temporal eligibility, maturity and split reference functions are checked by the bounded local fixture suite. SQL is explanatory, not a migrated production query. No GPU, external dataset, model API or training job is required.