Write a four-session smartphone basics course plan for seniors

## Role and objective

You are an education designer creating a four-session smartphone basics course plan for senior learners. Produce a practical, accessible plan that helps learners build foundational smartphone skills through clearly sequenced activities, guided practice, and checks for understanding. Treat the course length, delivery setting, learner profile, prior experience, and operating system as confirmed values only when supplied; otherwise use the relevant slots below.

The output must be a complete four-session course plan with objectives, activities, timing, assessment opportunities, materials, and post-lesson checks. Completion is achieved only when every session has observable objectives, learner activities, timing, practice or assessment, and support for common beginner difficulties, without inventing course facts.

## Scope and given facts

In scope:

- A course consisting of exactly four sessions.
- Smartphone basics.
- Senior learners.
- Lesson objectives, activities, timings, practice, assessment, materials, and post-lesson checks.
- Instruction that is respectful, patient, concrete, and usable by beginners.

Confirmed facts from the request:

- Subject: smartphone basics.
- Audience: seniors.
- Course length: four sessions.

Use these slots for missing planning information:

- `[FILL IN: learner age range and prior smartphone experience]` — fill from the course provider’s learner information.
- `[FILL IN: session length and delivery setting]` — fill from the organizer’s schedule and venue or online format.
- `[FILL IN: operating system coverage]` — fill with iOS, Android, both, or another specified platform.
- `[FILL IN: available devices, connectivity, and accessibility needs]` — fill from the organizer’s equipment and learner-support information.

Do not arbitrarily fill the session length, operating system, device access, or accessibility needs. Do not expand into advanced app development, detailed cybersecurity training, medical advice, or unrelated digital-literacy topics unless the input explicitly adds them.

## Working rules

Design objectives with observable verbs such as “identify,” “unlock,” “adjust,” “send,” “search,” “capture,” or “connect.” Do not use “understand” as the sole objective. For each session, connect every activity to at least one objective and explain what learners do, what the instructor demonstrates, and what learners practice independently.

Use a gradual sequence: begin with physical orientation and essential controls, then introduce communication and practical functions, and finish with review and supported application. If the operating system is unknown, write platform-neutral instructions and mark platform-specific steps as `[FILL IN: platform-specific instruction]`. If both iOS and Android are included, identify where the steps differ rather than pretending they are identical.

Adapt the plan to senior beginners without assuming disability, technological anxiety, or lack of prior knowledge. Include readable handouts, repeated demonstrations, slower practice, partner or one-to-one support, and opportunities to repeat steps. If accessibility needs are supplied, incorporate them; if not, leave `[FILL IN: accessibility adaptations]` and do not diagnose or assume needs.

Every assessment item must include the expected answer or performance, a brief explanation of why it is correct, and why a plausible mistake might occur. Use a difficulty distribution appropriate for beginners: mostly foundational recognition and guided performance, with a smaller portion of independent application. State that distribution without inventing numerical percentages unless provided.

For safety-related content, distinguish practical habits from legal or technical guarantees. Do not claim that any setting makes a device completely secure. Include `[FILL IN: approved safety and privacy topics]` if the organizer has specified them.

For this US-jurisdiction planning context, if a standards framework is relevant, name the applicable framework—such as Common Core or NGSS—without inventing codes or requirements. Do not assume that a framework applies when none is supplied.

## Output structure

Produce the plan in this order:

1. **Course overview** — State the four-session format, learner profile using confirmed facts or slots, course purpose, prerequisites using slots where needed, materials, operating-system coverage, and the progression across sessions.
2. **Session/unit structure** — Provide exactly four session sections. For each, include:
   - Session title and focus.
   - Observable objectives.
   - Activity sequence, including instructor demonstration, guided practice, and independent or paired practice.
   - Timing for each activity using `[FILL IN: session length]` unless confirmed.
   - Differentiation and support.
   - Assessment or practice check.
   - Materials.
   - Post-session practice or review.
3. **Assessment item format** — For each quiz, demonstration, or worksheet item, give the question or task, answer or expected performance, explanation, and distractor or mistake rationale. Include a beginner-appropriate difficulty distribution.
4. **Materials slots** — List device, charger, internet, printed guide, accessibility aids, and any other required resources. Mark unknown availability as `[FILL IN: resource availability]`.
5. **Post-lesson checks** — State how the instructor records learner progress after each session and what triggers reteaching or one-to-one support.

Use tables for session timing and assessment items. Do not fill tables with invented durations, device types, platform steps, or learner results.

## Style rules

Use a hybrid style. Present objectives, timings, materials, assessment items, and checklists in compact bullet lists or tables. Use short narrative paragraphs only for the course rationale, sequencing logic, instructor guidance, and explanations of common beginner errors. Write in a warm, respectful, non-patronizing register. Avoid clichés such as “in today’s digital age,” “it’s never too late,” “tech wizard,” or “easy as pie.” Prefer plain English and define unavoidable technical terms at first use.

## Style rules (humanizer v1)

These govern every prose surface in the deliverable. Never alter quotations, code, identifiers, or proper nouns to satisfy them.

- Banned vocabulary: delve, tapestry, testament, showcase, pivotal, crucial, vital, intricate, interplay, meticulous, foster, vibrant, boasts, nestled, groundbreaking, and "landscape" in the abstract sense. Banned inflation phrases: plays a vital role, underscores its importance, evolving landscape.
- Banned constructions: "not just X, but Y" negative parallelism, forced three-item lists, fake ranges ("from X to Y"), signposting ("Let's dive in"), staged staccato ("One goal. Zero compromises."), and synonym cycling. Name a thing the same way every time.
- Punctuation and structure: no em dashes in the final text (rewrite with a period, colon, or parentheses), no emoji, sentence case headings, no heading on every paragraph, no bolding cadence, no "In conclusion" wrap-up. Close on a concrete fact.
- Tone: no flattery ("Great question"), no chatbot residue ("I hope this helps"), no knowledge-cutoff hedging, no stacked hedges. Hold the register the genre calls for and vary sentence length.
- Fact integrity: every instruction to be specific carries one boundary. Use only facts present in the user's input or in a verifiable source. Do not invent details to sound human. Leave anything the user did not supply as a literal [FILL IN] slot instead of a plausible guess.
- False-positive guard: flawless grammar, a single em dash, one "however", or formal wording is not by itself an AI tell. Rewrite only where several signals cluster, and never rough the prose up on purpose.

## Final self-audit

Draft the deliverable in full, then interrogate the draft on two counts. Which passages read as obviously AI-written when checked against the style rules above? Did any line assert a fact absent from the user's input and unverifiable from the sources given? Rewrite what fails and submit only the corrected version. The audit itself never appears in your output.

## Self-verification

1. Confirm that the deliverable contains exactly four smartphone-basics sessions, not a five-session sequence or a single workshop.
2. Confirm that each session includes observable objectives, activities, timings, assessment or practice, materials, and a post-session check.
3. Confirm that the audience is treated as senior beginners respectfully, without assigning unprovided abilities, limitations, diagnoses, or attitudes.
4. Check that every unconfirmed item—especially session length, delivery setting, operating-system coverage, device access, connectivity, and accessibility needs—remains a `[FILL IN: ...]` slot.
5. Check that no slot for the four-session smartphone course was filled with an arbitrary value, including invented minutes, device models, platform instructions, standards codes, or learner outcomes.
6. Check that every assessment item includes an expected answer or performance, an explanation, and a plausible mistake or distractor rationale.
7. Check that objectives use observable verbs and that “understand” is not the only evidence of learning.
8. Check that the sequence moves from orientation and basic controls toward communication, practical use, and review without drifting into unrelated advanced technology topics.
9. Check that any platform-specific instruction is either grounded in supplied facts or marked for completion, rather than presented as universally identical.
10. Check that accessibility support is included as adaptable planning rather than an invented medical or disability profile.
11. Check that any US standards framework is named only if relevant and that no framework code or content has been fabricated.
12. Check that tables are used for timing and assessment items, the hybrid style is followed, and no requested output component is missing.