Build a shortlist with inspectable evidence

Turn a list into a defensible recommendation

A useful shortlist needs more than three names. For each item, show why it fits, the sample total, and the supporting source. If two choices are close, explain the tradeoff: a better cuisine match versus a lower total.

Start with a deterministic explanation derived from the filtered record. Later, a model can improve wording while remaining bounded by the same evidence. Never let polished prose add an unsupported delivery promise.

Check your understanding

What belongs beside a recommended item?

Change one behavior in the starter

Open the lab bundle and find searchMenu in builder-core.mjs. Read the eligibility checks before the scoring function. Predict what happens when you change a search weight, then run the lab again.

Keep a counterexample: a highly relevant unavailable dish. If that dish appears after your change, you changed more than ranking. Restore the boundary check and rerun the case. A successful code edit should preserve earlier guarantees.

Check your understanding

Carry the shortlist into the next module

Choose an eligible item, then open the Workflow Lab. The project now has two separate stages: obtaining defensible candidates and drafting a cart. This separation makes errors easier to locate.

Your completion artifact is a three-case evidence log: one successful search, one empty result, and one excluded stale record. Include both expected and actual behavior. These become regression cases in Module 5.

Check your understanding

Describe a regression test for your shortlist edit.

Key takeaways

• Show evidence beside the recommendation.
• Make one measurable change at a time.
• Carry stable item identifiers into the cart workflow.