Build the mental model

Pretraining teaches a model to continue text, not to be a helpful colleague. Alignment training changes which plausible continuation it prefers: answer a harmless question directly, ask when intent is ambiguous, and refuse a genuinely dangerous request. The boundary matters: RLHF is one family of post-training methods, not a guarantee that human values have been solved. Instruction tuning uses demonstrations; preference tuning uses comparisons; constitutional methods add written principles; runtime moderation acts after training. Alignment is the broader goal, and disagreement about that goal is part of the technical problem.

Draw the system in prose as four boxes: need → evidence → decision → consequence. The need belongs to a person or workflow, not the model. Evidence is what the system can legitimately inspect. The decision is the transformation alignment and RLHF performs. The consequence is what changes for a user, operator, or downstream system. If you cannot fill every box, the design is still a label rather than a working mental model.

For a general-purpose chat model, ask what happens when the model is absent. That baseline reveals the actual value. Then ask what remains deterministic: identity, permissions, arithmetic, record updates, and irreversible actions should not become fuzzy merely because a model participates. The model can propose or interpret; an application still owns policy and state.

RLHF is one family of post-training methods, not a guarantee that human values have been solved. Instruction tuning uses demonstrations; preference tuning uses comparisons; constitutional methods add written principles; runtime moderation acts after training. Alignment is the broader goal, and disagreement about that goal is part of the technical problem. This distinction is practical. It tells you where to inspect a failure and which component can repair it. Avoid explaining the concept as “the AI understands everything.” Name the artifact moving between stages—a token sequence, retrieved passage, ranked candidate, stored memory, trace, image latent, or agent message.

A good explanation also includes uncertainty. Inputs may be incomplete, learned behavior is probabilistic, and proxies can disagree with real outcomes. That does not make the system unusable; it means the workflow needs a fallback and a way to expose uncertainty rather than hiding it in fluent prose.

Use this compact record:

| Question | Concrete answer to supply | |---|---| | User job | One action the person is trying to complete | | Input boundary | Data allowed into the system | | Model contribution | The uncertain judgment or generation | | Deterministic guard | Rule, permission, schema, or calculation | | Success signal | Observable outcome, split by important group | | Escape hatch | Retry, fallback, escalation, or stop |

For this topic, a plausible first signal is not “the output looks intelligent.” It is a task outcome tied to the concept and checked on representative cases. Save this sketch; later pages add controls and measurements without changing the user job.

Teach the concept using the analogy above, then deliberately state where the analogy breaks. The kitchen, notebook, workbench, team, or librarian metaphor omits numerical limits and operational ownership. A learner has mastery when they can leave the metaphor and describe the actual information flow.