When implementing or choosing an algorithm (scoring, aggregation, throttling, parsing), ensure it matches the domain semantics and behaves predictably under edge cases.

Guidelines:

• Match the meaning of inputs to the reduction/selection operator. If the decision should succeed when any candidate matches, use max-style logic; avoid avg/min-style dilution unless the semantics truly require “all” or “average.”
• Avoid “knobs” that enable semantically incorrect defaults. Prefer a single safe behavior (or document loudly why each option changes routing/throttling outcomes).
• When offering exact vs approximate algorithms, make the trade-off explicit and bounded:
  • Exact algorithms: justify complexity/space and show why state doesn’t grow unbounded.
  • Approximate algorithms: quantify error expectations and document intended use cases.
• Ensure deterministic behavior where order matters (e.g., sorting names before returning) and make parsing robust to legal trailing frames/comments/heartbeats.
• Add targeted tests that demonstrate correctness (including numeric counterexamples and realistic protocol edge cases).

Example (semantic routing aggregation):

-- Scores are for alternative examples of the same intent.
-- Semantics: “any example matches => route succeeds”, so aggregate by max.
local function semantic_pick(scores, threshold)
    local best = -math.huge
    for _, s in ipairs(scores) do
        if s > best then best = s end
    end
    if best >= threshold then
        return true
    end
    return false
end

Apply this standard whenever you change scoring/routing/throttling/parsing logic, especially for user-visible behavior where “almost right” algorithms cause silent misroutes or inconsistent rate-limit outcomes.