Learning to build intelligent systems, one project at a time
I want to move from using software to understanding and building it. AI engineering offers a reason to study the foundations carefully: useful intelligent applications need reliable software, sound data, meaningful evaluation, and systems that can be explained and maintained.
This is a long-term, project-based learning initiative spanning software engineering, mathematics, data, machine learning, and systems. The goal is demonstrated understanding through implementation, testing, and reproducibility. Publishing the plan is a starting point, not a claim of expertise or a collection of completed certifications.
Start Here
When I sit down to study, I start with NOW.md. It names the current assignment and the next concrete action; I do not need to reread the whole curriculum. GitHub is the learning workspace. This page explains the process and provides an index to its evidence.
Current Focus — October 24, 2026
Source snapshot: NOW.md identifies W001 — Baseline and Setup, Stage S0, as Not Started. The progress ledger records no study hours or completed assessments; the skill ledger contains no demonstrated competencies. The overall initiative remains In Progress / Active because organizing and developing the learning system is ongoing work.
The next assignment is to build a Python script that reads five synthetic program records and computes a count, establish a reproducible environment, create a Git branch and commit, complete the arithmetic/logic baseline diagnostic, and explain every line. The budget is five hours: theory 0.5, mathematics 0.5, exercises 1, project 1, debugging 0.5, review 0.5, assessment 1.
GitHub issue #1 has the script-building checkbox checked, while its evidence section and NOW.md still say not started. That is partial reported activity, not verified completion of W001. Fresh-environment execution, explanation, diagnostics, and linked evidence remain necessary before advancing to W002. This dated snapshot is not a live progress feed; open NOW.md and the issue for subsequent changes.
Software foundations before advanced AI
Python comes first so that parsing, functions, tests, debugging, and reproducible execution become skills I can use independently. Algorithms develop reasoning about correctness and cost; backend work then turns those foundations into usable services and data products. Framework familiarity alone cannot supply that base.
The default sequence is S0 through S9. S5 may move earlier after S2 if needed without adding weekly hours. The first planned employability checkpoint follows S3: a service that can be explained, modified, tested, and reviewed. It is a checkpoint for considering applications, not a promise of employment.
The plan estimates 440 hours through S3 and 1,520 hours through the core S0–S9 sequence at five hours per week. These are planning assumptions, not guaranteed mastery dates or career forecasts. Assessment, missed weeks, and remediation can change the schedule.
- S0Diagnostic and working environment
- S1Independent Python software
- S2Algorithms and discrete reasoning
- S3Backend engineering and data products
- S4Computer systems and concurrency
- S5Mathematics and numerical experiments
- S6Classical machine learning and data quality
- S7Deep learning and a small language model
- S8Evidence-grounded AI applications
- S9Serving and distributed ML systems
Later stages build on earlier evidence. The first twelve weeks cover S0 and part of S1; they do not complete S1.
How the Learning Workflow Works
One assignment, one deliverable, then evidence before advancement. The numbered loop below clarifies the existing repository process; the assigned week and mastery framework remain the authority.
- Open NOW.mdRead the current week, stage, immediate objective, what to build, weekly budget, success criteria, evidence to record, and next prerequisite.
- Open the corresponding weekly assignmentMatch the week in NOW.md to docs/11-first-12-weeks.md or the complete docs/weekly-assignments.md. Read its deliverable, resources, and acceptance criteria.
- Complete five hours of focused workUse that week’s allocation across theory, mathematics, exercises, implementation, debugging, review, and assessment. The distribution varies by week. Build and explain rather than only watching tutorials.
- Produce an actual deliverableDepending on the assignment, produce scripts, tests, data-processing utilities, a small service, an experiment, documentation, or a recorded design decision.
- Record evidenceAfter each session, log actual minutes, category, work performed, artifact or commit, and next action in tracking/time-log.jsonl. Use progress.json for weekly status, skills.json for competency evidence, and assessments.jsonl for assessment results. Attempted, completed, assessed, and demonstrated are different claims; a checkbox alone proves none of them.
- Review and assessApply docs/08-mastery-framework.md and the project acceptance contract. A failed assessment calls for prerequisite review and remediation, which can extend the schedule. S0 records diagnostic decisions rather than a graduation score.
- Update the current stateOnly after acceptance criteria and applicable gates are met, update progress and skills, retain assessment evidence, schedule retrieval in tracking/reviews.json, and advance NOW.md to the next unlocked assignment.
- Repeat and review periodicallyWrite a short retrospective every four weeks. Every twelve active weeks, review the curriculum, actual progress, blockers, learning gaps, and next steps within the existing budget. Resume unfinished work rather than doubling the next week.
The schedule moves when evidence requires it. Time spent is recorded honestly; it is not automatically competency credit.
Organizing the work on GitHub
The management guide proposes Backlog → Ready → In Progress → Review → Done, with Blocked available for unresolved prerequisites. Backlog holds future work; Ready means prerequisites are satisfied; In Progress identifies the current assignment; Review awaits tests, assessment, or evidence review; Done means the acceptance criteria passed; Blocked means a prerequisite or unresolved issue prevents progress.
Open only the next four weekly issues. Each names its stage and module, objective, prerequisites, five-hour allocation, deliverable, acceptance criteria, and evidence. Keep one active module, one main project, and at most one optional small collaboration task. A stage milestone closes only after mandatory project and assessment evidence passes.
At the October 24 inspection, weekly issues W001–W004 (#1–#4) already exist, with S0 and S1 milestone associations visible on those issues. The README and management guide still describe an unpublished scaffold with no remote issues; that wording is stale. A configured Project board and its fields could not be verified, so the board model above remains proposed infrastructure rather than a claim about a live board. This case study does not create or change that infrastructure.
Real problems, progressively deeper implementations
The planned ladder begins with Python parsing and normalization, program-data collection and validation, then backend services and data products. Later work includes mathematical and numerical experiments, classical machine-learning pipelines, deep-learning implementations, evidence-grounded AI applications, and inference and serving systems. These are planned deliverables, not completed projects.
The RNtoNP program database is a possible practical context: collect permitted program data, preserve provenance, normalize missing values, test imports, and design a backend. Early assignments use synthetic records. The database is not being presented as finished, and the same learning goals could use another public-data directory.
Simpyll provides a place to document engineering decisions, experiments, lessons, and completed artifacts as evidence becomes available. Building this website does not establish AI engineering mastery.
Understanding has to survive a new problem
The mastery framework requires a runnable artifact, acceptance evidence, an explanation, and an unfamiliar transfer or debugging task. Its normal threshold is 80/100 overall and at least 60% in every dimension, plus all mandatory gates. S0 uses diagnostic outcomes instead. Correctness, explanation, independent transfer, reproducibility, and honest communication all matter.
Keep failed results and label self-assessment honestly. External review is preferred; AI-only grading is not independent validation. Required independent implementations, transfer tasks, and conceptual defenses cannot be replaced with generated solutions. Record significant AI assistance and verify suggestions.
If assessment fails, isolate the smallest counterexample, revisit the missing prerequisite, and use a targeted resource and simpler implementation. The documented remediation budget is 5–15 hours; retry with a different task and schedule retrieval around 1, 3, and 8 weeks. Two failures call for prerequisite reassessment or mentor feedback.
A plan that can change with evidence
The implemented learning-control tools are Markdown documentation, a canonical JSON curriculum, Python validation and rendering scripts, tracking files, GitHub issue templates, and a curriculum consistency workflow. Structural validation checks the plan; it does not assess the learner. Future libraries and systems named in assignments are learning targets, not an implemented AI stack.
Distributed infrastructure, GPU and performance engineering, research engineering, and AI compiler engineering are optional future branches. They are alternatives to choose after practical evidence of interest and readiness; the compiler branch requires the GPU branch. They are not current accomplishments.
The constraints are five sustainable study hours per week, prerequisite gaps, access to feedback, and eventually compute cost. Self-study can produce useful evidence but cannot substitute for sustained team delivery, production responsibility, or independent review. The twelve-week maintenance review should revise the next steps when actual learning reveals a better path.
Follow the evidence as it develops
The next useful milestone is completing and recording the baseline, not adding another framework to the plan. Follow NOW.md for the active assignment, the tracking files for recorded evidence, and GitHub issues for acceptance discussions. Future Simpyll writing can connect those artifacts to the decisions and mistakes behind them.