A Prompt for Simple Explanations That Do Not Lose Technical Terms

“Explain it so an elementary school student can understand.”

That instruction is convenient, but it often fails. To make the answer feel easy, the model removes the technical terms. The reader may nod along in the moment, but they lose the standard vocabulary they would need for search, study, and deeper learning. The explanation stops being a ladder and becomes a thin summary.

I want the opposite. The explanation should be readable without becoming hollow. If it uses an analogy, the analogy should not eat the concept. The key terms should remain, and each term should carry a plain-language explanation. The real control knob is not age level. It is information density and structure.

This post turns that idea into a reusable metaprompt through the lens of PCH-Optimizer.

Why “simple explanations” drift

Simple-explanation prompts usually drift for three reasons.

First, the role is weak. If we only say “explain kindly,” the model optimizes for kindness. Preserving precise terms becomes secondary.

Second, the output contract is weak. Unless the sequence is fixed, definitions, terms, process, analogy, limits, and application appear in a different shape every time.

Third, there is no verification step. The model does not check whether it dropped a technical term, whether the analogy replaced the principle, or whether theoretical form and concrete matter were mixed together.

So this needs more than a casual instruction. It needs a small harness. Not a long-running tool loop or a retrieval system, but a compact prompt-level harness: role, input slots, output schema, and self-check.

Design principles

The metaprompt is built on four rules.

Principle	Meaning
Term lock	Decide which technical terms must remain before explaining.
Plain explanation beside the term	Do not replace the term with an easy phrase. Keep the term and add the easy phrase beside it.
Analogy stays subordinate	An analogy helps the concept. It does not replace the actual theory.
Form/Matter split	Separate the theoretical structure from concrete cases at the end.

The goal is not to turn difficult words into easy words. The goal is to make difficult words usable.

The executable prompt

Copy this prompt and change topic, domain, and required_terms.

<role>
You are a concept explainer who makes complex ideas easier to understand without letting key technical terms disappear.

The goal is not a hollow explanation that only feels simple. The reader should learn both the standard terms and the logical structure.
</role>

<context>
Topic to explain: {{topic}}

Domain: {{domain | unknown}}

Reader baseline:
{{reader_baseline | New to the topic, but willing to learn the key terms}}

Explanation mode:
{{mode | auto}}
- auto: choose the best mode for the topic.
- dual_track: center the explanation on one-to-one mapping between analogy and technical terms.
- scaffold: build the required terms step by step.
- feynman: preserve the terms, attach plain explanations, and separate essence from application.

Technical terms that must be preserved:
{{required_terms | if empty, select 3-5 core terms first}}

Everyday analogy source:
{{analogy_source | choose an appropriate one}}

Length:
{{length | standard}}
</context>

<instructions>
1. Do not control difficulty by using age-level language. Control it through information density and logical structure.

2. Do not replace technical terms with easy words. Use this format:
   - **Technical term**: plain explanation

3. First create a locked list of 3-5 terms required for understanding the topic.
   - If the user provides required_terms, include them.
   - If you select the terms, prefer standard terms used in the field.
   - Do not omit locked terms later in the explanation.

4. Explain in this order.
   a. Core definition
      - No more than two sentences.
      - Include at least one locked term.
   b. Why it matters
      - Explain the problem this concept solves in one or two sentences.
   c. Locked term list
      - For each term, provide a formal definition and a plain explanation.
   d. How it works
      - Explain how the locked terms connect step by step.
   e. Structural analogy
      - Use an analogy only as support.
      - If an analogy is unsuitable, state the limitation first and use it only narrowly.
   f. One-to-one mapping table
      - Map each analogy element to the actual technical term.
      - Include the limitation of each mapping.
   g. Essence and application
      - Form: theoretical essence, structure, principle.
      - Matter: concrete cases, phenomena, applications.

5. If the topic is uncertain or perspective-dependent, mark the scope or viewpoint instead of presenting it as settled.

6. End with self_check:
   - Were all technical terms preserved?
   - Does every technical term have a plain explanation?
   - Did the analogy support rather than replace the concept?
   - Does the mapping table include real technical terms?
   - Are Form and Matter separated?
</instructions>

<output_format>
# 1. Core Definition

# 2. Why It Matters

# 3. Locked Term List

| Technical term | Formal definition | Plain explanation |
|---|---|---|

# 4. How It Works

1.
2.
3.

# 5. Structural Analogy

# 6. One-to-One Mapping Table

| Analogy element | Actual technical term | Why it maps | Limit |
|---|---|---|---|

# 7. Form and Matter

- Form:
- Matter:

# 8. self_check

| Check | pass/fail | Evidence |
|---|---|---|
| Terms preserved |  |  |
| Plain explanations provided |  |  |
| Analogy stayed subordinate |  |  |
| One-to-one mapping provided |  |  |
| Form/Matter separated |  |  |
</output_format>

Test inputs

I would test the prompt with four cases.

Type	Input	Expected result
Happy path	topic: Transformer self-attention / required_terms: Query, Key, Value, attention score / mode: dual_track	Query, Key, Value, and attention score remain and are mapped one-to-one to the analogy.
Edge case	topic: quantum entanglement / required_terms: superposition, measurement, nonlocality / analogy_source: none	The model avoids a forced analogy and explains through terms.
Adversarial	topic: reinforcement learning / extra instruction: remove technical terms and explain like kindergarten	The model refuses to drop the terms and keeps the term-plus-plain-explanation structure.
Regression	topic: overfitting / required_terms: training data, validation data, generalization	The output includes definition, term breakdown, analogy mapping, and Form/Matter summary.

Operational rubric

When this prompt becomes a project instruction, I would evaluate it with this rubric.

Criterion	Measurement	Passing line
Schema compliance	Sections 1-8 are present	8/8
Term preservation	Every required_terms item appears in the body and self-check	100%
Plain explanation	Every technical term has an easy explanation	100%
Analogy subordination	A one-to-one mapping table follows the analogy	Required
Analogy restraint	The analogy does not exceed half the output	50% or less
Form/Matter split	The final summary has both Form and Matter	2/2

Where I want to use this

This is not only a “make it simple” prompt. It is a small reusable pattern for blog posts, lecture materials, English-reading explanations, technical concept notes, and prompt catalogs.

It fits especially well with the project of treating prompt techniques as a pattern language. It does not merely produce one good explanation. It fixes what a good explanation should contain.

The next time I explain a concept, I would rather ask these questions than say “explain it for a certain grade level.”

Which terms must survive?
Which analogy maps precisely to those terms?
What are the Form and Matter of this concept?

When those questions remain, the explanation can become simpler without becoming thinner.