01 — CONTEXT: Case Study Kit

Input definitions, validation rules, gap protocol, reference data routing, and what each mode requires.

Mode 1 Inputs — Create

Validation Rules — Mode 1

1. No production without confirmed profession type. Disclaimer selection cascades from this. Ambiguous values block the run.
2. No production with [NOT SET] values in the extraction. If the extraction template has unfilled fields, halt and request completion.
3. No production without a CTA URL. The output is conversion-focused; without a destination, the page has no job. Ask for it; never invent one.
4. No production without a Convertri flag. Default is to ask; never assume. Convertri rules are non-negotiable when applicable, and applying them when not needed unnecessarily restricts the output.
5. Brand source must be confirmed. Either the practice owner's website / design system was extracted (preferred), or AOS defaults are explicitly chosen. Never silently apply AOS defaults if the practice owner has their own brand.
6. Story count must match extraction content. If the extraction has 2 stories, produce 2 case study cards. Do not pad with invented additional stories. Do not collapse two stories into one.
7. Numbers in the case study must match numbers in the extraction. Verbatim. If the extraction says "$58–60K," the output says "$58–60K." If a number isn't sourced in the extraction, it doesn't appear.
8. Anonymization posture is confirmed via the table, not invented. V2 transformations follow the Anonymization Table in 02-case-study-terminology.md. New mappings (when a profession or strategy isn't covered) get added to the table during the run and Mode-2'd back into the kit.

Mode 2 Inputs — Improve This Kit

Validation Rules — Mode 2

1. Always read the current kit files before making changes. Never update blindly.
2. Changes propagate. A golden-example change usually requires output skill and quality checklist updates too.
3. Never remove a quality check without a documented reason. Quality checks accumulate — each one represents a lesson learned.
4. Document what changed and why. Append to each file's ## Change Log (markdown) or comment block (HTML).
5. Golden examples are replaced, not edited. When V1 / V2 / delivery improve, the new versions replace 03a / 03b / 03c. Old versions stay accessible via git history, not as kit files.
6. Anonymization Table additions require a sanity check. When adding a new mapping (e.g., a new profession archetype), verify it doesn't accidentally identify the featured client. Run the anonymization test before locking the new entry.

Input Priority Hierarchy

When inputs conflict or are ambiguous:

1. Practice owner's design system wins for visual/brand decisions. AOS defaults only when nothing is provided.
2. Extraction template wins over transcript for structured data (numbers, strategy names, timelines). Transcript wins for voice patterns and direct phrasing the practice owner uses.
3. Practice owner's verbal direction wins over any document — they are the authority on their own client's story.
4. AOS voice (business-aos/reference/core/voice.md) wins over any other tonal reference. Banned words apply regardless of what the practice owner's brand allows.
5. Convertri compliance wins over visual flexibility when Convertri is the host. CSS variables, mailto links, and separate scripts are forbidden — non-negotiable.
6. The anonymization test wins over any V1/V2 mapping. If the test fails, anonymize further even if no current mapping covers it (and Mode-2 the new mapping back into the table).

Reference Data Routing

The kit pulls from business-aos/reference/ per the Offer Page kit precedent. Load what each step needs.

Core (load before writing any copy)

Brand QC (mandatory gate before delivery)

Visual fallback (load only when no practice-owner design system provided)

Historical reference (read once for context, not per run)

Content Filtering — V1 vs. V2 (Audience Boundary)

This kit transforms one extraction into two parallel deliverables with different audiences:

V1 outputs are pre-publication artifacts. They go to the practice owner for review and to the featured client for approval. Only after written approval does V1 publish.

V2 outputs are publishable on day one. The anonymization test (Could the featured client identify themselves?) is the gate — V2 ships only when the answer is no.

Both versions are produced from the same extraction in the same run. They are not two separate runs. The Anonymization Table in 02-case-study-terminology.md is the canonical mapping between the two.

Gap Protocol

A gap is a required input that is missing or unverified. Gaps are flagged, never filled with assumptions.

Blocking gaps (production halts):

• Profession type not specified (cannot select disclaimer)
• Extraction has [NOT SET] values (cannot produce sourced narrative)
• CTA URL missing (cannot produce conversion path)
• Convertri hosting flag missing (cannot select compliance rules)
• Brand source missing AND no AOS-default explicit choice (cannot style the page)
• Numbers in the extraction don't reconcile (e.g., savings amount conflicts with results table) — halt and confirm before producing

Non-blocking gaps (proceed with flag):

• Team member name not provided → omit team member FAQ; flag in delivery doc
• Story count >3 → produce all but flag length warning (long pages reduce conversion)
• Industry archetype not in Anonymization Table → propose a new mapping during the run; flag for Mode-2 add to the table

Surfacing gaps:

When a gap is detected, the kit must:

1. Identify which file or section cannot be fully produced
2. State the missing input specifically
3. Suggest where to get it (practice owner / extraction template / AOS defaults)
4. Halt the affected section until resolved (for blocking) or proceed with [GAP: reason] inline annotation (for non-blocking)

Pre-Build Validation Gate

Before writing any output file, verify all of the following are true:

1. Profession type set to a valid value
2. Extraction is complete (no [NOT SET]) OR transcript is provided with all data needed
3. CTA URL provided
4. Convertri flag set explicitly
5. Brand source confirmed (practice-owner system extracted OR AOS-default chosen)
6. Story count matches extraction
7. Numbers reconcile across extraction sections
8. Disclaimer template selected (matches profession type)

If any of the eight is false, halt. Surface the gap. Do not start production.

Change Log

2026-04-27: Initial build via kit-builder Mode 1. Inputs and validation rules derived from case-study-agent.md (Proof Engine project) and the V1/V2 Foncannon goldens. Gap protocol and pre-build gate adapted from kit-blueprint and kit-project-plan precedent. Reference data routing modeled on kit-offer-page.