Advanced
score 90–100Handles complex problems, optimises, defines standards and mentors.
Can
- Handle complex problems
- Optimise solutions
- Define standards
- Mentor other developers
- Own the skill area
Level guide
The single definition of every grade, dimension and evidence type the programme uses. Everything else in the app links here rather than repeating it.
How a grade is scored
Each skill has a prepared Q&A (the Q&A tab on the skill). In a review the skill owner asks the questions and marks every answer Correct (full points), Partial (half) or Wrong (none). Harder questions carry more weight:
- Basic — 1 point
- Intermediate — 2 points
- Advanced — 3 points
Score = points earned ÷ points possible over the questions asked (at least 5). The score sets the verified grade.
| Score | Grade |
|---|---|
| 90–100 | AAdvanced |
| 80–89 | BProficient |
| 70–79 | CWorking |
| 60–69 | DFundamental |
| below 60 | EBeginner |
Proficient
score 80–89Can design solutions, troubleshoot, review code and decide independently.
Can
- Design normal implementations
- Troubleshoot problems
- Review other people’s code
- Make technical decisions independently
Working
score 70–79Can independently perform common tasks and explain the implementation.
Can
- Follow documentation and use common tools
- Implement common tasks independently
- Explain their own implementation
- Integrate with another layer
Fundamental
score 60–69Understands basic concepts and can perform simple tasks with guidance.
Can
- Explain what it is and why it is used
- Describe the basic architecture and terminology
- Perform simple tasks with guidance
Beginner
score below 60Knows some basic concepts but cannot yet work in the area without close guidance.
Can
- Recognise the main terms and tools
- Follow a worked example step by step
A dash is not E. A dash means the skill has never been assessed. E means someone was assessed and scored below 60. The app shows them differently on purpose.
Assessment dimensions
A single number hides which part of a skill is missing, so every assessment can carry a score per dimension. A dimension may be left blank — “not assessed” is more honest than a guess, and blanks render as gaps rather than zeros.
- Knowledge
- Can they explain the fundamental concepts?
- Implementation
- Can they implement a solution?
- Code Understanding
- Can they understand AI-generated or existing code?
- Debugging
- Can they identify and solve problems?
- Design
- Can they make reasonable technical decisions?
- Communication
- Can they clearly explain why a solution was chosen?
Independence from AI
Using AI is not a negative factor. What is recorded is how much of the solution the developer demonstrably controls. Each criterion is rated Not assessed · No · Partly · Yes, and the rated ones roll up to a percentage.
- Can explain AI-generated code
- Can modify AI-generated code
- Can identify incorrect AI-generated code
- Can debug without AI
- Can make technical decisions without blindly following AI
AI can help a developer produce the solution, but the developer must demonstrate understanding of the solution.
Evidence types
A level should rest on evidence. Types marked not enough alone show recall or AI output rather than demonstrated skill — a level never rests on those by themselves.
- Knowledge questions
- Code review
- Debugging task
- Practical task
- Architecture explanation
- Real project contribution
- Knowledge-sharing session
- Peer review
- AI assessment
The Q&A sets the grade and is recorded as Knowledge questions evidence. Cite other forms of evidence alongside it to raise the confidence in that grade.
Confidence
How well-evidenced a verified grade is. Confidence is capped by the evidence actually cited: picking High with one item on file records what the evidence supports instead.
- Low
- Thin or single-source evidence — treat this level as provisional.
- Medium
- Reasonable evidence, but some dimensions were not directly observed.
- High
- Several independent forms of evidence across the dimensions.
Checklist statuses
- Not Started
- Learning
- Completed
- Needs Review
- Verified
A member moves their own items through Learning and Completed. Only the skill owner can mark an item Verified — the same separation that keeps people from setting their own level.
Session types
- Concept Sharing
- Primary Skill Owner introduces the topic and builds the mental model.
- Member Sharing
- A developer shares what they independently learned.
- Practical Challenge
- Developer demonstrates an implementation.
- Review / Assessment
- Skill Owner evaluates knowledge and records a verified level.
The learning cycle
Four stages, but only three of them schedule a session — self learning is individual work.
- 1Concept sharingConcept Sharing
The primary skill owner introduces the topic: what it is, why we use it, the architecture and real examples from our own projects. The goal is the correct mental model, not every implementation detail.
- 2Self learningno session
Members research on their own — AI, documentation, tutorials, internal examples, small experiments. There is no session to schedule: the owner hands out a learning assignment, and members work the checklist and keep a learning log.
- 3Member sharingMember SharingPractical Challenge
The developer presents what they understood and what they practised. A practical challenge is the same stage with the emphasis on a live demonstration rather than a talk.
- 4ReviewReview / Assessment
The skill owner checks that they can explain, use, demonstrate and troubleshoot, then records a verified level against the evidence on file.
Back to the team skills matrix or the skill areas.