Case Study Builder
Turn one real outcome into trustworthy proof without upgrading partial evidence into a miracle story.
Job contract
- Owns: a publishable story about one customer or project.
- Does not own: cross-customer patterns (
customer-insight-synthesizer) or a general meeting analysis (meeting-miner).
- Finished deliverable: a case study, clearly labelled project story, or evidence plan, plus a claim ledger and approval checklist where relevant.
Evidence gate
Classify the evidence before drafting:
Full case study: the starting situation, intervention, and meaningful outcome are all supported by traceable evidence. Proceed with the requested case-study format.Project story: the work and process are supported, but the customer or business outcome is not. Produce a useful project story and state plainly that no outcome claim is being made.Evidence plan: the work, change, or outcome cannot yet be verified. Do not manufacture a narrative. Return the missing evidence and the smallest practical plan for collecting it.
Quotes, metrics, customer names, logos, and claims of approval remain blocked until their source or permission is verified.
Workflow
- Inventory the customer, starting situation, stakes, constraints, intervention, timeline, outcome, sources, permissions, and confidentiality needs.
- Separate verified facts, customer statements, user interpretation, and missing evidence.
- Run the evidence gate and tell the user which route the material supports.
- Find the real change. Prefer a specific credible result over an inflated transformation.
- Build the narrative: situation, tension, decision, work, result, meaning.
- Attribute quotes and numbers. Mark anything requiring customer approval.
- Produce the supported format: proof block, one-page story, sales-page section, full case study, project story, or evidence plan.
Output
# [Outcome-led title]
## At A Glance
[Customer, challenge, work, result]
## The Starting Point
[Specific context]
## What Changed
[Actions and mechanism]
## The Result
[Verified outcomes and limits]
## Why It Mattered
[Customer consequence]
## Claim Ledger
| Claim | Source | Status | Approval needed |
## Publication Checklist
[Name, logo, quote, metric, confidentiality approvals]
Guardrails
- Never invent or round up results, dates, quotes, titles, logos, or customer approval.
- An internal draft is not permission to publish.
- Anonymise only when requested and ensure the remaining detail cannot re-identify the customer.
1---2name: case-study-builder3description: Turn evidence about one customer, client, project, or outcome into a credible case study, success story, proof page, sales story, or short proof block.4---56# Case Study Builder78Turn one real outcome into trustworthy proof without upgrading partial evidence into a miracle story.910## Job contract1112- Owns: a publishable story about one customer or project.13- Does not own: cross-customer patterns (`customer-insight-synthesizer`) or a general meeting analysis (`meeting-miner`).14- Finished deliverable: a case study, clearly labelled project story, or evidence plan, plus a claim ledger and approval checklist where relevant.1516## Evidence gate1718Classify the evidence before drafting:1920- `Full case study`: the starting situation, intervention, and meaningful outcome are all supported by traceable evidence. Proceed with the requested case-study format.21- `Project story`: the work and process are supported, but the customer or business outcome is not. Produce a useful project story and state plainly that no outcome claim is being made.22- `Evidence plan`: the work, change, or outcome cannot yet be verified. Do not manufacture a narrative. Return the missing evidence and the smallest practical plan for collecting it.2324Quotes, metrics, customer names, logos, and claims of approval remain blocked until their source or permission is verified.2526## Workflow27281. Inventory the customer, starting situation, stakes, constraints, intervention, timeline, outcome, sources, permissions, and confidentiality needs.292. Separate verified facts, customer statements, user interpretation, and missing evidence.303. Run the evidence gate and tell the user which route the material supports.314. Find the real change. Prefer a specific credible result over an inflated transformation.325. Build the narrative: situation, tension, decision, work, result, meaning.336. Attribute quotes and numbers. Mark anything requiring customer approval.347. Produce the supported format: proof block, one-page story, sales-page section, full case study, project story, or evidence plan.3536## Output3738```markdown39# [Outcome-led title]4041## At A Glance42[Customer, challenge, work, result]4344## The Starting Point45[Specific context]4647## What Changed48[Actions and mechanism]4950## The Result51[Verified outcomes and limits]5253## Why It Mattered54[Customer consequence]5556## Claim Ledger57| Claim | Source | Status | Approval needed |5859## Publication Checklist60[Name, logo, quote, metric, confidentiality approvals]61```6263## Guardrails6465- Never invent or round up results, dates, quotes, titles, logos, or customer approval.66- An internal draft is not permission to publish.67- Anonymise only when requested and ensure the remaining detail cannot re-identify the customer.
nahiddotai