04 — QUALITY: 1:1 Recap
Format: Pass/fail with blocking failures. When to run: After Step 6 (composing the email), before Step 8 (creating the Gmail draft). Then again after Step 10 (the .md is written).
Structural philosophy: This file is a traceability gate, not a graders' rubric. Every assertion in the email must trace to a row in the Step 5 ledger or a value in reference data. If a sentence has no source, it's not a "checklist failure" — it's a missing ledger row, and the fix is upstream in Step 5 or Step 11, not in re-writing the prose.
The blocking failures below are organized by what kind of upstream artifact failed: input load (Gate 1), ledger discipline (Gate 2A), composition discipline (Gate 2B), tool invocation (Gate 2C), or .md (Gate 3).
Gate 1: Pre-Draft Validation (Inputs Loaded)
All must pass before Step 5 (Ledger):
- [ ] Triage ran (Step 0.5): a thin / cut-short / no-decision call produced a short note + a board touch — NOT the full cascade. Heavy machinery on a thin call is a failure, not thoroughness.
- [ ] Load-bearing facts confirmed with Kathryn (Step 5C) when the email hinges on a fact the transcript doesn't nail (tool / account / plan / what's already set up).
- [ ] Member reference data file read first
- [ ] Cohort reference data read (when client is in a cohort) — including locked cadence vocabulary
- [ ] Transcript is the source — not a relay recap
- [ ] Calendar checked (Step 3) — next session facts written into working notes
- [ ] Prior recap email located and read for voice (if one exists)
If any Gate 1 item fails: Stop. Do not draft.
Gate 2A: Ledger Discipline
The Step 5 ledger is the structural protection that prevents most content failures. If the ledger is incomplete or sloppy, downstream prose fails.
- [ ] Ledger 5.1 (Commitments) — every row has a transcript line; every row tagged
explicit,hedged, orinferred(andinferredrows are dropped) - [ ] Ledger 5.2 (Decisions) — every row tagged
made,discussed, orrecommendation_open - [ ] Ledger 5.3 (Closing-eligible specifics) — every row has a transcript line; empty list is allowed and means no warm close
- [ ] Ledger 5.4 (New surfaced data) — every row that should update reference data is captured
- [ ] Ledger 5.5 (Calendar / next-session facts) — populated from Step 3
- [ ] Reporting-line claims extracted (Step 5.6) and the claim gate (Step 5B) printed CLEAR — not BLOCKED, not errored. Every Wins bullet traces to a PASS or advisor-confirmed claim (a gate that didn't run is not a pass).
- [ ] The gate protected the whole cascade, not just the email (Build A — source gate). Every fact-asserting line in EACH artifact — recap,
.md, CPM, drafts, agenda — traces to a gated ledger row (a PASS / advisor-confirmed claim). The ledger is the single gated source; an artifact line with no gated row is a fabrication, wherever it appears.
Gate 2B: Composition Discipline (Email Draft)
Voice
- [ ] Format matches the call's substance — a thin call is a short note, not forced Wins / What We Covered / Proposed Agenda sections. No manufactured or empty sections.
- [ ] Tone is peer-to-peer, not coddling or flip — no narrating the member's physical/emotional state ("you weren't comfortable," "feel better"), no "the real work" (implies the call was wasted), no jokey asides about their struggles. Warm-but-professional; the member is a respected peer.
- [ ] Opening references something specific from this call, drawn from a ledger row or a transcript-rooted fact (not a presumed framing)
- [ ] No coaching language ("you showed up," "I'm proud of") — see file 02 Forbidden Terms
- [ ] Close is either selected from ledger 5.3 OR omitted entirely (locked sign-off only)
Reference Data Compliance
- [ ] Every proper noun cross-checked against reference data (member + cohort)
- [ ] Every name spelled correctly
- [ ] Tools spelled correctly (ATOM, Karbon, TaxDome, etc.)
- [ ] Transcript-rendered tool/name spellings are normalized to the canonical spelling in ALL prose — no exceptions. Reference data tables include a "transcript misspelling" column (e.g., ATOM → "Adam", Karbon → "Carbon", Financial Cents → "Financial Sense"). The canonical spelling wins in every sentence the email and
.mdproduce, including casual mentions, parenthetical asides, summary lines, and ledger row descriptions. The audio rendering appears ONLY in two places: (a) the misspelling column of the reference data table itself, and (b) a ledger row that quotes the speaker's verbatim spoken phrase with the canonical name in parentheses (e.g., "I'll take Adam off" (transcript audio — ATOM)). All other prose normalizes. Common failure: model reads "Adam" in transcript, copies it into prose because it's "what was said." Reference data overrides transcript — always. - [ ] Abbreviations forbidden by file 02 are spelled out in full — most common: practice management software (NEVER "PMS"). Check
02-1on1-recap-terminology.mdForbidden Terms table for the full list. - [ ] Every cadence reference verified against file 02 Cadence Vocabulary by Program — for TPC: Monday = Momentum Monday (group), Thursday = co-working. Conflations are blocking.
- [ ] Place names use the unambiguous form from the transcript. "State College" alone reads as an institution; the transcript said "State College Pennsylvania" — the email must say "State College, Pennsylvania" or "State College, PA." Same rule for any city name that's also a generic noun (Charleston, Lancaster, etc.) or any institution name that's also a place. Pull the qualifier the speaker actually used; don't strip it.
Content Traceability
- [ ] Every assertion in Wins & Progress traces to a transcript fact or a ledger 5.2
maderow - [ ] Every entry in What We Covered maps to a discussion topic (one line, no sub-bullets)
- [ ] Wins and What We Covered never state the same item (non-duplication rule, hard). Wins = what moved forward; Covered = what was discussed without a finished outcome. If a topic produced an outcome it appears once, in Wins, and is not repeated in Covered. The claim gate does NOT catch this (it certifies sourcing, not composition) — read the finished email as the recipient and compare the two sections by eye. A Covered section that restates the Wins is a blocking failure.
- [ ] What We Covered names topics, not keystrokes — no procedural/training minutiae ("don't download until final," "convert .md to .docx," "click the paper icon"). Topic-level only.
- [ ] No integration/connector stated as "on" unless the transcript confirms it connected AND it isn't gated. The claim gate (file 05 Step 5B) is the primary enforcement — a
factlike "SharePoint turned on" with no verbatim transcript citation is BLOCKED automatically, and the Step 6 win-rule disqualifies anything attempted-but-gated. This bullet is the interpretation residue the gate can't catch: distinguish (a) connector authorized (e.g., Microsoft 365 read-only), (b) a tool visible within a connector ("SharePoint folder search" is a tool inside Microsoft 365 — not its own connector), and (c) actually accessible (not blocked behind client IT). Never write "X connector turned on" for (b), or for anything gated behind client IT / a platform limit. - [ ] Every member Action Item passed the live-and-executable screen (file 05 Step 5.1): still outstanding (not already handled by Kathryn) AND known-how (the session taught it). A verbally-explicit commitment that fails either gate is dropped from the email. (Member action items are fine — they just have to be live and doable.)
- [ ] Every Action Item traces to a ledger 5.1
explicitrow — same for Rob's Items and Kathryn's Items. If 5.1 is empty for a side, the section is omitted entirely (not left empty). - [ ] Stance invariant — no between-session Kathryn build (hard, file 01). No line implies Kathryn produces the member's deliverables: no "we'll work on this together," "I'll bring a recommendation/build," "I'll set up X for you," and no Kathryn Action Item that is the member's own tooling / infrastructure / build. A member's build-need routes to the signal (file 07) or a note — never Kathryn's Action Items or a Kathryn-owned agenda item. (Rob 6/17: "we'll work through the cleanest path" on his SharePoint setup = the violation.) This kit is advisory-only — no DFY mode.
- [ ] Proposed Agenda is scoped to the next session's PURPOSE (ledger 5.5) and is member-track only. A makeup/catch-up or staff-onboarding session's agenda is that session's actual job — not a forward roadmap. Program/cohort-level builds (cascades rolled out to everyone, retreat themes, platform integrations) do NOT appear as the member's agenda — at most a "coming to the group" context line in What We Covered.
- [ ] Every entry in Proposed Agenda for Next Meeting maps to a ledger 5.1
hedged, ledger 5.2discussed, or ledger 5.2recommendation_openrow — after the scope + member-track filters - [ ] Close carries no progress-verdict — no "you're over the hump," "you'll be able to run this independently," "you're really getting it." Warm close is factual about their situation, never a grade on the member's competence/trajectory. Neutral service close is the safe default.
- [ ] No sentence states a decision that ledger 5.2 has tagged
discussedorrecommendation_open— describe what was discussed, not what was decided
Content Scoping (multi-recipient recaps)
When the email goes to more than one recipient (e.g., owner + manager + departing staff), filter content against the recipient list — not just the room. Things discussed in the room may still be inappropriate to put in writing to a multi-recipient audience. Audit each item before composition:
- [ ] No private ownership / equity / compensation references. "10% owner," "X% stake," partner buy-in/buy-out terms, individual salary or bonus details — all of these are stakeholder-private even if they were announced in the room. They belong in the
.mdand (if relevant) a separate Bev-only follow-up. Never in a recap going to staff. - [ ] No succession or transition framing that names individuals. "Bringing Steven into TPC," "Steven taking over," "transition coaching" — these are confidential to the owner/successor pair. Don't put them in a recap going to other staff who weren't designed into that conversation.
- [ ] No performance assessments of specific staff — even staff who weren't in the room. "Tammy is not fitting the team," "Rob's review behavior issues" — keep these in the
.md. Don't name in a multi-recipient email. - [ ] No diagnostic / coaching / advisory framing about specific people. That's stakeholder content that belongs in private channels.
- [ ] Test: if the email got forwarded to anyone at the firm who wasn't in the room — including someone who shouldn't see it — would any line embarrass or expose anyone? If yes, move that line to the
.mdonly.
The default for multi-recipient recaps is operational and logistical — what was decided about workflow, schedules, deliverables, and next steps. Anything personal, confidential, or stakeholder-specific gets filtered out, regardless of whether it was on the table in the room.
Content Scoping (single-recipient — conversational filter)
Even single-recipient recaps require filtering of conversational content that was real but doesn't belong in writing. The audit applies to every recap, not just multi-recipient ones. Test each item against this list before composition:
- [ ] No content marked confidential by the speaker. "Between you and me," "confidentially," "this stays between us" — that content stays out of the email regardless of recipient. The marker is the speaker's choice; honor it.
- [ ] No personal rapport content shared as relationship-building. Health updates, family arcs, employee tenure history, personal life details — these were on the table because two people who trust each other were talking. They are not engagement record. Move to
.mdif anywhere. - [ ] No illustrative stories captured as commitments. When Kathryn describes how she runs her own business (e.g., "I have a 12-person AI team") to make a point, that's a vivid illustration — not a deliverable. The email locks what was agreed to be built, not what was described as context. Test: did the speaker say "I'll build X for you" or "here's how X works for me"? The second doesn't go in.
- [ ] No strategic anchors that work better implicit. Some pricing architectures, positioning moves, and longer-game setups land more cleanly when the structure isn't named. If Kathryn priced this engagement to set a future anchor (e.g., a Sprint at the same number that will appear monthly for a downstream Advisory OS), the future anchor doesn't go in the recap — the future conversation does. Naming the anchor short-circuits it.
- [ ] No live coaching pivots or hard redirects. "I don't know if that's the right problem to be solving" was real and valuable in the moment, but it doesn't belong in writing. Coaching moves were live interventions, not documentation. The recap captures what was decided after the redirect, not the redirect itself.
Why this matters even for single-recipient recaps: the email is a forwardable record. The client may forward to a partner, an investor, an attorney. They may reread it months later and pull lines out of context. Content that was right in the room can be wrong on paper. Filter accordingly.
Prospect / Sales Recap Variant — Composition Patterns
Sales recaps (post-close, post-Sprint-kickoff, post-prospect-call) have a different composition shape than ongoing-cadence TPC member recaps. The same kit applies — the ledger discipline, the no-fabrication rule, the conversational filter — but the prose patterns shift. Use this checklist when composing a recap that is closing or kicking off an engagement (not a recurring session recap).
- [ ] Subject line forecasts forward. Format:
Meeting recap - [M-DD-YYYY] and next steps(or equivalent forward-anchoring phrase). The ongoing-cadence subject (Meeting recap - [date]alone) is structurally implied by the recurring relationship; a sales recap subject needs to signal that forward action is in the body. - [ ] Paragraph density leans breathability. In the "what we agreed" or "what we're building" section, each substantive sentence gets its own paragraph. No three-sentence blocks under section headers. Each line carries its own weight; the reader can skim. Matches the email-voice golden (Nick Build4 pattern).
- [ ] Bold headers in BOTH plain text and HTML. Wrap section headers in
asterisksin the plain-textbodyANDtags inhtmlBody. Gmail's plain-text view renders asterisks as bold; recipients on either format see the structure. The kit's prior pattern ofHTML only with bare plain-text headers leaves the plain-text fallback unformatted. - [ ] Contract-artifact lines: state the artifact and the due date with the specific date. "Invoice attached. Payment is due before [next action] on [Month DD]." Not "lands before session 1" or "due before we start" — explicit calendar date. The recipient is signing a contract; the language matches that register.
- [ ] Forward-look lines anchor the timing. "We'll pick that conversation up at that time" / "on the back end" / "after [X]." Never leave timing implied. A sales recap forecasts when the next conversation happens; that anchor is what makes the forecast load-bearing instead of vague.
Why this matters: Sales recaps are forwardable contract proxies. The recipient may reread the email weeks later, forward to a partner, or pull lines into a contract discussion. Breathability + forward anchoring + explicit dates + bold-in-both-formats make the email do its contract work cleanly. The ongoing-cadence recap (TPC member) is a different artifact — it lives in a recurring rhythm, and tighter prose serves that context.
Structure
- [ ] Subject:
Meeting recap - [M-DD-YYYY]for ongoing-cadence recaps. For prospect/sales recaps (close, kickoff, post-prospect-call), useMeeting recap - [M-DD-YYYY] and next stepsper the Prospect / Sales Recap Variant section above. - [ ] Sign-off:
Talk soon, Kathryn(locked — no variations) - [ ] Greeting names every person on the To line, in the order they appear. Single-attendee 1:1 → "Hi [FirstName],". Multi-attendee session (owner + manager + key staff in the room) → "Hi [Name1], [Name2], and [Name3],". The greeting is bound to the recipient list — they are composed as one unit, not separately.
- [ ] Recipient list matches the session attendees. All client-side attendees who were in the room go on To (no cc) unless there's a specific reason to split. cc is reserved for people who weren't in the room but need the record.
- [ ] If the recipient list changes during drafting, the greeting is invalidated. Re-compose the greeting before saving the draft. Adding a name to To, moving cc → To, or any other change requires a greeting re-check.
AI Tell Scan
- [ ] No "That's exactly..."
- [ ] No "I want to highlight..." (unless genuinely introducing a quote)
- [ ] No stacked encouragement
- [ ] No exclamation points unless prior recap to this person used them
Gate 2C: Tool Invocation (Step 8)
- [ ]
mcpclaudeaiGmailcreate_draftcalled with bothhtmlBodyandbody. Plain text alone is a blocking failure. - [ ]
htmlBodyfollows the skeleton in file 05 Step 8 —headers,/lists, no markdown hyphens - [ ] No signature block included (Gmail auto-adds it)
If a correction is needed after the draft exists: the fix path is "trace error → upstream artifact → Step 6 + Step 8 again." Editing the draft in conversation is forbidden — it bypasses the ledger discipline AND drops rich-text formatting.
Gate 3: Personal .md Recap QC
- [ ] Filename:
[firstname]-1on1-[YYYY-MM-DD].md - [ ] Location:
cyp/tpc/members/[name]/sessions/ - [ ] Ledger included verbatim (Step 5 — permanent audit trail)
- [ ] Sections: Summary, What We Discussed, Takeaways, Action Items (from ledger), Connections, Quotes, Kathryn's Prep, Draft Agenda, Calendar Events Created, Notes for Next Time
- [ ] Captures everything — including things that didn't make the email
Blocking Failures (collapsed structural set)
After the structural pass, file 04 stopped trying to catch every category of error post-draft. Each remaining blocking failure points to the upstream artifact that should have prevented the error, with the fix described as a structural action (not a re-write).
| # | Failure | Where the upstream protection lives | Fix |
|---|---|---|---|
| 1 | Reference data not read first | Step 1 (file 05) | Stop. Re-run from Step 1. |
| 2 | Recap used as source instead of transcript | Step 2 (file 05) | Stop. Source the transcript. |
| 3 | Name misspelled | Step 1 + Step 11 (ledger 5.4 → reference data) | Update reference data, regenerate via Step 8. |
| 4 | Email content not traceable to ledger (was: action item fabricated, decisions stated that weren't made, fabricated close) | Step 5 (ledger 5.1, 5.2, 5.3) — if a sentence has no row to draw from, the row is missing or wrongly tagged | Trace the sentence back to the ledger. Add the row, fix the tag, or drop the sentence. |
| 5 | Reference data stale (was: name surfaced not added) | Step 11 (apply ledger 5.4) | Apply the ledger 5.4 list to reference data. |
| 6 | Cadence conflated (e.g., "Monday at coworking" for TPC) | File 02 Cadence Vocabulary by Program | Look up the table. Re-write the reference. |
| 7 | Coaching language | File 02 Forbidden Terms | Delete. |
| 8 | Subject line wrong | File 02 Subject Line — Locked Format | Re-write. Must be exactly Meeting recap - [M-DD-YYYY]. |
| 9 | Plain-text formatting instead of rich text | Step 8 (file 05) — locked path | Regenerate via create_draft with both htmlBody and body. |
| 10 | Conversation-edited draft instead of regenerate | Step 8 (file 05) — correction path | Trace error to upstream artifact, fix it, re-run Step 6 + Step 8. |
| 11 | Greeting doesn't match the To line (e.g., "Hi Bev," with Steven and Jess also on To) | Step 6 (file 05) — recipient list and greeting are composed as one bound unit | Re-compose the greeting against the current To line. Recipient changes mid-draft invalidate the prior greeting; re-check is mandatory, not optional. |
| 12 | Ambiguous place / institution reference (e.g., "State College" without "Pennsylvania" — reads as "going back to school") | Step 5 ledger 5.4 (new surfaced data) + Step 6 composition — pull the speaker's qualifier verbatim | Re-write with the qualifier the transcript used. City names that are also generic nouns, institution names that are also places — always include the disambiguator. |
| 13 | Stakeholder-private content in a multi-recipient email (e.g., ownership stake, succession plan, individual compensation, performance assessment of a specific staff member) | Step 6 composition — Content Scoping pass against the recipient list | Strip the line. Move to the .md, or to a separate single-recipient follow-up email. The default for multi-recipient recaps is operational/logistical only. |
| 14 | Conversational content in writing — confidential asides ("between you and me"), personal rapport content (health, family arcs, employee tenure), illustrative stories captured as commitments (e.g., "12-person AI team" treated as a deliverable), strategic anchors that should stay implicit (pricing architecture for downstream offers), live coaching pivots ("I don't know if that's the right problem to be solving") | Step 6 composition — Content Scoping (single-recipient — conversational filter) pass | Strip the line. Move to .md if useful for future reference. Composition discipline: the recap is a forwardable record, not a transcript. Content that was right in the room can be wrong on paper. |
| 15 | Prospect/sales recap composed in ongoing-cadence shape — subject line missing forward-anchor; dense three-sentence paragraphs under section headers; bold headers in HTML but bare in plain text; vague timing ("lands before session 1", "we'll pick that up") instead of explicit dates and timing anchors | Step 6 composition — Prospect / Sales Recap Variant section above | Re-compose with: subject + and next steps; one substantive sentence per paragraph in "what we agreed"; asterisks around plain-text headers; "Payment is due on [date]" + "at that time" / "on the back end" anchors on forward looks. |
The collapse: Original blocking failures #4 (Citation Test), #11 (decisions not made), and #12 (fabricated close) all collapsed into #4 above ("email content not traceable to ledger"). They're the same structural failure — model composing assertions without a verified source — and the structural fix is the ledger, not three separate post-draft checks. Original #5 (reference data not updated), #6 (calendar not checked), and #10 (cadence conflated) collapsed similarly into upstream-pointing references.
Common Failure Modes (what to look for)
| Symptom | Upstream cause | Fix location |
|---|---|---|
| Generic opener ("Great session today") | Composition default — opener wasn't drawn from a specific ledger or transcript fact | Step 6 — pick a ledger 5.2 made row or a ledger 5.1 explicit win |
| Sub-bullets in What We Covered | Step 6 composition rule violation | One line per topic — re-compress |
Sentence says "we decided X" but ledger 5.2 has X tagged discussed | Ledger discipline + composition discipline | Either re-tag the row (if a made decision was missed) or re-write to "we discussed X" |
Action item appears that has no ledger 5.1 explicit row | Ledger missing the row OR composition pulled from hedged/inferred | Add the row (with line citation) or remove the item |
| Close contains a specific (e.g., "safe travels") with no ledger 5.3 row | Composition violated select-from-ledger rule | Drop the close line |
| Cadence reference conflates terms (e.g., "Monday at coworking") | File 02 Cadence Vocabulary not consulted | Re-write per the table |
| Plain text in the draft, no rich text | Step 8 locked path bypassed (often during corrections) | Regenerate via create_draft with htmlBody |
| Renewal date / new staff member missing from reference data | Ledger 5.4 row missing OR Step 11 not applied | Add the row or apply the list |
| Greeting "Hi [FirstName]," when To line has multiple recipients | Step 6 — recipient list and greeting were composed as separate units instead of bound | Re-compose greeting from the current To line. Pattern: any time recipients change, the greeting check is mandatory before save. |
| "State College" / "Charleston" / "Lancaster" without qualifier | Step 6 — composition stripped the disambiguator the transcript used | Use the speaker's full reference verbatim ("State College, Pennsylvania"). City-also-noun and institution-also-place names always need the disambiguator. |
| Private ownership / succession / individual-staff content in a multi-recipient email (e.g., "Steven now 10% owner" with departing staff on To) | Step 6 — Content Scoping pass not run against the recipient list | Strip the line. Move to .md or a separate single-recipient email. Multi-recipient recaps are operational/logistical by default. |
| Member Action Item that's already handled or wasn't taught (e.g., "invite Natalie" when Kathryn already sent the invite AND inviting was never walked through) | Step 5.1 — live-and-executable screen not run | Drop from the email; note in .md as done or route to the next hands-on session. explicit ≠ valid action item. |
| Proposed Agenda over-promises the next session / includes program-level items (e.g., "deploy the cascade, add pre/post cascades, retreat prep" for a makeup onboarding session) | Step 5.5 (purpose not captured) + Step 6 (scope + member-track filters not run) | Re-scope to what the session actually is; pull program/cohort builds out (group channel, not the member's agenda). |
| Progress-verdict close ("you're over the hump," "you'll run this independently") | Step 6 — close composed as an assessment instead of selected from ledger 5.3 | Cut. Use a ledger 5.3 factual specific or a neutral service close. |
| Procedural keystroke detail in What We Covered ("don't download until final," "convert to .docx") | Step 6 — topic compressed at how-to level instead of topic level | Re-compress to the topic; drop the how-to. |
Change Log
- 2026-06-19 (Meryl 6/19 — triage + facts-confirm + format/tone gates): Added Gate 1 checks for triage (thin call → note + board touch, not the full cascade) and load-bearing-facts confirmation before client copy, plus Gate 2B Voice checks that format matches the call's substance (no manufactured sections) and tone is peer-to-peer, not coddling or flip. Reason: the Meryl 6/19 cascade over-produced — full machinery + an invented agenda on a cut-short check-in, four redrafts on an assumed account fact, then an over-familiar note ("you weren't comfortable," "good luck finding a chair that actually works") — an hour spent on a 3-line note. Structural fixes live in file 05 (Steps 0.5, 5C, 6, 8); these are the matching gate checks.
- 2026-06-10 (Rob 6/10 cascade — Kathryn's edits to the sent recap): Added Gate 2B Content Traceability checks + Common Failure Modes rows for five composition disciplines (structural changes live in file 05 Steps 5–6; these are the matching gate checks): (1) member Action Item live-and-executable screen (still outstanding AND known-how); (2) Proposed Agenda scoped to the next session's purpose + member-track-only (program/cohort builds excluded); (3) no progress-verdict close; (4) What We Covered names topics not keystrokes (no procedural minutiae). Reason: Kathryn hand-edited the Rob 6/10 recap, cutting an already-handled/untaught member to-do ("invite Natalie"), trimming a 4-item agenda to the single immediate makeup-session step (pulling out program-level TPC builds), removing the "living documents" keystroke line, and replacing a progress-verdict close ("over the setup hump… run independently") with a neutral "Let me know if you have any questions!" Golden file 03 refreshed with the sent version. These are upstream composition gaps (Steps 5–6), not post-draft checks — file 04 carries the gate, file 05 carries the structural fix.
- 2026-04-29: Added Citation Test for action items + reference-data-update + calendar-lookup blocking failures. Reason: Rob 4/29 cascade run produced 5 fabricated "Rob's Action Items" (Kathryn recommendations + soft acknowledgments treated as commitments), missed Natalie addition to reference data, skipped calendar lookup. Mode 2 fix.
- 2026-04-29 (second pass): Added blocking failures for plain-text-instead-of-rich-text formatting, cadence conflation (Monday/Thursday in TPC), decisions-not-made stated as decided, fabricated close. Reason: Rob 4/29 corrected recap was caught again on Kathryn's review.
- 2026-04-29 (structural pass): Restructured this file from a 12-row blocking-failure stack into a traceability gate that points to upstream structural protections. Original failures #4 (Citation Test), #11 (decisions not made), #12 (fabricated close) collapsed into a single "email content not traceable to ledger" entry — they're all the same failure (composition without a verified source), and the structural protection is Step 5's ledger in file 05. Original #5 (reference data not updated), #6 (calendar not checked), and #10 (cadence conflated) similarly collapsed into upstream-pointing references. Net: 12 → 10 blocking failures, but more importantly the file's role changed from "graders' rubric" to "traceability gate." Reason: Pass 3 of Rob 4/29 cascade surfaced that the kit was being patched reactively into file 04 rather than restructured upstream — the dumb fix was stacking rows; the structural fix was inserting an extraction phase (the ledger) between transcript-read and prose-composition.
- 2026-04-29 (Bev cascade Pass 2): Added blocking failure #11 (greeting doesn't match To line) + Gate 2B Structure rules binding greeting to recipient list + Common Failure Modes row. Reason: Bev 4/29 cascade produced a draft with all three attendees (Bev, Steven, Jess) on To but only "Hi Bev," in the greeting. The mismatch happened because the recipient list was changed after the greeting was composed (Pass 1 had cc Steven + Jess; Kathryn corrected to all-3-on-To; the greeting was not re-composed). Structural fix: greeting and To line are a bound composition unit in Step 6 — recipient changes invalidate the greeting by default. Kathryn caught this manually and called out that this is a kit gap, not a memory-layer issue.
- 2026-04-29 (Bev cascade Pass 3): Added blocking failure #12 (ambiguous place / institution reference) + Reference Data Compliance check + Common Failure Modes row. Reason: Bev 4/29 cascade produced "Jess heading to State College in June" — reads as her going back to school, not relocating to the town in Pennsylvania. The transcript was unambiguous ("State College Pennsylvania"); composition stripped the qualifier. Structural fix: place names that are also generic nouns or institution names always carry the disambiguator the speaker used. Kathryn called this "really poorly executed" — the kit must enforce verbatim qualifier preservation.
- 2026-04-29 (Bev cascade Pass 4): Added new Gate 2B section "Content Scoping (multi-recipient recaps)" + blocking failure #13 (stakeholder-private content in multi-recipient email) + Common Failure Modes row. Reason: Bev 4/29 cascade produced a draft to Bev + Steven + Jess that included "Steven now 10% owner" and "bringing Steven into TPC" — Jess (departing staff) shouldn't be receiving owner ownership-stake announcements or succession planning content in a written record, even though both were discussed in the room. Structural fix: multi-recipient recaps require a Content Scoping pass that filters private ownership/equity, succession/transition framing, individual compensation, and performance assessments of specific staff out of the email. These belong in the
.mdand (if needed) a separate single-recipient follow-up. Default for multi-recipient recaps is operational/logistical only. Connects to the existing memoryfeedback_stakeholder-content-in-writing.md— the kit now enforces it structurally. - 2026-05-18 (Tracy 5/18 cascade, Pass 3): Tightened Gate 2B Reference Data Compliance with explicit transcript-misspelling normalization rule (transcript-rendered tool/name spellings normalize to canonical in ALL prose — audio rendering appears ONLY in the reference data misspelling column or in a ledger row quoting the verbatim spoken phrase with canonical in parentheses). Added explicit abbreviation rule pointing at file 02's Forbidden Terms table (practice management software, never "PMS"). Reason: Tracy 5/18 cascade let "Adam" pass into recap, CPM, and reference data prose (7 instances), and used "PMS" abbreviation across CPM and cascade report prose. Both rules existed implicitly (reference data overrides transcript; file 02 forbids PMS) but Gate 2B didn't make them blocking, so composition pulled "what was said" instead of "what's canonical." Kathryn caught both ("ATOM not adam" and "PMS — what is this?"). Structural fix at the check level, not new structural steps.
- 2026-06-03 (Martin sales recap, prospect lane): Added new Gate 2B section "Content Scoping (single-recipient — conversational filter)" + blocking failure #14 (conversational content in writing). Five new filters: confidential asides ("between you and me"), personal rapport content (health, family arcs, employee tenure), illustrative stories captured as commitments, strategic anchors that should stay implicit (pricing architecture for downstream offers), live coaching pivots. Reason: Martin 6/3 prospect close call surfaced multiple categories of content that were real and valuable in the conversation but didn't belong in writing — the existing Gate 2B Content Scoping section only addressed multi-recipient stakeholder filtering, not the conversational filter that applies to every recap. The illustrative-stories-as-commitments failure mode in particular has a structural cousin in the existing ledger discipline (recommendationopen routes away from action items), but the kit hadn't named "vivid descriptions of speaker's own context" as a category that gets routed away from the email. Same with confidential markers — the speaker's "between you and me" was a discipline lever the kit didn't make blocking. Structural addition at the check level. Connects to the existing memory
feedbackstakeholder-content-in-writing.md — the principle expanded from "stakeholder-protective filtering" to "forwardable-record filtering." - 2026-06-03 (Martin sales recap, Pass 2 — Kathryn's edits): Added Gate 2B section "Prospect / Sales Recap Variant — Composition Patterns" + blocking failure #15 (prospect/sales recap composed in ongoing-cadence shape) + variant note on Subject under Structure. Five new patterns: (1) subject line forecasts forward (
+ and next stepsor equivalent); (2) paragraph density leans breathability — one substantive sentence per paragraph in the "what we agreed" section; (3) bold section headers in BOTH plain text (asterisks) and HTML (); (4) contract-artifact lines state the artifact + explicit due date with specific calendar date ("Invoice attached. Payment is due before session 1 on June 10th"); (5) forward-look lines anchor timing explicitly ("at that time", "on the back end") — never leave timing implied. Reason: Pass 1 produced a Martin recap that landed correctly on content but composed in ongoing-cadence shape — dense paragraphs under bold-HTML-only headers, "lands before session 1" instead of "due on June 10th," and vague "we'll pick that conversation up" instead of an anchored "at that time." Kathryn edited the draft in Gmail to demonstrate the prospect/sales register: standalone-sentence paragraphs, plain-text-bold asterisks, explicit due date, explicit timing anchor, subject extended with "and next steps." Structural fix: the kit treats sales recaps and ongoing-cadence recaps as the same shape, when they're actually two registers — the prospect/sales recap is a forwardable contract proxy and needs breathability + explicit anchors to do that contract work. - 2026-06-17 (Rob 6/17 Natalie-onboarding cascade, Pass 2 — Kathryn review): Added Gate 2B Content Traceability check forbidding stating an integration/connector as "on" unless the transcript confirms it connected and it isn't gated — distinguish authorized vs. tool-visible-within-a-connector vs. actually-accessible. Reason: the recap listed "SharePoint search" among connectors turned on; in fact SharePoint folder search is a tool inside the read-only Microsoft 365 connector, and access to the client's SharePoint site is IT-gated and not live (only Otter was connected on the call). Kathryn caught it on pre-send review ("did we turn on the connector for SharePoint? are you sure?"). Composition/traceability check, not a structural step.
- 2026-06-17 (Rob 6/17 cascade, Pass 3 — port the AOS claim gate, structural): Escalated the Pass 2 connector row into a structural fix. The fail-closed claim gate (file 05 Step 5B,
cyp/tpc/qc/verify_claims.py) is now the primary protection against status/wins overstating — every reportingfactmust carry a verbatim transcript citation or it BLOCKS. The connector bullet above is retained only as the interpretation residue the gate can't enforce (authorized vs. tool-visible vs. accessible). Added a Gate 2A item requiring the gate to print CLEAR before drafting. This is the escalation the kit's own "stop stacking rows" rule calls for: three overstating-adjacent patches (6/10 progress-verdict, 6/17 connector row, thefeedback-no-overstatingmemory) collapse into one mechanism — ported fromaos-client-na(6/17) so both cascades run the same gate. - 2026-06-17 (Rob 6/17 cascade, Pass 4 — Kathryn review of the drafted recap): Added the hard non-duplication rule (Wins and What We Covered may never say the same thing) to Gate 2B + file 05 Step 6. Reason: the drafted recap passed the claim gate (every line transcript-cited) but Wins and What We Covered restated the same five items — a duplicated, padded email. The gate certifies sourcing, not composition, so CLEAR was mistaken for "good." The fix is the rule NA's recap-email skill already carries; porting the gate without porting NA's composition rules was the gap. Also reinforces Rule 8 (recipient-first verification): read the finished email as the recipient and eyeball Wins vs. Covered — a deterministic gate is not a substitute for reading it.