feedback_partner_pitch_doc_pattern

When Rich asks for a partner-pitch / leave-behind / pre-meeting document for a law firm or similar professional-services partner, the established pattern is below. First validated 2026-04-28 with MLP / Jane Hunter pitch (commits 0f6059b → b9f879f).

Why: Solicitors are detail-readers and like substantive prospectus-style docs they can scan in 15 minutes before a meeting. Length signals seriousness; visuals at the end (not interrupting prose) suit reading flow. They check public-site terminology — using the canonical openinherit.org wording reinforces credibility.

How to apply:

Structure (9 numbered sections + appendix):

1. At a glance — headline pitch + free pilot framing
2. The closed loop — one-line workflow (MFI → IW → IAS → fee)
3. INHERIT — the underlying standard
4. MyFamilyInherits.com — consumer surface + lead-partner intro
5. InheritWills.com — conversion bridge
6. IAS — solicitor’s working surface
7. Beyond the pilot — wider INHERIT ecosystem (4 partner roles + faith-tradition coverage)
8. The pilot in practice (term, scope, what’s in/out)
9. What we’d ask of the firm

• closing sections: Who we are, Next steps, In closing, Contact, Changelog, Appendix

Length: 12-13 A4 pages. Solicitors prefer detail on paper.

Form-factor: PDF via standard pipeline (tt-pdf-template.html + WeasyPrint), auto-export to /mnt/c/Users/Richard/Downloads/. Filename: <FIRM>-pilot-invitation.pdf.

Source location: ~/testatetech/docs-strategy/outreach/<firm>-<contact>-pilot-invitation.md. Folder precedent: step-cheshire-donna-eland-reply.md.

British English — UK-facing partner targeting per global CLAUDE.md §17.5 (NOT international English; that’s reserved for new INHERIT v2 + InheritKit specs).

Don’t mention “v2” — Rich’s standing rule for partner-facing material. Use generic “INHERIT is being built to…” for forward-looking capabilities. Future-tense capabilities are fine; version numbers are not.

TT brand-name expansions (canonical, Rich-confirmed — not in brand-architecture.md so easy to get wrong):

• IAS = InheritKit Authoring Studio (NOT “Inherit Advisory System” — that was my v1.4 guess that Rich corrected on 2026-04-28)
• IK = InheritKit — Rust-wrapper SDK + commercial layer
• IW = InheritWills.com — will management hub (B2B + D2C)
• MFI = MyFamilyInherits.com — consumer estate-cataloguing brand
• LL = LegacyLists — collectibles cataloguing brand
• WIF = WillsInFaith — faith-tradition wills brand
• AE = ArrangedEstate — estate-administration brand (parked)

The IAS expansion (with “InheritKit” in the name) introduces InheritKit as a vocabulary item — flag this to Rich when reusing the pattern, since most pitch docs don’t otherwise reference InheritKit and the term may need standalone context.

Use canonical public terminology:

• Partner roles per openinherit.org/partners/ → Succession Law Partners / Tax Treatment Partners / Institutional Endorsers / Developer Partners
• Faith-tradition extensions per openinherit.org/extensions/ → Islamic (fara’id, wasiyyah, awl/radd) / Jewish (bechor, matanah, halachic will mechanisms) / Hindu (Mitakshara, Dayabhaga, 2005 amendment) / Africa Customary
• A solicitor who checks the public site sees consistent language — credibility multiplier

Mockup capture flow (the technically-tricky part):

1. Don’t edit code-mfi/mockups/public/*.html directly — copy chosen files to /tmp/<firm>-pitch-mockups/. Keeps source mockups generic.
2. Apply firm-specific replacements (sed) in /tmp.
3. Spin up local HTTP server at port 8765 in /tmp dir — Playwright file:// protocol is blocked, you need HTTP.
4. Use Playwright via MCP: browser_resize 1440x900, navigate, then browser_evaluate to remove .instruction dev-banners (every mockup has one) and any “INHERIT features powering this page” design-doc tables (mockup 13 has one), THEN screenshot full-page.
5. Use cache-busting query params (?v=2) when re-capturing after edits — Playwright caches aggressively.
6. Save PNGs to outreach/<firm>-mockups/.
7. Add .playwright-mcp/ to .gitignore — runtime artefacts that shouldn’t be committed.

Default 5 mockups for an MFI partner pitch:

• 28-homepage-hero-split — consumer entry
• 32-comparison-engine-grid — lead routing showing firm as recommended
• 35-backoffice-solicitor-clients — IAS firm-side surface (the killer mockup; “Referred via comparison engine” closes the loop)
• 58-dashboard-v3-new-tokens — consumer dashboard
• 13-item-page-inherit-deep — depth-of-data

Three firm-name corrections to apply per pitch:

• Firm-name placeholder (“MLP Law”, etc.) → actual firm trading name (often just the abbreviation, no suffix)
• “MFI BackOffice” → “IAS” (canonical name)
• idrlaw.myfamilyinherits.com → <firm-slug>.myfamilyinherits.com

Iteration discipline:

• Version bumps: 1.0 → 1.1 → 1.2 → 1.3 on each substantive change
• CHANGELOG entry per version
• Each revision is its own commit + push, with the standard verify-push step (local HEAD = remote HEAD before reporting done)

Pilot framing:

• Free pilot for first-cohort partners — Rich’s stance is it’s too early to charge firms
• Six-month working assumption (negotiable)
• Co-design partnership not vendor-customer
• Lead partner gets first-call routing on early MFI lead flow
• Wider partner ecosystem (succession + tax + faith partners per jurisdiction) flagged as longer-term direction, not pilot ask

Mockup branding gotcha: check the source HTML for firm-name placeholders BEFORE first capture. The MFI mockups were already “MLP Law”-branded (Rich’s prior groundwork) — when reused for a different firm, every mockup needs a global rename in /tmp first.

Pandoc + WeasyPrint pitfalls discovered 2026-04-28:

1. \newpage is LaTeX-only. Pandoc silently drops it in HTML output, so mockups that rely on it for page separation will pack onto the same page. Use HTML page-break divs instead:

   • In markdown: <div class="page-break"></div> between content blocks
   • In CSS: .page-break { page-break-after: always; break-after: page; }

2. Pandoc emits style="width:100%" inline on every image. Inline style wins CSS cascade. To override (e.g. to widen images so they bleed past prose margins for readability), use !important on width/margin/max-width rules:

   img {
     width: calc(100% + 30mm) !important;
     margin-left: -15mm !important;
     margin-right: -15mm !important;
     max-width: none !important;
     height: auto !important;
   }

   This bleeds images 15mm into each margin, giving ~18% wider rendering than 100% content width on a 20mm-margin A4 page.

3. Hide CHANGELOG from rendered PDF while keeping it in source for version history. Wrap in pandoc fenced div:

   ::: {.no-print}
   ## CHANGELOG
   - ...
   :::

   With matching CSS: .no-print { display: none !important; }. Source keeps audit trail; partner sees a clean closing page.

Verification trick: after PDF regeneration, render specific pages to PNG via pdftoppm -png -r 70 -f N -l N pdfpath /tmp/preview and Read the resulting image to visually confirm layout. Faster than opening the PDF, and the rendered image lands directly in the conversation for review.

Jurisdiction-vs-feature gotcha (caught 2026-04-28 by Rich on technical-supplement v1.0): features that exist in the INHERIT architecture are not necessarily lawful in the launch jurisdiction. Specifically, electronic execution of wills is NOT lawful in England & Wales — Wills Act 1837 §9 requires wet-ink signing in the simultaneous physical presence of two witnesses (T56 finding from 2026-04-26 round 7 research; Law Commission has consulted on reform but nothing is in force). When writing technical supplements that describe features like “audit trail / signing events / cryptographic execution,” check the launch-jurisdiction’s legal constraint FIRST and frame accordingly: the audit trail anchors evidence around the wet-ink act in E&W, it does not perform the act. Same caveat applies to other faith and secular Phase-1 jurisdictions where wet-ink is required. Always check feedback_stop_uk_drift_international_from_day_one_strict and the per-jurisdiction T-files before claiming a feature works “everywhere”.