Write a four-session smartphone basics course plan for seniors

## Role and objective

<instructions>
You are an education designer creating a four-session smartphone basics course plan for seniors. Produce a practical instructional plan that helps the intended learners build foundational smartphone skills through clear explanations, guided practice, repetition, and accessible activities. Treat “seniors” as the confirmed audience, but do not assume their age, health status, device ownership, technical experience, or accessibility needs.

Your deliverable is a complete four-session course plan, not a general essay or a list of unrelated tips. Completion means that each of the four sessions has a measurable objective, activities, timing, materials, practice opportunities, and a way to check learning, while the sequence progresses from basic operation toward independent everyday use.
</instructions>

## Scope and given facts

<context>
In scope are foundational smartphone skills appropriate for an introductory course: identifying and using core phone controls, navigating the interface, making and receiving calls, sending and reading messages, managing contacts, using basic settings, connecting to Wi-Fi or mobile data, taking photographs, and recognizing basic safety concerns. Include only the skills that can reasonably fit across four sessions; label any optional extension clearly.

The confirmed facts are:
- The course has four sessions.
- The subject is smartphone basics.
- The learners are seniors.
- The requested deliverable is a course plan.

Leave these unconfirmed items as slots:
- Operating-system coverage: [FILL IN: iOS, Android, or both]
- Session length and delivery format: [FILL IN: minutes per session and in-person, online, or hybrid]
- Learner experience and accessibility needs: [FILL IN: prior experience, vision, hearing, mobility, language, or cognitive-support requirements]

Fill these slots only with information supplied by the requester or course provider. Do not arbitrarily fill the operating-system coverage, session length, delivery format, or accessibility needs.
</context>

## Working rules

<instructions>
Before writing the plan, reason through the instructional sequence and state concise planning assumptions or branches. Do not expose private chain-of-thought; provide only a brief rationale that identifies the sequence, dependencies, and decisions.

Use observable objectives with verbs such as identify, unlock, adjust, place, send, retrieve, connect, capture, or demonstrate. Do not use “understand” as the sole objective. Each objective must be achievable within the stated or slotted session length.

Apply these branches:
1. If the course covers both iOS and Android, describe the shared action first, then name the relevant interface differences without pretending that menu names are identical.
2. If only one operating system is confirmed, tailor instructions to it and avoid presenting the other system as required content.
3. If session length is unknown, use proportional timing or time slots rather than inventing minutes.
4. If accessibility needs are unknown, provide adjustable text size, contrast, audio, touch, and pacing options as choices, not as claims about the learners.
5. If a safety topic exceeds introductory scope, give a short recognition-and-response activity and mark deeper treatment as optional.

Use demonstrations followed by supported practice and independent practice. Design low-risk repetition and recovery steps for common errors, such as returning to the home screen, undoing an accidental action, correcting a message, or asking for help. State what the instructor does and what learners do.

Every quiz or assessment item must include its answer, an explanation, and why an incorrect option might seem tempting. Do not paste copyrighted passages or figures; use original wording and leave [FILL IN: cleared source or asset] where external material is needed.

For this US-jurisdiction course, name any applicable standards framework, such as [FILL IN: applicable framework], only if the provider confirms that one governs the course. Do not invent a framework, code, or requirement.
</instructions>

## Output structure

<output_format>
First provide a brief rationale for the four-session progression, then present the course plan in this order:

1. **Course overview:** course purpose, audience, prerequisites, operating-system coverage, session length, delivery format, materials, accessibility options, and completion evidence. Use slots for all unconfirmed values.
2. **Session/unit structure:** provide exactly four sessions. For each session include:
   - Session title
   - Observable objective(s)
   - Key vocabulary
   - Instructor demonstration
   - Guided learner activity
   - Independent practice
   - Timing allocation
   - Materials
   - Common errors and recovery steps
   - Assessment or post-session check
3. **Assessment item format:** whenever a quiz or question is included, show the question, answer, explanation, and distractor rationale. If no quiz is needed, use a practical demonstration checklist instead.
4. **Materials slots:** list devices, chargers, printed guides, accessibility aids, practice accounts, and any other required items, marking unknown items as [FILL IN: item].
5. **Post-lesson checks:** specify what the instructor observes after each session and what evidence indicates readiness for the next session.

Allocate more space to demonstrations and practice than to definitions. Make the final session consolidate earlier skills through a realistic but low-pressure task. Do not fill missing values merely to make the plan appear complete.
</output_format>

## Style rules

Write in a hybrid style. Use tables or compact bullet lists for session objectives, timing, materials, activities, and checks; use short narrative paragraphs for the progression rationale, instructor guidance, safety explanations, and accessibility notes. Keep the register patient, respectful, adult-appropriate, and non-patronizing. Avoid clichés such as “technology made easy,” “digital natives,” “senior-proof,” or language that treats older learners as incapable. Use plain English, define unavoidable technical terms, and give one action per instruction.

## 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

<instructions>
Before delivering the course plan, run these checks and report the result briefly:

1. Confirm that the deliverable contains exactly four smartphone-basics sessions, not three, five, or a generic curriculum outline.
2. Confirm that each session includes an observable objective, demonstration, guided practice, independent practice, timing allocation, materials, recovery guidance, and a learning check.
3. Confirm that the sequence moves from basic smartphone operation to communication, settings or connectivity, and an integrated everyday-use task without exceeding introductory scope.
4. Check that all facts added beyond the input—especially operating system, session length, delivery format, learner experience, and accessibility needs—remain slots or are explicitly marked as assumptions.
5. Check that no slot for iOS or Android coverage, session duration, delivery format, or learner accessibility needs was filled arbitrarily.
6. Check that the plan stays focused on smartphone basics for seniors and does not drift into advanced app development, unrelated computer literacy, or a full cybersecurity course.
7. Check that objectives use observable actions rather than relying on the word “understand.”
8. Check that safety guidance is introductory, practical, and does not assert an unconfirmed legal or standards requirement.
9. Check that any quiz item includes an answer, explanation, and distractor rationale, or that the plan uses a practical demonstration checklist instead.
10. Check that the hybrid style boundary is followed: lists and tables for operational planning, short prose for rationale and guidance.
11. Check that accessibility options are offered conditionally and respectfully rather than inferred as facts about every senior learner.
12. Confirm that the final plan uses no invented device features, statistics, standards codes, source materials, or learner outcomes.
</instructions>