Turn an idea into a clear goal

IDEA 1

Describe the user's actual task

Start with the decision a person needs to make. ‘Help a club choose a meeting room’ is still broad. ‘Return an available room for 20 people within 500 cents’ tells us what the output must satisfy.

A specification is a small agreement about input, result, constraints, and failure behavior. It makes the goal checkable before any implementation exists. The fictional room catalog here uses integer cents so the budget boundary is unambiguous.

Turn the request into checks

1. Person. A club organizer needs one proposed room.
2. Requirements. The room must fit, be available, and stay within budget.
3. No answer. If none pass, return a no-match result.

Classroom planning scenario; no booking happens.

Write an example before code

// 20 people, budget 500 cents
// room: 20 seats, available, cost 500
// expected: eligible

A concrete example resolves whether equality is allowed. It also helps a reviewer catch an implementation that quietly demands extra seats or a lower price.

Think it through: Which requirement is directly testable?

IDEA 2

Separate requirements from preferences

A hard requirement rejects an option. A preference ranks options that remain. If availability is required and price is preferred, an unavailable free room still loses to a valid paid room.

Our rule is: filter available rooms with enough seats and acceptable cost, then choose the cheapest. If costs tie, keep the first eligible room in the supplied order. That tie rule makes results reproducible without claiming there is one universal best room.

Filter, then rank

1. Reject. A free room with too few seats cannot satisfy this task.
2. Keep. Two available rooms fit the group and budget.
3. Rank. Choose 300 because cheapest is the stated preference.

Preferences never repair a failed requirement.

Ranking has a precondition

const eligible = room.available && room.seats >= people && room.costCents <= budget;
if (eligible && (best === null || room.costCents < best.costCents)) best = room;

The first expression is a gate. The second compares only eligible candidates and uses a strict price comparison to preserve the first candidate on a tie.

Think it through: A free room is too small. A 300-cent room fits a 500-cent budget and the group. Which wins?

IDEA 3

Choose a simple workflow when it is enough

When the data is structured and the rules are settled, ordinary code can filter and rank it directly. Adding a model would introduce another component without being necessary for this calculation.

A model could help interpret an ambiguous natural-language request, but its interpretation would still need review or validation. Our workflow stops after scanning the finite list and returns either the cheapest eligible room or no match.

Use the smallest sufficient system

1. Read. Use the fields already supplied by the case.
2. Calculate. Apply the agreed checks and preference once per row.
3. Finish. Return the selected ID and known price, or explicit absence.

This lab is deterministic decision code, not simulated model reasoning.

An honest no-match object

return { status: "no-match", roomId: null, costCents: null };

All expected fields are present. null preserves unknown or absent values instead of silently relaxing the budget or inventing an available room.

Think it through: Why can this room selector work without a model?

Put it into practice

Select the cheapest eligible room, preserving input order on ties.

1. Locate the eligibility placeholder; ranking is already written below it.
2. Insert availability, capacity, and budget checks together.
3. Run the case where the cheapest room is invalid.
4. Compare an exact-budget case with a no-match case.

Your next experiment: Increase budgetCents by one. Predict whether the no-match result changes.

Agree on eligibility, ranking, tie handling, and no-answer behavior before adding intelligence.

Key terms

Specification

A checkable agreement about input, output, requirements, and failure behavior.

Preference

A ranking rule applied after hard requirements have passed.

Sources and scope

Original Stemtiq teaching, reviewed 2026-09-14. The named researchers and organizations do not endorse this course. Classroom cases are authored exercises, not published findings.