Certification alignment
Outcome
At the end of this workstream, a finished chapter’s own content has been rated against a certification’s published skill list, rolled up across every certification assessed, and turned into a weekly study schedule. Certification alignment produces an alignment matrix: chapters as rows, exam skills as columns, each cell rated high, medium, low or none. The schedule that follows tells a learner where to spend study time; it does not change anything inside the framework’s own five stages.
Where it fits
This workstream sits beside the five-stage framework, not inside it. It takes in chapters the content-development stages have already finished, and a certifying body’s published certification outline. That outline is the outside list of skills an exam covers, distinct from the program’s own blueprint, which is the program’s own plan. This workstream always reads an outside outline; it never re-reads the program’s internal blueprint. Its own output, ratings and a schedule, is meant for a learner directly; nothing here feeds back into the framework’s stages.
Why this way
Four sub-parts make up this workstream, each depending on the one before it. Codify turns a certification’s own outline into a numbered, weighted skill list, and rate scores every chapter against every codified skill. Roll up builds one cross-certification summary from every per-certification rating file, and pace turns the rated chapters into a weekly study schedule. Rating needs a skill list to score against, and a roll-up needs finished ratings to summarize, so the order is not arbitrary.
The first three sub-parts are deliberately manual, by explicit rule in the project notes: no automated script produces a skill list, a rating, or a roll-up table. Judging whether a chapter genuinely prepares a learner for a skill is a judgment call, not a pattern a script can match reliably. Pace is the exception: turning a rated chapter list into minutes and a written schedule is closer to arithmetic and formatting than to judgment, so real tooling exists for it, alongside its own prompts. That tooling turns out to be a genuine mix of working, broken and credential-bound pieces, stated plainly below rather than treated as if it all still works.
Steps
| Sub-part | What happens | Who | Basis |
|---|---|---|---|
| Codify | Turn a certification’s own outline into a numbered, weighted skill list | Agent | documented |
| Rate | Score every chapter against every codified skill, high, medium, low or none | Agent | documented; explicitly manual by rule |
| Roll up | Build one cross-certification summary table from every per-certification rating file | Agent | documented |
| Pace | Turn the rated chapters into a weekly reading and active-learning schedule | Agent, then a script for the arithmetic check | documented for the method; suggested for the schedule check itself |
The rate sub-part’s own rule is stated directly in the project notes: an agent manually analyzes each chapter, and does not use automated scripts for this work. The same rule holds for codify and roll up. Pace mixes prompt-driven drafting with a real script layer, described in full below.
Codify, rate and roll up: deliberately manual
A certification’s own outline may already number its skills; when it does, codify reuses that numbering as each skill’s own id. When it does not, codify invents a consistent id scheme instead. Either way, the result is a codified skill list: one row per skill, each with an id, its own text, and its domain’s published weight where the certifying body gives one.
Rate scores every chapter against every codified skill on the four-level scale above: high, medium, low or none. High means the chapter directly prepares a learner for that skill. Medium means the chapter is supplementary, useful combined with others. Low means almost irrelevant, and none means irrelevant. One rating file results per certification assessed. Rating stays manual because it asks a reader, a person or an agent, to judge fit, not to match a pattern.
Roll up reads every per-certification rating file and writes a single cross-certification table. The table has the same chapters as rows, one column per certification, and a simple marker in each cell showing whether that chapter carries any high-relevance rating for that certification. It is written as ordinary prose-and-table output, not generated by a script.
Pacing: technique, tooling and its own honest limits
Pace starts by turning each chapter’s own length into a rough estimate of study minutes, adjusted by the chapter’s importance tier from the roll-up. A higher-tier chapter gets more weekly time than a lower-tier one, never less. The resulting schedule reads one section per chapter: a short description, a reading and active-learning time split with a stated total, a key-concepts list, and a set of key questions.
The reading technique behind that time split is documented and safe to name directly, since none of it is specific to any one program. It combines five elements: a survey-question-read-recite-review method (survey the chapter, turn its headings into questions, read to answer them, recite from memory, then review later); Cornell-style note-taking; expanding-interval spaced repetition, reviewing material at gradually longer gaps; an explain-it-to-a-novice elaboration technique; and short, timed work intervals with breaks.
The tooling behind pace is a genuine mix. One script in the pacing family, meant to parse a chapter-and-questions document for downstream use, was run directly against that document during this guide’s own research and returned zero results. Its heading-matching pattern expects a chapter id right after the heading marker, in a shape the document used at some earlier point. The document’s own headings have since changed shape, so the pattern no longer matches anything. Nothing crashes; the script just reports zero chapters found, a quiet failure rather than a loud one. As a generic illustration of the same failure shape, not the real headings: a pattern written for ## Chapter 3: Recovery and team rules finds nothing against ## Part II, Chapter 3: Recovery and team rules, once a part label is added ahead of the chapter number. A script’s assumption about a file’s own heading format can go stale exactly like this, unnoticed until someone compares its output against what the file actually contains.
A second script in the family carries its own caveat. It turns a chapter’s own questions into an item on a forms-based quiz-delivery platform, depends on locally cached sign-in material this guide does not reproduce, and its own fallback path for finding chapter data points at a batch-file convention the project notes say no longer exists.
A separate, heavily researched design guide for pacing describes a considerably more automated system than any of this: a phased timeline with continuous performance monitoring and automatic pace adjustment, written only as pseudocode. No such adaptive system exists among the tooling described above; what pace actually produces is a static document, written once, with a fixed per-chapter time split that nobody’s progress ever revisits. A design document can describe more automation than a project has actually built. Reading a design guide alone, without also checking what a workstream actually outputs, gives a materially inflated picture of how automated pacing really is.
Worked illustration
The running example’s three chapters and its fictional certification, “Team Git Practitioner (fictional)”, already plant one gap of each kind: chapter 3 matches no skill, and skill CB-3.1 is covered by no chapter.
Codified skill list:
| Domain (weight) | Skill id | Skill |
|---|---|---|
| Daily workflow (40) | CB-1.1 | Stage and commit changes with clear messages |
| Daily workflow (40) | CB-1.2 | Inspect status, history and differences |
| Daily workflow (40) | CB-1.3 | Create, switch and delete branches |
| Team synchronization (35) | CB-2.1 | Merge branches and resolve conflicts |
| Team synchronization (35) | CB-2.2 | Exchange commits with a remote using fetch, pull and push |
| Team synchronization (35) | CB-2.3 | Read ahead and behind status against a remote counterpart |
| Release and setup (25) | CB-3.1 | Mark a release with an annotated tag |
| Release and setup (25) | CB-3.2 | Clone a repository and inspect its remotes |
Rating (H = high, N = none; this sample carries no medium or low rating):
| Chapter | CB-1.1 | CB-1.2 | CB-1.3 | CB-2.1 | CB-2.2 | CB-2.3 | CB-3.1 | CB-3.2 |
|---|---|---|---|---|---|---|---|---|
| 1 Snapshots, history and branches | H | H | H | N | N | N | N | N |
| 2 Combining and sharing work | N | N | N | H | H | H | N | H |
| 3 Recovery and team rules | N | N | N | N | N | N | N | N |
Roll up (does this chapter carry any high rating for this certification?):
| Chapter | Any high rating |
|---|---|
| 1 | Yes |
| 2 | Yes |
| 3 | - |
Pace turns this into an importance tier per chapter. Chapter 1 fully covers the heaviest domain (weight 40) and is rated high. Chapter 2 fully covers a second domain (weight 35) plus one skill from a third, and is rated medium. Chapter 3 matches nothing and is rated low. That is why the schedule below gives chapter 1 the most weekly time, chapter 2 less, and chapter 3 the least.
Scripts
X-CA-01 Schedule check checks a schedule file’s own arithmetic and tier ordering: that every chapter’s reading_minutes plus active_minutes equals its own total_minutes, and that no chapter at a lower importance tier is given a strictly higher total than a chapter at a higher tier. The tier-ordering check is a warning, never an error, because a small, invented schedule will not always order cleanly on its own. Run it from the repository root:
python3 -B scripts/ca/schedule_check.py \
scripts/sample_data/git_basics_batch8/schedule/schedule.json
On the sample schedule above, which has no problems, it prints one summary line:
chapters=3 errors=0 warnings=0
Break it on purpose: a second, checked-in copy of the same schedule raises chapter 3’s own total_minutes from 60 to 130 without changing its reading_minutes or active_minutes:
python3 -B scripts/ca/schedule_check.py \
scripts/sample_data/git_basics_batch8/schedule/schedule_broken.json
error sum-mismatch: chapter 3 reading_minutes (45) + active_minutes (15) = 60, not total_minutes (130)
warning tier-order: chapter 3 (low, total 130) exceeds chapter 1 (high, total 120)
warning tier-order: chapter 3 (low, total 130) exceeds chapter 2 (medium, total 80)
chapters=3 errors=1 warnings=2
One field edit trips both checks at once: the stated total no longer matches its own parts, and the lowest-tier chapter now claims more weekly time than either higher-tier chapter. This script checks arithmetic and tier ordering only, on an invented schedule schema; it is a different, safe check from the broken chapter/question extractor described above, motivated by the same broader lesson that real pacing tooling can drift out of sync with its own inputs, not a stand-in for that script’s own particular failure. The exit code is 1 whenever a finding is printed, as it is here, and 0 when the file is clean, as in the first run above. See Reading exit codes on the Stage 1 index for what an exit code means generally.
Prompts
P-CA-01 Propose a study schedule proposes one chapter’s own reading and active-learning time split, from its word count and its importance tier. It is written for this guide and has not been run against any model in this build; treat it as a starting point and adapt it.
Artifacts and formats
This workstream produces four artifacts. A codified skill list is needed only where a certification’s own outline does not already number its skills. A per-certification alignment matrix has chapters as rows and skill ids as columns, rated high, medium, low or none. A cross-certification roll-up has chapters as rows and certifications as columns, marking whether a chapter carries any high rating for that certification. A study schedule has one section per chapter, in the shape X-CA-01 reads.
Definition of done
- Every skill on a certification’s own outline has an id, whether reused from the outline or invented by codify.
- Every chapter has a rating against every codified skill, at high, medium, low or none, made by a person or an agent reading the chapter directly, never by a script.
- The roll-up table covers every certification assessed and every chapter.
- Every chapter’s schedule entry has reading_minutes, active_minutes and total_minutes that sum correctly, and the schedule check reports no errors.
- A person has approved the codified skill list, the ratings, and the schedule before it reaches a learner.
Common failures
- A tool that silently returns zero results once its input document’s own format changes, with nothing louder than a “0 results” summary to notice.
- An aspirational design guide mistaken for what a workstream actually built: reading the design guide alone, without checking the actual schedule and scripts, gives an inflated picture of how automated pacing really is.
- A schedule whose reading and active-learning minutes do not sum to its own stated total, caught only if someone actually runs the check.
Adapting to your platform
llm: drafts a codified skill list, chapter ratings, a roll-up table, and a proposed schedule from P-CA-01.file-read: reads a certification’s own outline and each chapter’s text before rating or scheduling it.shell: runs the schedule check; without it, add each chapter’s reading and active minutes by hand and compare the sum to its own stated total.human-approval: covers approving the skill list, every chapter rating, and the schedule before it reaches a learner.
Where humans decide
- Approving a codified skill list before any chapter is rated against it.
- Every chapter rating: explicitly manual, with no automated shortcut, by rule.
- Approving a study schedule before it reaches a learner.
Next: Delivery.