Proven — Promoted from Emerging May 8, 2026 (CIO promotion authority per methodology-audit-policy-updates-2026-03-16.md). Trial-application evidence: six-section structure operated without structural failure across 7 cohort migrations Apr 22-26 (HOST → CIO → Comms → CXO → PPM → Architect → exec); decreasing review-volume signal observable (HOST 5+1 → CIO 4 → Comms 3+1 → CXO 2 → PPM 3); pre-seam authoring discipline held in every case (no post-seam reconstruction required); Section 6 candor invitation produced cohort-level methodological signal (PP-002 emerged as tier-3 finding via HOST 360 v0.2 synthesis); reception-first reading discipline operated. All three pattern claims (pre-seam authoring, Section 6 candor, reception-first reading) validated. Originally identified through three-project convergence (Piper Docs, OpenLaws coffee-spill handoff, Klatch Phase 3.5 handoff prompt); filed Emerging Apr 27 under CIO self-approval authority + PM concurrence on M1 audit recommendation B4. Promotion analysis at dev/active/cio-pattern-promotion-analysis-2026-05-08.md.
Portable — Any team operating across instances, sessions, or boundaries that creates context discontinuities will encounter this. Particularly relevant for AI-agent workflows where session boundaries are frequent and instance retirements/migrations happen on a sprint cadence. Generalizable to any human-or-machine handoff where the departing party has knowledge the arriving party will need.
Most teams write continuity documents after a discontinuity has occurred — a postmortem, a handoff retrospective, an “I wish I’d said this” follow-up. By then the context has degraded: the departing party is gone or distracted; the arriving party has reconstructed an incomplete picture from artifacts; the gap that the continuity doc is meant to bridge has already widened.
The Continuity Memo Before the Seam pattern inverts this. The continuity document is written before the discontinuity occurs, while the departing party still has full context, by the departing party themselves. The arriving party reads the memo as their first orientation, before reconstruction begins.
This pattern is closely related to but structurally distinct from a handoff memo. A handoff memo can be written at any time (often after the seam); a continuity memo’s defining property is its temporal placement — written before the seam closes.
A discontinuity occurs (session ends, instance retires, role transitions, project transfers). The arriving party — successor instance, new role-holder, downstream team — must reconstruct the departing party’s context. Available materials:
The reconstruction is always incomplete. The departing party held tacit knowledge — open threads, “I’d tell my successor X,” half-formed observations, relationship-level cues — that the arriving party cannot recover from artifacts.
Three forces:
Docs sessions routinely produce wrap memos before context-window closure or session-end. The wrap names: open threads, files modified, what’s in flight, what the next session should pick up first. Successor Docs sessions read the wrap as their first orientation. Cost: 5–10 minutes at session end. Value: predecessor’s tacit decisions surface immediately rather than getting reconstructed from git log.
Calliope (OpenLaws coordinator) wrote a continuity memo anticipating a discontinuity rather than after one — the memo named the potential failure modes that would matter if the team got hit by a bus. The framing — “what would I want my successor to know if I disappeared this afternoon?” — produced more candor and specificity than postmortem-shaped framings. The memo became reference material for OpenLaws onboarding.
Klatch’s Phase 3.5 transition included a handoff prompt that the departing instance wrote for the arriving instance, before retirement. The prompt structure (six sections: current state, open threads, relationships, lessons, what’s changed, candid notes) became the template for subsequent migrations across the DinP ecosystem (Piper Morgan HOST/CIO/Comms/CXO/PPM/Architect migrations Apr 22–26).
In all three cases, the continuity material was authored by the departing party before the seam closed. In all three cases, the arriving party reported the material as the single most useful onboarding artifact — more useful than briefings, role docs, or formal training.
Whenever a foreseeable discontinuity is approaching, the departing party writes a continuity memo before the discontinuity occurs. The memo is structured (six-section template established by HOST migration Apr 22 + Klatch Phase 3.5):
A continuity memo is written when:
The arriving party reads the continuity memo first — before the formal briefing, before the role docs, before any reconstruction work. This is counter to the common pattern of reading formal docs first and the personal handoff last; the discipline reverses the order because the personal handoff is fresher and more accurate.
| Don’t Do This | Why | Do This Instead |
|---|---|---|
| Write the continuity doc as a postmortem | Information value degrades after the seam closes | Write before the seam, while context is fresh |
| Skip §6 because it feels awkward | The candid section produces the highest-signal content | Use the explicit candor invitation; PM/coordinator’s framing matters here |
| Treat the continuity memo as ceremony | Ceremony degrades — gets rushed, then skipped | Treat as the highest-leverage 30–60 min of the departing session |
| Write only what’s “appropriate” for formal record | Formal-only framing loses the tacit knowledge | Section 6 or candor sub-sections preserve tacit material with explicit candor invitation |
| Have the arriving party read formal docs before the continuity memo | The personal handoff is fresher; reading order matters | Continuity memo first, formal docs second |
Piper Morgan Docs sessions established the wrap-memo pattern at session-end as standing practice.
Three independent applications of the pattern surfaced in the DinP ecosystem within ~10 days: Piper Docs (recurring), OpenLaws Calliope coffee-spill memo, Klatch Phase 3.5 handoff prompt. The convergence was independent — no coordination across projects.
CIO M1 methodology audit §3.5 recognized the three-project convergence and recommended formalization: “Strong candidate for Emerging pattern. The three-project convergence is good evidence. File when ready.”
HOST migration Apr 22 produced the canonical six-section structure that all subsequent Piper Morgan Code-migration handoffs (CIO Apr 23, Comms Apr 23, CXO Apr 25, PPM Apr 25, Architect Apr 26) adopted. The exec review pass during each migration validated the structure as load-bearing — gaps caught with decreasing volume across migrations (HOST 5+1 → CIO 4 → Comms 3+1 → CXO 2 → PPM 3 fixes), evidence the pattern is internalizing.
Filed as Emerging pattern under CIO self-approval authority per PM concurrence on M1 audit recommendation B4. Promotion to Proven pending one more cycle of trial application — exec migration is the natural validation event.
dev/active/handoff-host-chat-to-code-2026-04-22.md — the canonical six-section examplePattern created: April 27, 2026 Origin: Three-project convergence (Piper Docs / OpenLaws / Klatch), March–April 2026 Author: CIO (formalizing cross-project pattern) Status: Emerging (CIO self-approval, PM concurrence) Promotion criterion: one more cycle of trial application across migration events; exec migration is the natural validation event.