Skip to main content

Beginner Pilot Guide

Start here if you want one practical route from Launchpad into your first programming module. A pilot means studying the material and preserving what actually happens: what you can explain, where you need help, how long work takes and what you remember later. It does not mean finishing quickly or producing a positive review.

This guide organizes existing lessons and assessments. It adds no new compulsory project and does not replace their completion rules. Its scope is Launchpad plus Semester 00 Programming Basics and its delayed checks, not the whole orientation semester.

Your first session​

  1. Copy or download the shared progress record into a private study folder. A plain-text file is sufficient; no account, public repository or paid service is needed. Enter your start date, available study time and previous experience. Leave results blank.
  2. Attempt the readiness diagnostic before opening its answer key. Allow about one focused hour including recording; splitting this over sessions is fine. Save your first work and note help used.
  3. Compare with the answer key. Record computer, arithmetic, algebra and reading results separately. Pick the first missed prerequisite and its repair lesson. If none is missed, start Study Systems and make one feasible calendar.
  4. End by writing one next action, such as “Practise locating the saved file, then try a fresh navigation task.” Do not plan the entire degree in this session.

Being unfamiliar with a diagnostic question routes you to instruction. It is not a reason to abandon the course or to study the answer before attempting the question.

Follow this route​

1. Establish entry skills​

Use Readiness and Repair and its fresh reassessment. Preserve an example and explanation for each demonstrated domain. Computer A: 4/4, arithmetic B: 4/4 and reading D: 3/3 must be demonstrated before Programming Basics. Algebra C: 4/4 may be repaired alongside Semester 00, but is required before Semester 01.

Output: separate domain results, evidence links and a repair plan for anything open. A readiness pass alone does not replace Launchpad's tooling, Git or final assessments.

2. Begin one sustainable study routine​

Start Study Systems and Sustainable Study together. Use one calendar and observe two actual study sessions on separate occasions during the following technical work. Review the plan against your available time and what you learned. Label any interruption rehearsal as simulated.

Output: one calendar, two observations and a justified revision. Reuse these observations for SS1–SS3 and S1–S3, while assessing each dimension against its own criteria. A plan to observe is not an observation. A perfect streak is not required. Do not wait for a long streak before starting technical lessons.

3. Understand the workspace, then use the tools​

Study clusters 1–2 of Digital Systems, Safety and Recovery before installing development tools. Learn files versus application state, paths, destinations and authority. Continue Developer Environment, then Git Fundamentals. Complete the digital recovery cluster and disposable restore lab while practising file operations.

Output: a usable editor/terminal workspace, setup notes, inspectable Git history and a reopened, content-checked restored file with an explanation of its limits. The restore must actually occur. A local collaboration rehearsal is acceptable where the task permits it, but label it as local practice rather than another person's review. Work in disposable practice folders for destructive examples.

4. Explain and check your work​

Complete Reading and Evidence using a short passage and a learning/tool claim. Complete Communication and Feedback using your setup notes or recovery explanation. Preserve the original explanation, the feedback or labeled solo review, and the revision.

Output: a passage explanation, a source audit, a focused help request and a visible revision. Link the existing technical artifact instead of rebuilding it. Private notes and the supported solo route are sufficient; public posting is not a prerequisite.

5. Practise AI use with an independent check​

After reading and arithmetic readiness, take AI for Learning and Everyday Work. Make and save your own initial attempt before revealing the assessment's candidate response. Inspect its claims, calculations and requested actions. Then attempt the fresh transfer independently.

Output: the initial attempt, candidate audit, justified correction, fresh transfer and assistance declaration. The authored offline candidates are a complete route; no live model, subscription or API key is required. Label these as authored examples, not observed model behavior. If you already saw the answer, use the task's fresh-variant rule.

6. Close Launchpad's existing gates​

Assemble the Foundation Project from your existing artifacts. Complete the cumulative review, checkpoint and exam, repairing failed skills on fresh cases. Keep section scores and dimension scores separate.

Before entering Programming Basics, confirm all of the following under Workload and Progression:

  • Computer, arithmetic and technical-reading readiness demonstrated.
  • Study SS1–SS3 and preparation R1–R3, C1–C3, S1–S3, DS1–DS3 and AL1–AL3 each at 2/2. Communication C1–C3 is distinct from readiness domain C (algebra).
  • Environment quiz at least 18/20 and Git quiz at least 21/23, both with all required practical checks; project complete; checkpoint at least 12/15 (80%), independently demonstrated, with no critical missing skill.
  • Exam at least 75% overall, with at least 70% in every section, using weights A 25%, B 35%, C 25%, D 15%.
  • Required practice, disclosures and fresh reassessments complete. Algebra has a plan if deferred.

Output: one evidence index with explicit results. A high average cannot cover a missing restore, Git skill or assessment dimension. Keep reviewer identity/status separate from scores: self-assessment is provisional evidence, not independent endorsement.

7. Start Programming Basics with a small runnable file​

Open Programming Basics. Complete its entry check and Python setup bridge, then follow Values, Names and Execution: save the script in a known folder, predict its output and run the saved file using the documented command for your system. If running fails, record the exact command, folder and error before changing anything.

Continue the module's full learning sequence, required exercises, lab, assessment and design clinic. A successful first script is an encouraging first result, not a module pass.

Output: the working project, predicted tests, debugging evidence, explanations, both immediate transfer tasks and disclosed assistance. Apply the five-dimension rubric. Record immediate results separately from pending delayed transfer evidence.

8. Check what survives the delay​

Use the Programming Basics retention tasks. Set the anchor to the date you first demonstrate all immediate requirements, including the assessment and clinic. Schedule checks about 7 and 28 days after that same date. Record both planned and actual dates; if delayed, report the actual interval rather than backdating the attempt.

Output: independent attempts on the package-capacity and changed-reading-rule tasks, explanations, tests and any fresh repair. The dates are curriculum design choices, not proven optimal intervals. A check that is not yet due is pending, not failed or passed. Immediate success permits provisional continuation into Algorithm Intuition; delayed checks and any failed repairs must close before final programming readiness and the Semester 00 exit gate.

Required, conditional and optional work​

The core module lessons, required practice and assessment gates remain required. Readiness repairs are conditional on missing skills. Additional remediation is necessary when evidence still fails a gate; repeating already-demonstrated work solely to fill time is unnecessary.

Full external books/courses, extra drills, extended habit tracking, live AI services and public contributions are optional unless a specific required task calls for a bounded selection. No book purchase is necessary for this pilot. Follow each assessment's help rules: ordinary documentation and accessibility tools may be allowed, while generated solutions do not demonstrate independent skill. Record help honestly and use a fresh independent attempt when needed.

Budget time without counting it twice​

Launchpad allocates 92–138 focused hours, including the one-hour initial diagnostic. All four readiness repairs, if needed, add 11–18 hours, including reassessment. Programming Basics adds 38–57 hours, with 2–3 more for its delayed checks and one bounded repair. The narrow pilot therefore plans 132–198 focused hours before conditional repairs, extra remediation or optional work. These estimates await real beginner timing; they are not deadlines.

The rest of Semester 00 is outside that sum, including the separate Learning and Calibration module if you take it alongside programming. Waiting seven or 28 days does not add that many days of focused study. Use existing record/review and integration allowances for these notes, and log any additional administration honestly. Charge one technical session once even when several modules use its evidence; charge only the additional analysis to the supporting module.

Turn a difficulty into a useful correction​

When a task is confusing, record the page and instruction, expected behavior, actual behavior, smallest reproduction, relevant environment and help used. Remove secrets and personal information from shared examples. Distinguish a missing prerequisite, ambiguous instruction, tool problem and concept error; keep uncertain diagnoses labeled as hypotheses.

After a correction, save the original attempt, note the changed instruction/version and retest a fresh case. A successful author demonstration verifies the example; it does not show that a beginner learned it. One learner's time is an individual observation, not a population average. Report authored, technically checked, independently reviewed and learner-demonstrated evidence separately.

At each review choose a concrete next action: continue through the next permitted lesson, repair a named skill, or wait for a scheduled retention check while doing permitted work. Use the shared record as the index; the linked task pages remain the source of assessment criteria.