What a completion record looks like
Every learner gets one when they finish. This is a sample.
Completion record
- Name
- Sample learner
- Course
- Git and GitHub Foundations — a project of yours, on GitHub, with a history you can defend
- Completed
- 8 November 2026
- Project
- View the dashboard →
- Skills demonstrated
- Version control from the command line · Deliberate staging, and commit messages a stranger can navigate by · Keeping credentials and scratch files out of a repository · Branching, merging, and resolving a conflict by hand · Publishing to a remote, and understanding what publishing means · Working through a pull request · Reading a history three ways · Undoing safely, and knowing which undo applies · Tagging a release
What was built
A public GitHub repository holding a small project — a price list, a one-page site, and an ignore file that keeps the workshop's credentials and scratch files out — with a history whose every commit says why it happened, one merge you resolved by hand, one pull request you opened and merged, a readme that tells a stranger how to use the thing, and a release tag. The repository's address is what your completion record points at.
The 6 sessions, and when each was completed on their own
Each session was completed twice: once with step-by-step guidance on one company’s data, then on a second company’s data from a brief, with guidance only when asked. Every check passed on both. Alongrail records the sessions, the checks and the dates; the dashboard itself is the learner’s own, hosted where they chose.
The record is a description of work you did, not a claim about you. Anyone who opens it can see the work for themselves. It stays private until you publish it, and you can unpublish it at any time.
The name, the course, the date, the skills and the link to the dashboard: that is the whole of it. Nothing on it is about you that you didn’t do.