Learn

Explain a complex document in plain language

Explain difficult material for a named audience without deleting conditions or uncertainty

5 min setupTested with:ChatGPTReviewed: 2026-08-28
1

Add your context

Your text stays in this browser. AILesson Prompts does not send it to a model or server.

2

Your prompt

Unfilled fields remain visible as placeholders, so you can still copy and edit the prompt

Explain the source in plain language for the stated audience and purpose.

Source:
[document]

Audience and prior knowledge:
[audience]

Purpose and boundaries:
[purpose]

Use only information supported by the source. Preserve conditions, exceptions, scope, numbers, uncertainty, and distinctions that affect meaning. Define necessary terms on first use and replace avoidable jargon. Use one clearly labeled illustrative example only if it does not imply facts absent from the source. Return: one-sentence point; plain-language explanation; what changes for the reader; glossary; illustrative example; limits or ambiguities; and a factual-preservation check. Do not turn explanation into professional advice or a stronger claim.
Private by defaultPrompt assembly happens locally in your browser. Avoid placing confidential information into any AI service unless your organization allows it.

From input to outcome

A worked example

See how concrete context turns this recipe into a usable result

Actual input

Complex source
The service-level objective is 99.9% successful requests measured over a rolling 30-day window, excluding scheduled maintenance announced at least 72 hours in advance. Error-budget exhaustion triggers a release freeze, except for security fixes and changes approved by the incident commander. The objective is an internal reliability target, not a customer service-level agreement.
Audience and prior knowledge
New customer-support colleagues who know the product but not reliability engineering.
Purpose and boundaries
Help them explain incidents accurately. Do not imply contractual guarantees or tell customers what compensation they receive.

Example output

One-sentence point: the team aims for 99.9% successful requests across the most recent 30 days, with specific exclusions and internal consequences, but this is not a customer contract.

Plain-language explanation: “rolling 30-day window” means the measurement period moves forward each day. Planned maintenance is left out only when announced at least 72 hours ahead. The small permitted amount of failure is called the error budget. If that allowance is used up, ordinary releases stop; security fixes and incident-commander-approved changes may still proceed.

For support: describe this as an internal target, not guaranteed uptime or a basis for compensation. Glossary: service-level objective—internal reliability target; error budget—failure allowed within that target; release freeze—temporary stop on ordinary changes. Illustrative example: an announced maintenance window 48 hours ahead would not meet the stated 72-hour exclusion. Limits: the source does not define contractual uptime, compensation, or how successful requests are calculated. All numbers, exceptions, and the SLO/SLA distinction are preserved.

Why this works

  1. 1

    It treats exceptions and uncertainty as meaning, not clutter to remove.

  2. 2

    Audience and purpose constraints control depth without authorizing invented advice.

Check the result

  • Are every number, condition, and exception unchanged?

  • Is any illustrative example clearly separated from source facts?

  • Could the audience understand the point without unexplained jargon?

More ways to explore

Where this recipe fits

Text promptsDocument readingChatGPT prompts

Keep the work moving

Organize information 6 min setup

Generate a source-grounded FAQ

Turn source material into useful questions and traceable answers without filling evidence gaps

A prioritized FAQ with source locators, answer status, and unresolved questions
Open recipe