LLM Alignment: Strict Instruction Following vs. Intent Inference

1. The bottleneck moves once models become capable

Early conversational models were judged mostly on whether they could say anything sensible at all, so alignment work naturally focused on dimensions that are easy to verify: safety, format compliance, and refusal boundaries. Once reasoning, coding, and tool-calling abilities crossed the usability threshold, the real bottleneck moved. User input is almost never complete.

This leaves two sharply different alignment philosophies:

• Route A — Literal strict following. Training and reward signals favor the exact satisfaction of explicit constraints. The model is expected to infer as little as possible and not to improvise. Whatever the user says is what it does, and the user must draw the boundaries in the prompt.
• Route B — Intent inference. The model keeps its native reasoning and commonsense completion abilities, and may look for a workable solution within the space the business rules allow. An incomplete input is treated as a problem to be completed, not a specification to be executed.

The split is not a moral difference between “obeying” and “not obeying.” It is an engineering decision about who carries the intellectual cost of resolving ambiguity.

2. What Route A buys and what it costs

Literal strict following has real value, and its benefits are concrete:

• Predictable and testable. The same input yields a stable output. Regression tests are easy to write, and production issues are reproducible.
• Compliance-friendly. In scenarios with hard constraints on data boundaries, permissions, or output format, it is better not to infer than to overstep.
• Controllable across turns. When an agent runs long workflows, strict instruction boundaries substantially reduce the chance of drifting off course.

The costs are equally concrete, and often surface only after launch:

1. Brittleness. The model executes an incomplete input as if it were a complete spec. The result is “fully compliant with the instruction, and completely useless.”
2. Responsibility shifted back to the user. The burden of resolving ambiguity lands on the user, which amounts to demanding that they first write a complete system prompt, field list, and exception-handling conventions.
3. Implicit business logic. The prompt becomes the de facto carrier of business rules, with no version control, unit tests, or regression baseline. Every change requires a full manual re-verification.

A typical case:

User input (the normal state of the real world):
"Please change this order for me, the customer is in a hurry, and try not to cost him extra money."

A literal-following model returns a clarification checklist: order number, target date, target specification, budget cap, whether add-on services are kept, whether splitting is allowed… A dozen fields later, the user has already given up. That is not successful alignment; that is handing the intellectual work back to the user.

3. Why “making the user align to the model” is the wrong goal

Abstracted into three arguments, the case is more persuasive than emotional criticism:

Argument 1: Information asymmetry. Users do not know what they do not know. Incomplete specifications are not caused by user laziness; requirements themselves are clarified progressively during the conversation. Demanding complete input is equivalent to demanding that the problem already be solved before you start solving it.

Argument 2: Value density. If a task can only be completed by writing out complete constraints first and then correcting the model step by step, the intellectual value the model contributes is close to zero. Compared with hand-writing the workflow, using an intelligent system then adds nothing but latency and cost.

Argument 3: Maintainability. When the system prompt balloons to several hundred lines, mixing business rules, format requirements, edge cases, and exception clauses, it is software that is not being managed as software.

The more sensible goal, therefore, is not “align the user to the model” but having the model absorb a reasonable share of ambiguity resolution, while exposing the resolution process so it can be audited.

4. What Route B requires: inferences must be visible, controllable, and recoverable

Retaining the model’s native reasoning is not the same as letting it improvise freely. From an engineering standpoint, this decomposes into four achievable constraints.

4.1 Make assumptions explicit

Require the model to emit its assumptions alongside the proposed action, so inference moves from black-box behavior to an auditable field:

{
  "action": "modify_order",
  "constraints": [
    {"key": "total_price", "op": "<=", "value": "original order amount", "source": "user_utterance"}
  ],
  "assumptions": [
    {"id": "a1", "text": "'This order' refers to the most recent incomplete order in the conversation context", "confidence": 0.82, "reversible": true},
    {"id": "a2", "text": "'Don't cost him extra money' is read as a total price no higher than the original order", "confidence": 0.74, "reversible": true}
  ],
  "needs_confirmation": false,
  "confirm_reason": null
}

With assumptions, the product side can do three things it previously could not: measure error rates by assumption type, insert a confirmation automatically before irreversible operations, and crystallize frequently misread assumptions into explicit conventions in the system prompt.

4.2 Let reversibility drive the clarification policy

Not every ambiguity is worth a question. Use “reversible or not, plus blast radius” to decide the policy:

• Read-only, rollback-able, impact limited to a single session: execute directly and declare the assumption.
• Touches money, external notification, or data deletion: stop and ask one minimal question.

This avoids both extremes: asking about everything, which makes the system unusable, and silent execution, which causes irreversible loss.

4.3 Push the rules down into code validators

Do not expect the prompt to carry business rules. The model proposes candidate actions; code decides whether they are legal:

# Rules live in code; the model only submits a candidate action
def validate_modification(before: Order, after: Order, policy: Policy) -> Result:
    if after.total_price > before.total_price and not policy.allow_upgrade:
        return Result(ok=False, reason="price_increase_forbidden")
    if not policy.transition_allowed(before.state, after.state):
        # Combination not covered by the rules: send to the human/spec review queue
        return Result(ok=False, reason="undeclared_transition")
    return Result(ok=True)

Note the undeclared_transition branch: it does not mark a model error, it marks that the rule set itself does not declare this path. This distinction is the core of the next section.

4.4 Evaluation and attribution: rule out specification defects first

Benchmarks for tool calling and workflow tasks, such as booking, rebooking, approvals, and ticket routing, have a high-incidence defect: the business rules described in the task are incomplete, but the grader accepts only a single “expected action sequence.”

A typical case: in an evaluation involving a cabin-class change, the task states the target is a direct change, and the benchmark expects the model to refuse. The model instead finds a compound path: first an upgrade adjustment that the rules allow, then the change itself. This completes the user’s goal while satisfying every explicit constraint in the task statement. The grader scores it as a failure; by the intent of the task, it holds. The root cause of the failure is a hole in the specification, not an alignment failure.

Classify evaluation failures into three categories before discussing improvements:

Attribution	Criterion	Action
Capability gap	Violates an explicit constraint in the task, or the reasoning chain breaks	Training or prompt optimization
Alignment failure	Ignores a clear system-level constraint (safety, format, permissions)	Fix data and reward signals
Specification defect	Model solution satisfies all explicit constraints, but the grader accepts only one path	Fix the benchmark; do not count it against the model

The supporting review process: sample failing cases, have two reviewers attribute them independently, send disputed cases to arbitration, then fix the benchmark or the model, and run a regression. An evaluation system without an “arbitrate the specification” step will book a large number of benchmark defects to the model’s account and, in turn, misdirect training.

5. Writing a system prompt that does not regress

If you want both strict boundaries and retained inference capability, the system prompt should be layered rather than piled up as a single prose block:

[L1 Hard constraints] Non-negotiable: permission boundaries, data export, output format, prohibited actions
[L2 Objective function] Success criteria for the task (the user's goal, not the steps)
[L3 Missing information] Inference under the L2 goal is allowed; every inference is written into assumptions
[L4 Clarification threshold] Ask only when the operation is irreversible or its impact extends beyond the current session, and ask only the single most important question
[L5 Rule reference] Business rules are authoritative at the tool/validator interface and are not restated here, to avoid writing the rules twice

The most easily overlooked item is L5’s “avoid writing the rules twice”: when the same rule exists in both the prompt and the code, the two will inevitably drift apart, and what appears in production is usually the looser, prompt-side version.

6. Assembling this capability on the cloud

The design above can be assembled entirely from general-purpose cloud services, without relying on any proprietary interface:

• Model services: separate call types for “constrained execution” and “complex reasoning,” routed by task;
• Vector retrieval: provide traceable grounding for long-tail business rules, reducing prompt hard-coding;
• Object storage: keep full conversation and tool-call traces for attribution analysis and regression sampling;
• Message queues: carry asynchronous tasks and retries for long-running agents;
• Logging with monitoring and alerting: continuously observe the rate at which assumptions are overturned, the clarification rate, and the distribution of validator rejection reasons;
• Container platforms: turn the evaluation pipeline and the arbitration queue into reproducible scheduled jobs.

On a platform such as Baidu AI Cloud, these components are typically assembled on demand. The key is to put prompts and policies under version control and roll them out gradually: a policy change is a code change, not a casual configuration edit.

7. Three signals of a healthy alignment philosophy

Finally, three actionable criteria for assessing the alignment posture of any model or agent platform:

1. Does it retain native reasoning? A model that performs well only when the input is complete has its intelligence ceiling set by the user’s ability to express the request, not by the model.
2. Does it treat incomplete input as the norm? Look for whether it provides mechanisms such as assumption declaration, clarification thresholds, and confidence, instead of simply asking the user to supply more information.
3. Does it have a specification feedback loop? When an evaluation produces a disputed case, does the system simply record a model failure, or can it identify and fix the benchmark defect?

Strict literal following suits the role of “baseline discipline”; intent inference suits the role of “problem-solving capability.” They are not substitutes but a division of labor. Treat discipline as the whole of intelligence and you get a marionette; use inference as an excuse for exemption and you get an unauditable black box. The mature engineering practice is to enforce constraints rigidly in code, and to let inference happen inside the model and record it explicitly.