00 — START HERE: Case Study Kit

Setup and orientation for the Case Study Kit. Read this first to understand what it produces, when to run it, and the rules that apply to every run.

What This Is

The Case Study Kit takes the raw material of one extraction interview (transcript or completed extraction template) and produces a publishable case studies asset for a practice owner's website — built around a documented client outcome they've never written up.

A case study (in this kit) is a third-person narrative — never a testimonial. It tells the client's story in the practice owner's voice, with traceable numbers and specific actions, structured to work as conversion proof on the practice owner's website.

This kit is a core Authority OS deliverable — the OS focused on conversion-focused web presence that positions the practice owner as the expert. Per advisoryos.ai: "Conversion-focused web presence that positions you as the expert—not a vendor in a sea of vendors." Case studies are the proof asset Authority OS deploys.

Audience: Practice owners (CPAs, financial advisors, attorneys, consultants, insurance professionals). The output goes on their website, in their brand, in front of their prospects.

Format:

• Two HTML files (V1 named with full detail, V2 anonymized)
• One markdown delivery doc (email + content for the practice owner to review)

Lifecycle: One-shot per extraction. Each run produces a complete asset set. New cases trigger new runs, not edits to existing files.

What It Produces

Every Mode 1 run produces exactly three files, named:

[client-first-last]-case-studies-v1-approval-required.html
[client-first-last]-case-studies-v2-anonymized.html
[client-first-last]-case-study-delivery.md

Example:

rob-foncannon-case-studies-v1-approval-required.html
rob-foncannon-case-studies-v2-anonymized.html
rob-foncannon-case-study-delivery.md

Where [client-first-last] refers to the practice owner Kathryn is producing the asset for — not the practice owner's individual clients featured in the case studies.

Each HTML file can contain one or more case study cards (stories) within a single page. The Foncannon golden examples each contain two stories. The number of stories per output is set by the extraction.

Operating Modes

Mode 1 — Create

When triggered: a completed extraction exists. Either:

• A filled-out case-study-extraction-template.html (preferred — the structured intake), OR
• A raw interview transcript (the kit will extract from it before generating)

Required inputs (full list in 01-case-study-context.md):

• Extraction output OR raw transcript + client card + design system
• Profession type (cpa / ea / cfp / ria / insurance / attorney / general)
• Brand colors (primary, secondary, accent) — pulled from the practice owner's design system
• Brand fonts (heading, body) — pulled from the practice owner's design system
• CTA destination URL
• Number of stories
• Convertri hosting flag (yes/no — affects technical compliance rules)

What it produces: the three files above, written to the production directory.

Confirm understanding before executing. Before producing, restate to Kathryn: "Here's the practice owner, the profession type, the story count, the brand source, the Convertri flag, and the disclaimer template I'm applying. Does this match your intent?" Wait for confirmation. Do not proceed on silence.

Mode 2 — Improve This Kit

The self-improvement loop. After running the kit:

1. Did Kathryn edit the output by hand? → Update the relevant golden example (03a / 03b / 03c) + the output skill (05) so the next run produces it that way.
2. Did QC miss something Kathryn caught? → Add the check to 04-case-study-quality.md and add a row to the Common Failure Modes table.
3. Should the kit do something it doesn't? → Update 05-case-study-output-skill.md.

The rule: Every manual fix becomes a kit fix. If you fixed it by hand, fix the kit so you never fix it by hand again.

What This Does NOT Do

• Does not conduct the extraction interview. The interview is a separate upstream activity; the kit consumes the transcript or extraction template. The Proof Gap briefing (advisory-os-vault/content/business/marketing/campaigns/proof-gap/proof-gap-briefing-script-v3.md) is the published methodology for how the interview is conducted — the four trigger questions, the Three Layers (Surface / Real / Prospect), what owners skip when self-extracting. Reference it for the upstream context, but the kit itself starts when the transcript exists.
• Does not produce testimonials. Case studies are third-person narratives. They tell the story; they do not quote the featured client saying things. Quotes in the body of a case study are forbidden — they're a testimonial format, and creating "quotes" the featured client didn't actually say is fabrication.
• Does not invent numbers. Every dollar figure, percentage, and timeline must be traceable to the extraction. If a number isn't in the extraction, it doesn't appear in the case study. Use ranges ("$58–60K") when the extraction is uncertain; use "projected" or "estimated" for forward-looking figures.
• Does not pitch Advisory OS in the delivery email. The delivery email connects to the practice owner's language, mentions the V1/V2 versions, opens the door to an Advisory OS conversation — and stops there. No pricing, no proposal language, no standalone offer to build the web asset (the build is part of the engagement, not a separate offer).
• Does not skip the anonymization test. Every V2 must pass: Could the featured client identify themselves in this version? If yes, anonymize further. Industry archetypes, generic strategy names, removed locations — never the actual client's signature.
• Does not use AOS brand colors when the practice owner has their own. The practice owner's design system is the source of truth. AOS defaults (charcoal/cream/gold + Cormorant Garamond + Inter) are the fallback only when no client design system is provided.
• Does not produce internal advisor reference arcs. That used to be this kit's job — it isn't anymore. Internal narrative arcs of Kathryn's own engagements live separately at business-aos/reference/proof/case-studies/ (e.g., sync-tax-arc.md); they are advisor-only context, not client-facing assets.

Critical Rule

The output is the practice owner's document. Every word, every section, every design choice must pass this test: "Would this make the practice owner's prospects pick up the phone?" If the answer is no — if the language is corporate, the numbers are vague, the strategy names sound like brochure copy, or the V2 still feels traceable to the featured client — the case study isn't ready.

The Proof Gap article names the failure mode this kit prevents: the invisible no. "You hear every yes. You hear some no's. You never hear: 'I looked, couldn't find proof, and moved on.'" Every case study this kit produces exists to close the gap that creates the invisible no.

File Inventory

Total: 8 files. The split goldens (03a / 03b / 03c) are required because V1, V2, and delivery have different rules and produce different file types — combining them would muddy the production logic.

Relationship to Other Kits and Docs

File Location

advisory-os-vault/content/frameworks/kit-case-study/
    00-case-study-start-here.md                              (this file)
    01-case-study-context.md
    02-case-study-terminology.md
    03a-case-study-golden-example-v1-named.html
    03b-case-study-golden-example-v2-anonymized.html
    03c-case-study-golden-example-delivery.md
    04-case-study-quality.md
    05-case-study-output-skill.md

Output produced by the kit lands in the practice owner's project directory (or wherever Kathryn is running the production session); the kit itself does not prescribe a fixed output path.

Change Log

2026-04-27: Initial build via kit-builder Mode 1. Replaces deprecated kit-case-study (deleted same day) which was built around a 4-master copywriting spine and a wrong-layer "framework hooks" list. New kit is built around the actual Proof Engine product Kathryn published — V1 named HTML / V2 anonymized HTML / delivery MD — with The Proof Gap briefing as upstream methodology and Authority OS as the parent capability.