06 — UPDATE MEMBER CPM

Per-member mini-CPM. Lighter than the RC client CPM. Tracks the member's constraint state, movement, and conversion-readiness for the value ladder.

When this step runs

After the recap .md is written (Step 8 in file 05). Auto-advances from there.

Output

File: cyp/tpc/members/[name]/cpm/[name]-cpm-[YYYY-MM-DD].md Audience: Kathryn — never client-facing. Lifecycle: New dated file each session. Prior CPMs stay in place for trajectory tracking.

Required inputs

1. The recap .md from Step 8 (this session)
2. The most recent prior CPM in members/[name]/cpm/ (if exists)
3. members/[name]/[name]-reference-data.md
4. members/[name]/[name].md (engagement context)
5. members/[name]/open-actions.md (carry-forward state)

What this step is NOT

• Not the RC full CPM. No multi-tier prioritization, no Mode 3 active project plan, no capability category mapping. Light by design.
• Not client-facing. Internal advisor doc.
• Not a substitute for the recap .md. Different purpose: recap captures what happened; CPM captures what the constraint state IS now.

Template

# [Member Name] — Mini-CPM
**Date:** [YYYY-MM-DD]
**Source session:** [name]-1on1-[YYYY-MM-DD].md
**Prior CPM:** [path to prior CPM or "first CPM"]

---

## Top Constraints (3-5)

### 1. [Constraint name — short]
- **Status:** [Open / In motion / Resolved / Watch]
- **Movement since last CPM:** [+ improving / – worsening / = unchanged / NEW / RESOLVED]
- **Evidence from this session:** [1-2 sentences]
- **Owner:** [Member / Kathryn / Both]

### 2. [...]

### 3. [...]

---

## Pattern Flags (optional — only when present)

- 🔁 Recurring — surfaced N+ sessions in a row
- 📈 Escalating — getting worse
- 📦 Same Root Cause — connects to constraint X
- ↔️ Solve Together — pairs with constraint Y
- 🧠 Behavioral — person-shaped, not system-shaped

---

## Conversion-Readiness Signal

**Current read:** [Stay TPC / Sprint candidate / OS candidate / No-fit / Re-evaluate]

**Evidence supporting the read:**
- [Specific signal from this session, with quote/reference if available]
- [...]

**Trigger to watch for:**
- The single observation that would move them to the next rung. Examples:
  - "Member explicitly asks Kathryn to *build* the artifact (not sequence it)" → Sprint
  - "Member can't execute action items between sessions for 2 cycles in a row" → Sprint conversation
  - "Member needs multi-system ongoing build" → OS

The trigger is **build-execution gap**, not prep depth or relationship intensity. TPC = sequencing + 1:1 advisory. AOS = Kathryn produces the artifacts.

---

## Carry-Forward Items (from prior CPM)

| Item | Status this session | Notes |
|---|---|---|
| [Constraint or open thread] | [Resolved / Still open / Reframed / Dropped] | [why] |

---

## New This Session

[Anything that surfaced this session that wasn't on the prior CPM — new constraints, new context, new conversion signals.]

---

## Group CPM Cross-Routing

**Does anything here belong in the group CPM too?**

If a constraint surfaced here is also showing up across 2+ other members → flag for cross-routing to `cyp/tpc/group/tpc-cpm-[date].md` at next group session update.

[List any items routing to group, with one-line reason.]

---

*CPM produced by /update-member-cpm step in the 1:1 cascade.*

Workflow

1. Read prior CPM (if exists). If first CPM, note "first CPM" — no carry-forward.
2. Read the recap .md from this session. Pull constraints surfaced, status changes, behavioral signals.
3. Cross-reference open-actions.md for items that have been resolved or that recur.
4. Identify the conversion-readiness signal. Default = Stay TPC unless a build-execution gap explicitly surfaced.
5. Write the CPM. Keep it tight — top 3-5 constraints, not 15. If the member only has 2 active constraints worth tracking, write 2.
6. Flag any items that should cross-route to the group CPM.

Quality gate (light)

• Every constraint traces to a specific moment in the session (transcript or recap)
• Conversion read is defensible — what specifically would make it move?
• No invented constraints — if it didn't surface, it doesn't belong on the CPM
• No double-counting with the recap — CPM is the state, recap is the record
• Compose from the gated ledger (Build A). The CPM's constraint evidence draws from the same gated ledger fact-rows the recap drew from (file 05 Step 5B) — don't assert a fact the claim gate didn't clear. The CPM is gated by the same source as the email, not separately. A Kathryn-edit to a recap line ripples here too (file 05 correction/ripple path) when the change traces to a shared ledger row.

Auto-advance

After writing the CPM, auto-advance to /draft-1on1-actions (file 07).