# Practitioner instructor practice kit

AI-native training by LockedIn Labs · Edition 1, 28 October 2026

Use this kit to prepare and observe a topic-specific teach-back. It is a working teaching standard and blank observation record, not trainer accreditation, an approved faculty directory or permission to deliver a LockedIn Labs course. Discuss a real teaching engagement through [Teach with us](https://training.lockedinlabs.ai/experts#for-experts).

## 1. Bring evidence you are entitled to show

Select one current public lab and a sanitized engineering artifact that you may discuss. Explain your own contribution, the operating constraint, a failure you encountered, the decision made and what remains unverified. An artifact can be a small permitted code change, trace, evaluation case, runbook or integration contract. A slide of vendor logos and a list of credentials do not substitute for demonstrating the work.

Keep client names, employee records, credentials, private source and confidential incident material out of the exercise. Explain the problem using synthetic fixtures when permission is absent. Recent production experience is useful evidence to review, not a claim the kit grants to its user.

## 2. Prepare the learner's path

State one observable learning goal and prerequisites. Preserve the exact lab file/version, runtime, setup instructions, independent expected result and a deliberately changed condition. Identify which behavior is real execution and which is an authored replay or simulation. Prepare a fallback for a learner who cannot install the environment and record the mode actually used.

Connect the lesson to the existing DEPLOY Method: diagnose the task, establish an outcome, prove a bounded slice, land it within real constraints, operate from evidence and yield ownership. A small lesson can practice one boundary; it need not pretend to complete the whole method.

## 3. Observe a sixty-minute teach-back

Reading, artifact selection and environment setup happen beforehand.

| Minutes | Task | What the observer records |
| --- | --- | --- |
| 0–10 | Candidate states the user task, baseline and boundary in plain language. | Goal, prerequisites, unsupported assumptions. |
| 10–25 | Candidate runs the original and changed condition, locating actual evidence. | Commands, versions, expected versus observed result, truthful limits. |
| 25–40 | Learner explains and attempts a receiving task; candidate coaches without taking over. | Learner's own action, hints, author takeover and unresolved confusion. |
| 40–50 | Observer introduces a missing source, conflicting result or setup failure. | Candidate's reasoning, safe stop/fallback and evidence request. |
| 50–60 | Candidate revises the explanation and proposes the next bounded practice. | Exact correction, remaining gap and accountable next role. |

## 4. Review the observed work

Use **observed**, **partly supported**, **repair needed** or **not observed** for each dimension. These are observation labels, not a qualification score. Cite the actual command, screen, file or learner action beside each finding.

| Dimension | Evidence of a useful teaching performance | Repair signal |
| --- | --- | --- |
| Technical accuracy | Explains bytes, identity, source, state or evaluation boundaries using the selected lab's actual contract. | Claims a fixture proves production safety or silently changes the reference. |
| Reproducibility | Another person can prepare, run and locate the stated result with versions intact. | Only the author's machine or narrated screenshot works. |
| Failure reasoning | Predicts a changed condition, inspects actual refusal/recovery and preserves uncertainty. | Treats a successful process exit as the intended outcome. |
| Learner coaching | Learner performs a meaningful step and can explain what happened. | Instructor completes the task while the learner watches. |
| Safe practice | Uses permitted data, clear access boundaries and a feasible fallback. | Requests private records or credentials to rescue a demonstration. |
| Receiving transfer | A receiver finds evidence, names assistance and states the next bounded owner/action. | Attendance or a group presentation becomes a claim of independence. |

## 5. Co-teach before a delivery decision

A proposed instructor path is: artifact discussion, lab reproduction, observed teach-back, targeted repair, co-teaching with an agreed lead, then an explicit topic/version/audience-scoped delivery decision by the accountable LockedIn Labs owner. Keep the exact observation and limits. No automated pass or broad teaching authority is created by this document. Course use, material rights, payment, safeguarding, observation, support and cancellation arrangements require a written engagement before a public class is announced.

Refresh the review after material curriculum/runtime changes, a repeated learner misconception or a delivery incident. Retain corrections and versions. Expansion to another topic requires evidence for that topic; an approval to facilitate a beginner browser lesson does not establish authority to teach production security or lead a client engagement.

## Blank observation record

```text
Synthetic candidate / observer / learner aliases:
Proposed topic / audience / curriculum version:
Artifact and right to use it / candidate's contribution:
Observable goal / prerequisites / setup mode:
Original command / prediction / actual evidence:
Changed condition / prediction / actual evidence:
Learner action / explanation / assistance / author takeover:
Technical accuracy finding / evidence:
Reproducibility finding / evidence:
Failure reasoning finding / evidence:
Coaching and safe-practice findings / evidence:
Receiving-transfer finding / evidence:
Repair requested / owner / next observed attempt:
Proposed co-teaching scope / named lead to confirm:
Delivery decision: not recorded
Decision owner / approved scope / version / date, only if actually decided:
Remaining limits / renewal or review trigger:
```