Hard vs Soft Constraints in AI Evaluation: What Is the Difference?

A hard constraint is a boundary. The workflow must satisfy it. If it does not, the result is unacceptable, regardless of how polished or efficient the answer looks.

A soft constraint is a preference or quality target. The workflow should satisfy it, but reasonable trade-offs are possible. A response can be slightly longer than ideal and still be useful. A schedule can be feasible without being perfectly optimal.

The distinction is not about whether a rule matters. Soft constraints can matter enormously. It is about whether violating the rule makes the outcome invalid or merely less desirable.

A hard constraint usually describes an unacceptable state that can be tested with a clear assertion. The total must remain under budget. Only an approved role may call a destructive tool. A patient identifier must not be sent to an external service. The output must contain a valid case ID.

Hard rules often protect safety, legality, privacy, permissions, or basic feasibility. A violation should produce a decisive result: block the action, require approval, quarantine the output, or fail the release.

The evaluator should point to evidence. If a payment exceeded the limit, show the amount and the limit. If a tool was called without approval, show the caller, tool, and event order. “Unsafe” is a label; evidence is what makes the label useful.

A soft constraint describes a quality, preference, or optimisation target. The response should be concise. The schedule should balance workloads. The plan should minimise cost. The explanation should be understandable to a non-specialist.

Soft constraints admit degrees. A response can be clear but a little verbose. A route can be safe but not the cheapest. A schedule can meet every mandatory requirement while distributing shifts unevenly.

That makes soft constraints valuable for improvement. They show teams how to make a valid system better without pretending that every difference is a security incident.

Imagine a run with ten soft objectives passed and one hard privacy rule failed. A blended score might report 90%. An operator scanning a dashboard could interpret that as a strong result and miss the disclosure.

The opposite problem is also common. If every preference is a hard gate, small style differences block useful workflows. Teams then learn to ignore the evaluator because it fails too often for reasons that do not match business risk.

Keep the layers separate. Report hard gates as pass/fail or pass/unknown/fail. Report soft objectives as scores with confidence and explanations.

When you are unsure how to classify a rule, ask four questions.

First, can the rule be expressed precisely? Second, what is the harm if it is violated? Third, is there a legitimate trade-off? Fourth, can the necessary evidence be observed?

A precise, high-harm, non-negotiable rule usually belongs in the hard layer. A rule with legitimate trade-offs usually belongs in the soft layer. If evidence cannot be observed, the answer may be to improve tracing before deciding how to score it.

Classification can change with context. “Use the cheapest vendor” is soft in a normal purchase. “Use only an approved vendor” is hard in a regulated workflow.

Many real requirements contain both layers. Consider: “Choose the cheapest approved vendor that can deliver by Friday.”

The approved-vendor condition is hard. The delivery deadline is hard if Friday is a contractual commitment. Cost is soft among the remaining feasible options. The evaluator should first reject vendors that fail the hard conditions, then compare the survivors by cost.

This ordering matters. An agent should not win the optimisation score by choosing an unsafe or impossible option.

LLM judges are useful for meaning, but they are not ideal sole authorities for arithmetic, permissions, schemas, or exact event order. They can be inconsistent, influenced by wording, and persuaded by a confident explanation.

Use ordinary code where the rule is formal. Check a budget with arithmetic. Check a role against a permission table. Check a tool call against an approval record. Check a response against a schema.

Use an LLM judge for questions such as whether the explanation addresses the user’s concern or whether the tone is appropriate. For high-impact decisions, add human review when the judge’s confidence is low or its result disagrees with deterministic evidence.

A useful report might say: hard gates 12/12 passed; quality objectives 84/100; judge confidence medium; review required: no.

This gives the operator two different answers. Is the workflow safe and valid to continue? How well did it perform among the valid options?

Avoid hiding both answers behind one percentage. If you must provide an aggregate score for a leaderboard, keep the hard-gate status visible and make it impossible for a soft score to compensate for a failed hard rule.

Represent each result with a type, not just a number. A hard result might contain a status, evidence, severity, and blocking decision. A soft result might contain a score, confidence, rubric version, and explanation.

{ "kind": "hard", "status": "passed", "constraint": "budget.limit", "evidence": ["amount=420", "limit=500"] }

{ "kind": "soft", "score": 82, "confidence": "medium", "dimension": "clarity" }

This structure makes downstream decisions easier. Release gates can read hard results. Product teams can trend soft dimensions. Auditors can inspect the evidence behind both.

Make the hard layer small, explicit, deterministic where possible, and difficult to bypass. Make the soft layer rich enough to guide improvement without pretending that preferences are laws.

When you get the distinction right, AI evaluation becomes more honest. It can stop behaviour that is unacceptable, explain why it stopped, and still help a team make an already-valid system faster, clearer, and more useful.