Cost-tier right-sizing

rightSize() in src/lib/server/recommend.ts is the product differentiator of the Recommendation & Right-Sizing capability (#4): beyond matching systems to a requirement, it actively steers toward the most cost-appropriate system that still meets the real requirement and surfaces cheaper alternatives that suffice. It encodes the "NW Acoustical 645 → NW Aluminum 640 → SL45" insight as behavior over the ranked candidates from the matching engine.

The key idea

The matcher (#60) only returns systems that already satisfy the applicable rules' conditions. So a candidate on a lower cost tier is, by construction, a sufficient and cheaper option — right-sizing is therefore a pure cost ordering over the candidates, with no re-evaluation of the requirement.

Cost is compared with the relative budget_tier only — Budget < Mid-range < Premium < Ultra Premium (tierOrdinal). No absolute pricing enters the engine; that stays in the configurator.

API

rightSize(recommendation) → RightSizedRecommendation

type RightSizedRecommendation = {
	recommended: Candidate | null; // the lead pick (top-ranked candidate)
	alternatives: Candidate[]; // strictly-cheaper, still-sufficient — cheapest tier first
	overSpecified: {
		// present only when a cheaper tier would suffice
		fromSystemId: string;
		fromTier: string; // the recommended pick's tier
		toSystemId: string;
		toTier: string; // the cheapest sufficient alternative's tier
		note: string; // "X (Premium) recommended — Y (Budget) may suffice for less."
	} | null;
};

• recommended — the top-ranked candidate from the matcher (already the strongest match). null when nothing matched.
• alternatives — candidates with a strictly lower tier than recommended, ordered cheapest tier first (ties keep the matcher's order). These all meet the requirement, so each is a genuine cost saving.
• overSpecified — set when at least one cheaper alternative exists. It names the cheapest sufficient option (the maximum saving) so the guided flow can say "you're looking at X — Y may suffice for less."

Edge cases

• No cheaper option — when the preferred pick is the only candidate (or the only one on the lowest tier present), alternatives is empty and overSpecified is null: the recommendation is already right-sized.
• Unknown lead tier — if recommended.budgetTier is absent/unrecognized, no cheaper/dearer judgement can be made, so alternatives is empty and nothing is flagged.
• Same- or higher-tier candidates are never surfaced as alternatives — an equal-cost or dearer system is not a cost saving.
• Empty recommendation — returns { recommended: null, alternatives: [], overSpecified: null }.

Worked example — the canonical right-size

Matcher candidates for a high-STC requirement (all already meet STC ≥ 50):

system	role	tier
nw-acoustical-645	preferred	Premium
nw-aluminum-640	alternative	Mid-range
sl45	alternative	Budget

rightSize returns:

• recommended — nw-acoustical-645 (the strongest match),
• alternatives — sl45 (Budget) then nw-aluminum-640 (Mid-range) — cheapest first,
• overSpecified — nw-acoustical-645 (Premium) → sl45 (Budget): "nw-acoustical-645 (Premium) recommended — sl45 (Budget) may suffice for less."

Because SL45 was returned by the matcher it provably clears STC ≥ 50, so surfacing it is a real, requirement-safe saving — the essence of right-sizing. This case is asserted in recommend.spec.ts.

Related

• Recommendation matching engine — produces the ranked candidates this layer right-sizes
• Right-sizing rule representation — where budget_tier and the outcomes come from
• Recommendation API contract (#62) — the consumable surface exposing this right-sized result (guided flow + GET /api/recommendation)