# LockedIn FDE Formation Operating Kit

`lockedin.training.fde-formation-operating-kit/v1` · version 1.0.0 · reviewed 2026-08-29

Use this copy-and-complete kit to establish a pod's working agreement and run a developmental after-action review (AAR) against one specific event. Keep the completed copy only in an approved team workspace.

Do not place passwords, tokens, credentials, protected health information, direct personal identifiers, client names, unnecessary personal data, restricted client material, or unapproved production records in this document. Approved private operational handles are allowed only where bounded role, participant, or action ownership requires them. Use bounded references to approved evidence instead of pasting sensitive material.

This kit is an authored training artifact and creates no saved platform state. It is not a legal signature, employment agreement, confidentiality agreement, attendance record, performance appraisal, evidence-gate decision, competency finding, qualification, credential, or proof that the LockedIn program is effective.

---

## OA-01 · Pod operating agreement

Complete before mission work begins and review whenever membership, scope, authority, data, or risk changes.

### Mission identity

- **Program key** (maximum 64 characters):
- **Pod key** (maximum 64 characters):
- **Mission key** (maximum 64 characters):
- **Mission purpose** (maximum 600 characters):
- **Named user and owner** (maximum 120 characters):
- **Outcome and exit standard** (maximum 800 characters):
- **In scope** (maximum 800 characters):
- **Out of scope** (maximum 800 characters):

### Five rotating ownership assignments

These are temporary mission responsibilities, not identities, employment roles, or proof of competence. Record exactly one current human owner per assignment and how the rotation will occur.

1. **Mission Lead** — owns mission framing, scope, user outcome, and the human decision boundary.
2. **Build Lead** — owns implementation coherence, integration, version control, and reversible delivery.
3. **Evals & Reliability** — owns evaluation design, failure evidence, observability, rerun criteria, and reliability claims.
4. **Security & Governance** — owns data boundaries, least privilege, threat review, compliance questions, and stop conditions.
5. **Operations & Adoption** — owns operator workflow, launch readiness, support, adoption, cost, rollback, and owner transfer.

**Role assignments**: record exactly five assignments. For each one, record the current owner, handoff trigger, and backup. Maximum 240 characters per assignment.

- **Mission Lead:**
- **Build Lead:**
- **Evals & Reliability:**
- **Security & Governance:**
- **Operations & Adoption:**
- **Rotation plan** (maximum 600 characters):

### Working commitments

- Consequential decisions have one named human owner.
- AI assistance is disclosed on every shared artifact, including tool/model context and what a human verified.
- Failures, uncertainty, dissent, and unknowns are surfaced with evidence; they are not hidden to protect the demo.
- Shared fields contain no secrets, credentials, protected health information, direct personal identifiers, client names, unnecessary personal data, or restricted client material. Approved private operational handles are used only for bounded accountability.
- Task disagreement is separated from personal blame. The team asks what evidence would change the decision.
- The team stops or escalates when authority, data permission, safety, compliance, or rollback conditions are unclear.
- A developmental AAR follows every significant stage, incident, failed gate, or material scope change.
- Acknowledgment of this agreement does not create attendance, competence, employment, legal, qualification, or credential evidence.

### Team operating details

- **Working cadence** (maximum 600 characters; include sessions, channels, and response expectations):
- **Decision and AI-assistance disclosure** (maximum 800 characters):
- **Data and evidence boundary** (maximum 800 characters):
- **Escalation and conflict path** (maximum 600 characters; name only an active staffed contact):
- **Mission-specific norms** (up to 5, maximum 240 characters each):
- **Agreement review triggers** (up to 5, maximum 240 characters each):
- **Member acknowledgments** (exactly 5, maximum 120 characters each):

### Attributed practice

This agreement adapts Recurse Center's four social rules—no feigning surprise, no well-actuallys, no back-seat driving, and no subtle -isms—with attribution and uses its self-directives as prompts to work at an appropriate challenge level, be generous, and remain responsible for one's own experience. These are attributed community practices, not evidence that this pod or program will be effective.

- Social rules: https://www.recurse.com/social-rules
- Self-directives: https://www.recurse.com/self-directives
- Adaptation permission: https://www.recurse.com/still-computing/issue-1

---

## AAR-01 · 20-minute formation after-action review

`[LOCKEDIN FORMATION AAR · V1]`

Run this review as soon as practical after the event and before the next dependent gate. The review is developmental, evidence-anchored, nonpunitive, and unscored. A separately reviewed incident artifact may support an evidence gate; this AAR does not make the gate decision.

For a pod event, use a temporary conductor who does not become a sixth role or acquire new authority. For an individual event, include the participant and an observer, facilitator, or objective information source.

### Completion rule

A completed formation AAR requires all of the following:

1. one specific bounded event;
2. active input from the participant or trained unit;
3. multiple information sources or perspectives;
4. at least one approved objective-media reference, such as a bounded log, diff, ticket, test result, recording, or timeline; and
5. at least one actionable next step with an owner and a reattempt or review condition.

If any element is missing, title the artifact exactly:

`LIMITED REFLECTION — NOT A COMPLETED AAR`

### 01 · Frame · 2 minutes

State the developmental, nonpunitive purpose. Name the event boundary, trained unit, intended standard, evidence permissions, stop conditions, and discussion ground rules.

- **Event ID** (maximum 64 characters):
- **Review unit** (`pod` or `individual`):
- **Event boundary** (maximum 320 characters):

### 02 · Intended · 3 minutes

Reconstruct what was supposed to happen: the outcome, task standard, authority boundary, decision owner, and stop condition.

- **Intended outcome and standard** (maximum 800 characters):

### 03 · Observed · 5 minutes

Reconstruct what happened from objective media and participant perspectives. Distinguish observation from interpretation and label unknowns instead of filling gaps from memory.

- **Objective-media references** (up to 8, maximum 240 characters each; references only—do not paste sensitive material):
- **Participant roles** (up to 8, maximum 120 characters each; include each relevant perspective):
- **Observed timeline** (maximum 1,600 characters):

### 04 · Explain · 4 minutes

Identify what to sustain, what differed, near misses, and causal conditions. Focus on process, system, tools, information, and role clarity—not personal blame.

- **Sustain** (up to 3 items, maximum 400 characters each):
- **Change or near miss** (up to 3 items, maximum 400 characters each):
- **Causal conditions** (up to 5 items, maximum 400 characters each):

### 05 · Commit · 4 minutes

Choose no more than three changes. Each change needs one human owner, a due date or review trigger, acceptance evidence, and a reattempt condition.

- **Owned next actions** (up to 3 items, maximum 600 characters each):
- **Reattempt plan** (maximum 600 characters):

### 06 · Read back · 2 minutes

Confirm the actions, owners, unresolved unknowns, escalation path, evidence permissions, and the next event that will test the change.

- **Unresolved unknowns** (up to 5 items, maximum 400 characters each):

### Research boundary

Structured debriefs have shown positive average effects across prior studies, with results moderated by context and implementation. This template does not establish the effectiveness of LockedIn training, an individual, a pod, or a field outcome. Use the protocol as a disciplined learning mechanism and evaluate its operation with bounded evidence.

- Keiser & Arthur (2021): https://pubmed.ncbi.nlm.nih.gov/32852990/
- Tannenbaum & Cerasoli (2013): https://cebma.org/assets/Uploads/Tannenbaum-Cerasoli.pdf
- U.S. Army FM 7-0, Appendix K: https://www.first.army.mil/Portals/102/FM%207-0.pdf

---

## Separate-system boundary

The Formation AAR is not the platform's existing private `[LOCKEDIN SESSION AFTER-ACTION · V1]` learner handoff. Do not copy one into the other or imply that either creates attendance, reviewed evidence, delivery confirmation, qualification, or credential authority.