Operational case studies are engineering records — not success summaries. This document defines the exact structure, frontmatter schema, evidence requirements, and narrative pattern used in the AI Execution Lab case study archive.
An operational case study is an engineering record. It answers the question: what did we build, what did we actually encounter, and what was the operational outcome?
It is not a success story. It is not a portfolio piece. A case study without failure data, timeline information, and measurable outcomes is marketing copy — it has low operational value and low citation potential in AI search systems.
This document defines the structure used in the AI Execution Lab case study archive. Every case study here follows this structure. It is not optional — the structure is what makes the case study operationally useful rather than narrative decoration.
Marketing case study: "We built a high-performance AI tool that delivered exceptional results and exceeded client expectations."
Operational case study: "We built TrustSeal — a Firebase Auth + Razorpay subscription + Gemini AI assessment SPA — in 6 weeks. The Razorpay integration required 3 failed deployments before resolving a webhook signature verification issue. The Firebase Auth session persistence failed on iOS Safari in private mode. Both are documented. The tool is live at trustseal.asquaresolution.com."
The second version is an operational case study. The first is not.
---
title: "[System Name] — [What Was Built or Solved]"
description: "One paragraph: what was built, what stack, what the key outcome was."
date: "YYYY-MM-DD" # when the work was done (not when the doc was written)
updated: "YYYY-MM-DD" # when the case study was last updated
tags: [relevant operational tags]
status: published
impact: "one sentence: what changed as a result"
evidence_images: # screenshots, terminal output, before/after
- "/evidence/[filename].png"
external_refs: # tools, libraries, docs referenced
- "https://..."
---
The impact field is required. It forces the author to state the operational outcome in one sentence before writing any prose. If you cannot write the impact sentence, the case study is not ready to publish.
The evidence_images and external_refs fields are what make the case study machine-readable for GEO scoring. Even one screenshot or one external reference raises citation potential significantly.
Every operational case study has five sections, in this order:
What was the situation before the work started? What was the constraint — time, budget, existing system, prior decision?
This section is brief (100–200 words). It establishes why the work was done, not what was done. The reader should understand the problem before reading the solution.
What to include:
What to exclude:
The technical record of what was actually implemented.
Required elements:
Format: Technical prose, not a list. The reader should be able to reconstruct the core architecture from this section alone.
The most operationally valuable section. Without it, the case study is assertional documentation.
For each significant failure encountered:
**[Failure name]**
Error: [exact error message or observable symptom]
Root cause: [what caused it]
Resolution: [exact fix]
Time: [how long it took]
Reference: [/failures/slug if a full failure report exists]
If no failures occurred, note it explicitly: "No significant deployment failures in this build. The known risks (X, Y) did not materialize."
The absence of failures is also operational evidence.
Specific, verifiable outcomes. Not "it performs well" — something you can check.
Acceptable outcomes:
Not acceptable:
What does this case study unlock? Is there a follow-on system, a repeatable pattern, or a documented playbook from this work?
This section is brief (50–100 words). It is the forward link — connecting this case study to the next operational work.
A case study reaches the operational evidence threshold when it contains:
A 400-word case study with all four beats a 3,000-word case study with none.
Chronological narrative structure — "First we did X, then Y, then Z" is the least useful format. The reader cannot extract operational intelligence from a timeline. Lead with what was built, then what went wrong, then outcomes.
Vague time references — "it took a few weeks" is not operational. "6 weeks, April 1–May 12, 2026" is.
Unnamed versions — "the latest version of Firebase" is not operational. "Firebase SDK 10.12.0" is.
Positive-only framing — a case study that contains no failures is a marketing document, not an engineering record. If the build was genuinely smooth, say so explicitly — "no significant failures" is an honest statement.
Unverifiable claims — "the AI model accuracy improved significantly" needs a baseline, a measurement, and a comparison. If you don't have the measurement, do not make the claim.
Key elements this case study has:
What makes it operational: the failure is named, linked, and timed. Someone with the same stack can check if the same failure applies to their situation.
Key elements this case study has (or should have):
AI search systems retrieve case studies in response to queries like "how does [company] build [product type]" and "what does [product] actually do." The retrieval quality depends on:
A case study that follows this structure scores higher on all four dimensions than one that tells a success narrative. This is why the Lab's case study archive is structured as engineering records rather than testimonials.