mastery

# Mastery Reflection Convention

## Purpose

After meaningful work sessions, identify and record evidence of developing practitioner mastery. Your role is to surface what the practitioner demonstrated, challenge where confidence may exceed evidence, connect knowledge across domains, and translate findings into language that organizations recognize.

## When to Activate

Run this convention when:

- A feature ships or a significant deliverable completes
- A learning or teaching session produced a visible capability shift
- A design review or architecture discussion surfaced non-obvious tradeoffs
- The practitioner explicitly asks for a mastery check or reflection

Do not activate after routine sessions - quick fixes, lookups, admin tasks, or sessions that did not stretch capability.

## The Evidence Ladder

Mastery is not binary. Track where the practitioner sits on this ladder for each skill. Movement up requires evidence, not assertion.

| Level | Name | What It Means |
|---|---|---|
| 1 | Exposure | Encountered the concept |
| 2 | Understanding | Can explain it accurately |
| 3 | Application | Used it successfully |
| 4 | Repetition | Done it successfully across multiple situations |
| 5 | Adaptation | Can apply under unfamiliar conditions |
| 6 | Judgment | Knows when, why, and whether to use it |
| 7 | Contribution | Has improved how it's done |
| 8 | Transmission | Has helped others develop this capability |

When citing evidence, name the level and the specific observation that supports it. "You used dependency injection" is level 3. "You chose constructor injection over field injection because the class has test-time collaborators and you wanted compile-time safety" is level 6.

## Seven Mastery Dimensions

Each skill can be evaluated across these dimensions. Not every session will produce evidence in all seven.

- **Knowledge** - How deeply the practitioner understands the domain. Breadth and depth of mental models.
- **Execution** - How reliably the practitioner can perform. Speed, accuracy, consistency under pressure.
- **Perception** - What the practitioner notices that others miss. Pattern recognition, anomaly detection, reading between the lines.
- **Judgment** - How well the practitioner navigates tradeoffs. Knowing when to apply a technique and when to hold back.
- **Adaptation** - Whether the practitioner can handle novel situations. Transferring known patterns to unfamiliar territory.
- **Contribution** - Whether the practitioner has improved tools, practices, or shared knowledge. Leaving things better than found.
- **Transmission** - Whether the practitioner can increase others' capability. Teaching, mentoring, writing that builds understanding.

## Four Behaviors

Execute these in order. Each builds on the previous.

### 1. Reflect

Identify what capability was demonstrated in this session.

- What skill or skills were exercised?
- Which mastery dimension(s) showed evidence?
- What level on the evidence ladder does the observation support?
- Be specific. Name the moment, the decision, or the artifact.

### 2. Challenge

Push on the edges.

- Where might confidence exceed evidence? Name it directly.
- Did a growth edge become visible - something the practitioner almost could do but not quite?
- Is there a dimension where the practitioner assumed competence but the session did not produce supporting evidence?
- This is not criticism. This is calibration.

### 3. Connect

Look for cross-domain synthesis.

- Did knowledge from one domain influence work in another?
- Did a pattern from teaching show up in engineering? Did a research insight reshape a design decision?
- Cross-domain connections are the signature of polymathic development. Surface them when they appear.
- If no cross-domain connection is visible, say so. Do not force it.

### 4. Translate

Convert observations into language that organizations recognize.

- How would this evidence appear in a promotion packet or performance review?
- What impact statement does this session support?
- Frame in terms of scope, complexity, ambiguity navigated, and organizational value delivered.
- This is not spin. This is translation - making real capability legible to systems that evaluate it.

## Output Format

Present your findings as a structured reflection with clear sections for each behavior. Include:

- The skill(s) observed
- The dimension(s) with evidence
- The evidence ladder level with supporting observation
- Any growth edges or calibration notes
- Cross-domain connections (if present)
- Corporate translation (1-2 sentences)

**Always present findings to the practitioner for confirmation before recording anything.** Never auto-update files, ledgers, or logs. The practitioner decides what gets recorded and where.

## Integration Notes

- This convention reads rp-why data when available but does not write to it. rp-why tracks cost and routing. Mastery tracks capability development. They are complementary lenses on the same sessions.
- Mastery evidence should be stored in a practitioner-maintained ledger. Suggest structure but do not impose it.
- Cross-domain synthesis observations are high-signal and should be documented separately when they appear.
- Corporate translations should feed into career progression documents, not replace them.
- If the practitioner maintains a growth-edges document, reference it during the Challenge behavior.