# How to make strategy case studies

Explain why customers chose or rejected the company, whether those choices built a substantial business, and what sustained or undermined it. Choose the few causes that explain the most. A reader should finish able to explain what mattered, in ordinary language, without knowing our taxonomy.

Each study must explain the company's outcome at least as convincingly as the strongest relevant analysis found through a thorough search. Aim to improve on those accounts through broader evidence, better comparison of explanations and synthesis across strategic mechanisms. Research broadly across sources and the full taxonomy, then publish the few explanations that carry the most weight. More sources, tags or words do not establish better analysis. The final review must identify what this study adds and where another account remains stronger.

## 1. Define the outcome

Name the business, period, geography and relevant alternatives. Define the outcome being explained: adoption in a segment, profitable growth, category leadership or another observable result. Revenue, valuation and customer success are different outcomes. If the company lost ground or won only in part of its business, say so.

Separate materially different businesses. Microsoft Office cannot establish an Azure moat. Choose competitors customers actually considered at the time, including doing the job manually or buying nothing. Record the historical endpoint and evidence cutoff.

### Record the company outcome for admin review

Follow Company outcomes (admin research policy) and its versioned data contract. The labels are Won, Partial win, Limited outcome, Lost and Too early to call. Missing research stays Unassessed; an operating company without an exit is not automatically Lost. Record the current outcome, historical milestones and operating status separately, with dated sources, scope, rationale and review status. Existing studies require an evidence review before receiving labels. For public companies verify a recent dated closing market cap, including values below $500 million. For acquisitions, attempt a sourced equity estimate with explicit bounds before leaving the tier unresolved. For failed businesses with a surviving brand, check the distressed-disposal rule and verify transaction scope. Preserve the sources and uncertainty for each decision.

Apply success-oriented guidance below to the outcome being explained. A failed or ongoing business still needs a customer-choice account, competing explanations and a clear causal argument. Investigate rejected offers, reversals and unsustainable economics where relevant; do not invent a growth or moat story to fill the template. Preserve supported strategy mechanisms even when the company failed. Outcome labels stay in admin data while the public presentation is undecided.

### Assign industry membership

Once the study's business scopes are final, review the [industry collections](../../data/industries.json). Add the company ID to every collection whose stated scope covers a business in the study. Each membership value must exactly match a string in the study's `businesses` list. A company may belong to more than one industry, and each membership applies only to the named businesses rather than the whole company.

Do not infer industry membership from taxonomy tags or stretch an existing collection to make a study fit. If no collection applies, resolve whether the industry set needs a new collection before delivery. Rebuild the admin and run `python3 brands/strategy/build/check_industries_admin.py --counts-only`; the check fails while any current study remains unassigned.

### Explain partial wins and setbacks

Use “What shaped the outcome” for the causal section across current reading pages and admin inventories. Keep successful adoption, unsuccessful expansion, recovery and company-scale milestones separate. A partial win can contain effective mechanisms and costly choices. A successful exit cannot establish that all tagged approaches worked.

New studies and substantive revisions use `explanation_version: 1` and a `contribution` on each claim: `effect` (`positive`, `negative`, `mixed` or `unresolved`), a named `outcome`, `period_start`, `period_end`, `basis` and `sources`. Business scope, comparator and confidence remain in the argument record. Split claims when different periods or mechanisms require different effects; never average them into a company-wide success score. A missing contribution on legacy records means unassessed, not positive or absent.

Keep supported mechanisms in failures and partial wins. The effect describes contribution to the scoped result; evidence strength describes how well the mechanism is supported. Apply each concept's actual requirements: observed rejection can explain a setback, but does not establish a delivered-product benefit or a network effect. The stable diagnostic key `winning_mechanism` now asks for a contribution to results and remains readable in dated ledgers. Do not loosen a moat's benefit-and-barrier requirements to populate a failed-company template.

Industry rankings count tagged mechanisms across all company outcomes. Their downloads retain claim contributions and separate effect counts, including unassessed legacy records. A company can appear in several effect counts for one tag; those counts are not additive or success rates. Company labels remain admin-only and require their own evidence assessment.

### Write the entry situation from the customer's side

Open every study with a short section describing what a prospective customer faced before this company existed. Give a scope line naming the industry, geography, customer and year, then two to four sentences on what that customer could and could not do: what the job cost them, what the available options required, and what they settled for when none of the options fit.

The company does not appear in this section. Not by name, not as "the alternatives before X", not as an implied solution waiting to arrive. A reader who skipped the title should not be able to tell which company the study is about.

Anchor the year on the company's entry into the business being explained, which may differ from its founding date. Netflix's streaming study opens on what a US household faced in 2007, not on the 1997 DVD business. Inherited assets can explain later arguments; they are not the situation a prospective streaming customer was in.

Begin with the customer’s experience and include external conditions that materially shape the offer, participation or economics, such as essential suppliers, regulatory constraints or an enabling technology shift. Name the mechanism instead of adding general industry background. Do not state a condition that only makes sense as a setup for the company’s move. "The market was ready for a simpler product" is a claim about the company, written backwards.

Every claim must have been true at or before the entry year, and must be supported. Prefer material from the entry period. A later account may document an earlier condition, but a later market share, price or competitive lineup cannot establish what a customer faced at entry. Cite sources in the section as other sections do. Record the attribution -- documented company judgment, participant recollection or our reconstruction -- and the limits of the claim in `EDITORIAL_REVIEW.md`, not on the page.

Use one Arena at Entry section per study. Separate business entries only when the study explains materially different businesses, as in the approved Adobe, Amazon and Veeva entries. Ordinary expansion, an acquisition or a new geography does not create another entry situation. Later structural changes belong in the dated timeline or the argument they explain. Spotify’s 2019 podcast move does not rewrite what a music listener faced in 2008.

Do not pair the situation with a company response. The response is the first "What shaped the outcome" argument, where the evidence for it already sits.

Arena uses fourteen condition tags in four browsing groups:

| Group | Tags |
| --- | --- |
| Customer needs and access | Barriers to participation; Specialist requirements; Overserved customers |
| Existing solutions | High setup and upkeep costs; Disconnected workflows; Entrenched systems |
| Market structure | Information asymmetry; Limited local selection; Scattered supply; Essential supplier control; Regulatory constraints; Regulatory shift |
| Technology shifts | Enabling technology shift; Changing technical requirements |

The groups are navigation, not company tags. Use two or three supported tags where useful; fewer is appropriate when the paragraph establishes only one condition. Keep business, geography and entry date as scope fields. Tag a specific observed condition, not overall attractiveness, generic dissatisfaction or the company's response. Barriers to participation includes the narrower case of nonconsumption; do not add Underserved as a duplicate. Disconnected workflows does not prescribe a product architecture. Overservice requires unnecessary capability or complexity for a defined customer, not merely a lower-priced entrant. Scattered supply means the options already exist but are spread across many sources with no shared place to find or compare them; it is not unequal knowledge about quality (Information asymmetry) or inventory limited by location (Limited local selection). Regulatory shift is a dated rule change that creates demand, a market or required work; a standing rule that limits participation or the offer is Regulatory constraints, and both can apply.

**Tagging the Arena paragraph is a required step, not a carry-over** (Dave, Oct 2, 2026; tightened Oct 5). After the paragraph is final, test it against every Arena tag's classifier predicates in `data/taxonomy.json` and record each condition the paragraph describes, primary condition first. Do this even when rewriting an older study: tags from a predecessor are a starting point, not the answer. It applies to every study, whatever renders it: the `arena` record in `study.json` for a batch page and the `arena` block of `data/case-study-v4/<id>.json` for an authored page.

How to judge a tag:
- **Read the predicates as a definition, not an evidence gate.** Ask whether the cited paragraph describes that condition for the named customer and year. If it does, tag it. Tagging is how incidence and winner gaps get measured (Dave, Sept 28: "we won't know if it's a non-winner unless we have incidence data"), and no tag is gated (Sept 29).
- **A missing source is research to do, not a reason to withhold.** If a predicate needs a fact the paragraph doesn't yet carry (a date, an observed refusal), add the sourced sentence or tag what the paragraph already shows. "The record does not establish every predicate" is never an `untagged_reason`, and the build rejects reasons worded as evidence gaps.
- **Don't misread a predicate as excluding its own textbook case.** Many separate listing sites *is* Scattered supply; a predecessor directory existing doesn't fail "no gathering point" unless one source was already widely used for the whole market.
- **One to three tags is the default**, more when each is distinct and described.
- **`untagged_reason` is only for a condition no current tag names.** Name the condition and the tag you propose (section 6), and tell Dave in the same session. "Pending decision" reasons stay until he decides.

To change tags on an existing batch page without editing its dated `study.json`, add a `kind: "arena"` placement to `data/teardown-tag-updates.json` (`record: "arena"`, `before`, `after`, `reason`; an empty `after` also needs `untagged_reason`). The build fails on any rendered Arena paragraph, authored or not, that has neither tags nor a reason (`build/case_study_v4.py`, `check_arena_tags`; test `build/test_v4_arena_tags.py`). History: 55 authored pages shipped untagged in September 2026 because the brief only copied tags forward (`claude/strategy/arena-untagged-review-20261002.md`); 31 batch pages shipped untagged in October because the check covered only authored pages and batch reviews treated predicates as an evidence gate (`claude/strategy/arena-tag-audit-20261005.md`).

The approved September 14 entry revision lives in `data/arena-entries.json`. It supplies 31 business-scoped paragraphs across 28 companies; Adobe, Amazon and Veeva have two distinct business entries within one section. Preserve these approved scopes when editing. The shared selector applies the reviewed paragraphs before public rendering, concept links and admin inventories. New company revisions require renewed entry review; a stale source batch fails the build. Dated research and original entry-response assessments remain available as historical evidence.

When selecting a paired comparison, save it immediately in the core company-pairing registry (`data/COMPANY_PAIRINGS.md`). Record the relevant business and whether the companies are direct competitors, adjacent alternatives or a broader mechanism contrast. Preserve older pairings and later qualifications; assess company outcomes separately.

## 2. Research the explanation

Start with a provisional account of the company's outcome and the questions that could overturn it. Follow the [source policy](TEARDOWN_SOURCE_POLICY.md). Collect factual evidence alongside serious attempts to explain the business.

| Source | What to look for |
| --- | --- |
| Founder and early employee interviews, letters and oral histories | First customers, rejected ideas, constraints, surprising behavior and changes of plan |
| Early customers, procurement and migration accounts | What they used before, why they bought, what improved and what disappointed |
| IPO filings, annual reports and earnings materials across transitions | Adoption, economics, allocation, risks and failed initiatives, by business |
| Technical documentation and dated product announcements | The design decisions behind the customer benefit; evidence of use must come separately |
| Competitors, regulators and courts | Rival responses, substitutes, access restrictions and evidence against the story; distinguish allegations from findings |
| Strategic analyses, company histories and VC websites | Competing explanations of what mattered, including product and distribution choices that filings barely discuss |

### Save each source's text when you first read it

Save the main text of every source the first time it is read, and quote evidence from that saved text; see [saved source text](TEARDOWN_PRODUCTION.md#saved-source-text) for the capture paths. Classifier rules keep getting stricter, and each new check asks something the original notes didn't record. A saved source can answer it later without another trip to the web; a paraphrase cannot. Record a paywall, challenge or removed page as an access limit instead of summarizing a page that wasn't read.

### Keep a broad company record of product and go-to-market choices

Before selecting the few explanations for the reading page, log the company's concrete product and go-to-market choices as facts. This company-level record is a required research deliverable, including for unsuccessful companies. Keep choices that worked, failed, were reversed, or have no measured effect. A fact does not need to explain the outcome or qualify for a taxonomy tag to belong in the record.

Research both categories across entry, expansion and material reversals. As a breadth target, seek about 10 to 20 distinct product choices and 10 to 20 distinct go-to-market choices per company when the record supports them. These are research targets, not acceptance quotas: record genuine gaps rather than inventing facts, splitting one choice into cosmetic variants or treating silence as evidence of absence. A concise public narrative is not a reason to discard the underlying choices.

- Product choices include the initial customer job, features included or deliberately omitted, architecture and deployment, integrations and APIs, supported platforms, onboarding and configuration, workflow boundaries, reliability and control options, self-service versus assisted use, and subsequent launches, acquisitions, migrations or retirements. Describe what customers could actually use, distinguishing an announcement from availability and observed use.
- Go-to-market choices include target buyers and users, positioning, packaging and pricing, trials and free access, conversion paths, sales motions, agent or reseller incentives, acquisition channels, partnerships, marketplaces, content and community programs, implementation, account expansion, and changes in segment or geography. Record the chosen route separately from claims about its effectiveness.

Every fact needs a stable ID, company ID, business scope, category, dated observation or event window, a precise statement, and source IDs with passage locators and disclosure dates. Record whether it is a documented action, a participant's account of a decision, or a company-described offering. An analyst's inferred choice belongs in interpretation, not as an observed fact. Use an observation date for undated current documentation; do not backdate it to launch. Record stated intent and rejected alternatives only when a source supports them.

Keep these records independently accessible in structured company data and a readable companion. Link facts to arguments and timeline events where useful, but do not limit the inventory to the facts those arguments use. Preserve discontinued choices and date later replacements. Separate existence of a choice, evidence of customer response, and our explanation of its contribution to the outcome. For paired studies, use the same coverage checklist for both companies and record whether each area is documented, investigated but unresolved, or outside scope.

The final review must report product and go-to-market fact counts, period coverage, source concentration and material gaps. Check a sample of unused facts as well as facts cited by the thesis. Follow the company-fact contract in [the production reference](TEARDOWN_PRODUCTION.md#company-level-choice-facts).

### Find and compare the strongest analytical accounts

Before settling the thesis, search broadly for company-specific essays, investment memos, founder and operator interviews, customer accounts and industry specialists. Include analyses of relevant competitors and unsuccessful approaches. Search sources such as Stratechery, Acquired and VC websites, including firms beyond the named list. The source policy supplies starting points; assess other relevant publications on the quality of the particular work. Follow citations, interviews and disagreements to further sources.

Keep a search record in `EDITORIAL_REVIEW.md`: queries and publication archives checked, promising leads followed, material access gaps and the reason for stopping. Seek every substantive account likely to improve or challenge the explanation. There is no target source count or ceiling of two comparison pieces. Continue while new material supplies consequential mechanisms, contrary evidence or observations that could change the account. Stop when the major explanations and credible alternatives have been investigated and further targeted searches repeat material already assessed. An inaccessible source remains an access gap, not evidence that the search is complete.

For each substantive piece, record its author, title, date, URL and relevant passage or timestamp, then answer:

- What is its central explanation, and what evidence does the most work?
- What does it explain particularly well, and what does it overlook or get wrong?
- What will our study adopt, challenge or add, and where will that appear?

Record commercial relationships and whether accounts share the same underlying evidence. Repeated versions of one founder story remain one account. A bibliography entry does not count as a comparison. Never imply that a paywalled article, case study or transcript was read when only a snippet was available. Collecting additional company announcements cannot substitute for examining strong outside analysis.

### First-person testimony is the primary source for decisions

Weigh a source by what the speaker had access to, not by what kind of source it is. On what a person decided, what they chose against, what they were refused, what they were trying to do and what constrained them, a participant is the best evidence that will ever exist. No filing, analyst note or outside history has better access to it. Where a participant speaks from direct experience, treat the account as supported and say so plainly; the absence of outside corroboration is not a reason to downgrade it, because there is no outside source better placed to corroborate.

Record the access that carries the weight: who the person was, what role they held, when, and how they came to know the thing they are describing. A former executive of the incumbent explaining why that incumbent declined to respond is testifying about a company he ran; treat that as strong. The same person characterising a rival he never worked inside is speculating; treat that as weak. Access, not affiliation, is the test.

This standing covers decisions and internal constraints. It does not extend to:

- **Outcomes and magnitudes.** How many customers responded, how fast, how much of the growth a choice produced. A founder saying customers loved it is not evidence that they did.
- **Causal attribution of the company's own success.** "This is why we won" is authoritative about what the founder believes and intends to have done, and it is the right starting hypothesis; it is not a finding until something connects the choice to the result.
- **A competitive barrier.** Whether a rival *could* have matched the move is a claim about the rival. Testimony can establish the mechanism; the barrier needs its own evidence.

So a participant account alone can carry an Intent tag, an Operating Model tag, a Product decision tag and the narrative of what happened and why. It can carry an Advantage tag where the advantage turns on the company's own choices and the speaker's own knowledge of them, with the barrier's status stated. It cannot by itself establish adoption, market share or a proven moat.

Retrospection is a real limit and a bounded one. Recollection of what someone did and why is far more durable than recollection of dates, sequences and figures, so date events from the record and take the reasoning from the person. Where the speaker signals their own uncertainty, follow them and say so. Where a later account conflicts with a contemporaneous document on a fact, the document wins on the fact without discrediting the account's reasoning.

### Trace how each strategy and moat was built

Filings and later results describe a strategy or moat after it exists. They rarely say what the company did to build it. For every product strategy, go-to-market strategy and advantage the study relies on, collect accounts from people who were there: founders, early employees and board members or early investors. Record the actions that produced it.

1. **List the targets.** Take each material product and go-to-market mechanism and each advantage in the current or predecessor study. For each one, write the question "What did the company do, before it had this, that produced it?"
2. **Search for participants, not summaries.** Before going to the web, search the saved text of the existing study's sources for each target (`source_text.py find`): investor memos and early founder interviews often already hold dated actions and declined alternatives that the earlier study summarized away. Then search "how did <company> build <mechanism>", "what did <company> do before <mechanism>", "<company> early days", "<company> first employee", "<company> oral history" and "<company> launch playbook". Also search the names of founders, early operators (first sales, growth, city-launch or community hires) and board members. Useful venues are long-form interviews (Acquired, How I Built This, Invest Like the Best, 20VC, Lenny's, First Round Review, Masters of Scale, SaaStr), board members' and investors' own blogs and memos, oral histories, and company engineering or launch posts from the period. Also search contemporaneous trade reports (TechCrunch, Fortune, trade press) of each launch: for later mechanisms they are often the only dated record, and a participant quoted in them counts as a participant source. For podcasts, check public transcript archives (for example the lennys-podcast-transcripts repository on GitHub) before treating an episode as unreadable. Early employees' own history newsletters or blogs about the company date the founding weeks and name design alternatives that founders' interviews skip. When founders wrote a technical paper or engineering essays about the product, read the lessons-learned and related-work sections first: they name the rejected alternatives and the rivals the design answered. When a fetch returns an empty page for a known interview or transcript, open it in the browser before recording it as unreadable; script-rendered pages often read fully there. Board members' and lead investors' IPO-day essays often explain a pricing or go-to-market decision in their own words.
3. **Write the build chain.** For each target, record 3 to 7 dated actions before onset. Each action needs the lever used, how it produced the mechanism, the source and the speaker's access (role, when they joined, how they knew). Where a participant names the alternative the company turned down (Airbnb declining to buy Wimdu, for example), record it: Intent and Operating Model tags need a declined alternative, and investors' own podcast and essay series (such as Sequoia's Crucible Moments) and early employees' first-person essays are where it most often appears. Date actions from contemporaneous records where they exist, and take the reasons from the participant. Date contract terms (exclusivity, non-competes, minimum commitments) from the filing or document that first discloses them, not from the partnership announcement: leads often merge an alliance's launch with a later amendment.
4. **Tag the action, not the result.** A tag that names a lever goes on the event or argument where the lever was pulled (for example, Cold Start on the supply subsidy or seeding campaign), not on the claim that the network later worked.
5. **Reset onset from the chain.** A material advantage needs at least two dated building events at or before its onset, with a participant source where one exists. If the search finds none, record the gap in the review instead of leaving a vague onset. If the existing study's period starts after the company's founding, check whether the moat's first building events fall before it; if they do, extend the scope to the earlier business under its own business label rather than treating it as background.
6. **Keep the limits of testimony.** A participant establishes what was done and why. The barrier, the magnitude and the outcome still need their own evidence (see above).

### Credit analytical contributions

Classify each passage by its contribution. A filing may establish reported results; a participant may explain a decision; an outside analyst may supply the interpretation that makes those facts intelligible. A single source can do more than one of these jobs. The distinction between primary and secondary sources is not a ranking of analytical value.

Credit a borrowed explanation near its use in the public prose and link the specific work. Explain the contribution: for example, name the analyst whose distinction between two business models informs the argument. Separate that interpretation from our extension, disagreement or later corroboration. Keep the attribution in the source record too. Do not replace credit to an analyst with a citation only to the company documents they used. Check the factual premises while preserving the origin of the reasoning. Attribute participant explanations of their own success as their account and test the connection to outcomes.

## 3. Choose the few reasons that mattered most

Before outlining the page, compare a short list of plausible explanations in plain language. Consider more candidates than the page will contain, including consequential market growth, inherited assets, capital availability and competitor mistakes. Keep the list open as research changes the story; the first compelling sources should not determine the outline. Assign tags after selecting the explanations. Four or five final reasons is a useful target, not a quota. A request to add sources or tags does not imply adding reasons.

Use this sequence and retain a compact record in `EDITORIAL_REVIEW.md`:

1. Define the outcome, customer group, business and period each explanation concerns.
2. Assemble candidates from the source comparison and a deliberate scan of all six taxonomy layers. Record a consequential mechanism even if the taxonomy lacks a suitable tag; follow the existing proposal procedure before adding one.
3. Trace each candidate from a choice or condition, through customer behavior or an economic effect, to the outcome. Attach evidence and identify the weakest consequential link.
4. Compare candidates using observations that distinguish them, including customer migrations, rival responses, failures and changes across periods or customer groups.
5. Identify dependencies and overlap, then select the leading explanations. Record their importance separately from confidence and explain why alternatives receive less weight.

The layer scan broadens the search for explanatory fit. It does not require a reason or tag from every layer in the finished page.

### Assess importance and confidence separately

For each candidate, record the outcome, customer group and period it explains. Assess its importance: how much of the trajectory does it plausibly account for, and what would be difficult to explain without it? Separately assess confidence: what evidence connects the mechanism to customer behavior or business economics, and which links remain uncertain?

A well-documented feature may explain little of the company's success. A potentially decisive cause with weak evidence deserves further research. Source count, ease of measurement and taxonomy coverage do not establish importance. Use reasoned comparisons without numerical scores or invented percentages of growth.

Separate four questions during research: why customers first bought, how the company won more customers, how existing accounts grew, and what made the business hard to displace. They need not become four separate blocks. For an early win, connect the customer's situation, the company's choice, the benefit over the available alternative, and evidence that customers responded. A useful product or effective sales approach can explain adoption before a durable moat exists. For a later defense, identify what constrained a capable rival from matching or bypassing the benefit, and how well that constraint is established. Switching costs may explain retention and expansion after adoption without explaining the first purchase.

Trace the intermediate steps. For ServiceTitan, product investment matters through the contractor outcomes it improved, the customer experience that made recommendations credible, and the resulting route to new buyers. “Better product → higher customer ROI → more word of mouth” is a causal hypothesis to substantiate, not a substitute for evidence at each step. Attribute participant accounts and distinguish observed customer results from unmeasured comparative ROI or referral speed. Likewise, an end-to-end workflow can help explain both initial value and later switching costs within existing arguments; it does not need two blocks repeating the product's breadth.

### Compare the leading explanations directly

Ask: "What does explanation A explain that B leaves unexplained?" Compare candidates against the same outcome and period. Then check where each explanation stops working. For Robinhood, commission-free trading helps explain initial acquisition but leaves continued growth after incumbents matched the price unexplained. That later period helps test explanations involving the account relationship and product development.

Identify dependencies and overlap. Product simplicity can make referrals more effective; they may be steps in the same acquisition chain. Explain their relationship before treating them as separate reasons, and avoid counting the same outcome twice. Different causes can matter at different stages without competing for one company-wide ranking.

Use these checks to weigh the candidates:

- If this factor were missing, would the company's trajectory plausibly have been much worse? Explain the counterfactual and its uncertainty; do not invent a numerical contribution.
- Did rivals have the same feature or benefit? Explain why this company's combination, timing or execution produced a different result.
- Did the whole category grow? Separate market expansion from company-specific gains. Consider capital access, regulation, luck, competitor mistakes and inherited assets when consequential.
- Are we treating a result as its own cause? Growth, retention and brand awareness need an explanation of what produced them and how they affected later wins.
- What failed, changed direction or contradicted the thesis? Include the episode where it changes the explanation. Preserve uncertainty about what decision-makers knew at the time.

### Explain why customers chose this company

For each leading explanation, identify the customer's relevant alternative in the same period and segment. State the difference that mattered, the evidence connecting it to buying, adoption, expansion or retention, and why a rival's apparently similar offer did not remove that difference. Test whether the difference persisted, was copied or applied only to particular customers. The alternative can be manual work or buying nothing.

Use observed choices where available: a customer explaining a purchase or migration, procurement records, win/loss work, or adoption changing after a rival response. Distinguish those observations from our reconstruction. An interested source can supply useful evidence when its access, selection and scope are explicit. Naming a rival, listing its features or saying that competitors also offered the benefit does not complete the test. If the decisive comparison remains unresolved, research it further and retain that limit in the editorial decision.

These examples illustrate the work required; reassess the original sources for the business and period under study:

| Case | Weak comparison | More useful competitive test |
| --- | --- | --- |
| Toast | Other POS vendors also integrated payments. | Bessemer's [2015 memo](https://www.bvp.com/memos/toast) describes hardware choices, customer work and implementation economics. Test which differences mattered to particular restaurants and whether installation costs changed the apparent acquisition advantage. Attribute the investor's observations and examine their scope. |
| Figma | Sketch also had loyal designers. | Explain why credible editing combined with shared work justified switching from the customer's actual tool stack. Test adoption friction as well as benefits; the [CPO's account](https://review.firstround.com/lessons-in-product-scaling-and-storytelling-from-figmas-cpo/) describes resistance to colleagues seeing unfinished work. |
| Shopify | Rival platforms also had APIs. | The [2010 investor memo](https://www.bvp.com/memos/shopify) compares developer interfaces and records app use and designer referrals. Examine why specialists chose to build and recommend Shopify, and distinguish merchant adoption from exclusive partner dependence. |

### Research what could change the ranking

For each leading candidate, name an observation that would strengthen or weaken it relative to the alternatives. Turn the weakest consequential link in its causal chain into a specific research question. Prioritize gaps whose resolution could change the leading explanations or the weight they receive.

Look for customer migrations, rival responses and differences across periods or customer groups that help distinguish the explanations. Ask what each proposed cause would lead us to expect, then check what happened and what else changed. These comparisons need not be controlled experiments, but their limits belong in the review. Further descriptions of an already documented feature may add little to this judgment.

Return to the analytical-source comparison after this research. Have outside accounts identified a major cause we missed, or explained one more convincingly? Mark each material explanation as covered, newly incorporated, rejected with evidence or unresolved, with a reason and a draft location. Seek meaningfully different perspectives; agreement among writers does not establish causation. Keep access and coverage limits explicit rather than filling them with assumed consensus.

### Record why these explanations lead

Before drafting, add a brief explanation-selection note to `EDITORIAL_REVIEW.md`. It should state:

- Why the selected explanations deserve the most weight for the named outcomes and periods, with importance and confidence assessed separately.
- Which factors enabled the leading mechanisms, and which appealing explanations the evidence weakens.
- Which alternatives were merged, given less weight or excluded, and why.
- What unresolved evidence could change the selection or ranking, and which research addressed those gaps.

Update the note when later research changes the story. An interesting discovery must earn its weight in the account. Finding Robinhood's active-trader correction makes its history more complete, but does not by itself establish how much of the recovery that correction caused. When relative importance remains unresolved, preserve that uncertainty in the review and avoid presenting a precise causal ranking.

### Challenge the editorial conclusion

Before finalizing the outline, have the reviewer argue for the strongest competing explanation using the same outcome and period. Record the challenge, evidence that would distinguish the accounts, and the resulting decision: revise the selection, retain it with reasons, or leave a material issue unresolved. When the writer also reviews the draft, label the pass as self-review. A model review must identify itself and cannot satisfy the existing human publication review.

Express the resulting editorial conclusion in the summary and the emphasis of the public arguments. Say what mattered most at each stage and how supporting factors contributed. Keep detailed adjudication in the review. A disputed causal ranking must not become a confident public claim simply because the company became large; carry consequential uncertainty in the wording without adding repetitive commentary about source limitations.

### Arrange the selected reasons for the reader

Usually begin "What shaped the outcome" with the first consequential customer wins. Explain the opening in the market, the customers the company chose, the product decision that addressed their problem, and how it reached and persuaded them. These are Arena, Intent, Product strategy and Go-to-Market questions. Investigate all four; include what mattered without forcing four labels into the paragraph. Founding biography belongs only where it explains an ability, choice or relationship that affected the result — but where it does explain one, the founder's own account of it is the best source available and should be stated with confidence rather than hedged.

Order the remaining reasons so the reader can follow how the business developed. Explain dependencies: an early sales approach may attract the customers whose requirements improve the product, which then opens a larger market. Combine overlapping explanations while preserving the distinct mechanisms and supported tags within them. Give the decisive causes more space; do not allocate one entry to each layer or turn every launch into a reason. Chronological reading order need not match the importance ranking recorded in the review.

## 4. Write the summary after choosing the reasons

Use roughly 80 to 120 words as a starting budget. Lead with the company's distinctive answer to a real customer problem. Name the initial customer and the constraint or unsatisfactory alternative. Explain the choice that earned the first wins, then the most important way those wins compounded. End with the present scope or a limit that changes how the reader should understand the success, when relevant.

Make the causal sequence legible. Prefer a specific customer task, product choice or buying obstacle over phrases such as "an innovative platform" or "a powerful ecosystem." Include one revealing detail if it earns its space. Every claim in the summary must be supported in the page below.

Read it with the company name hidden. If it could introduce three competitors, make it more specific. Read it alone: could someone explain why customers bought and why the business grew? Save incorporation dates, executive biographies and secondary initiatives for places where they help the argument. Avoid a compressed list of tags or a miniature table of contents.

Write the one-line headline after the summary, once the causal story is settled. This is the `headline` field passed to `company()` in the study's `author.py`; it appears above the thesis paragraph on the company's own page and doubles as the one-line description on the case study index. It is not a slogan or a command: open with a concrete subject (the company, an early product, the problem it solved, the customer it served) and narrate a transformation, the way the first line of a story would. Never lead with a bare imperative verb ("Make...", "Build...", "Turn...").

Carry two beats: the insight or choice that won the first customers, and the mechanism that later compounded or defended those wins. Where the page establishes a moat, name it: switching costs, network effects, earned trust or the specific defense documented. Otherwise explain the supported growth mechanism; include an open question only when it is central to the story. Do not turn a plausible defense into a proven moat for the sake of the headline, or omit an established defense to focus only on the origin.

Ground both beats in claims the page already makes; add nothing the summary and evidence don't support. Run the draft through the humanizer pass described below before it goes in `content.json` -- a staged, aphoristic close ("...and earn a place in the work itself") or a vague abstraction ("make booking them feel possible") is exactly the pattern to cut. Two worked examples, from the September 12 Adobe and Airbnb studies:

- Adobe: "A fix for the Mac's printing problem grew into the tools designers relied on every day, until years of invested skill made leaving too costly."
- Airbnb: "A stranger's spare room earned enough trust to rival a hotel room, then a swelling supply of unique listings made Airbnb the first place travelers looked."

Read the headline alone, with the thesis paragraph hidden: does it tell a reader where the company started and how its wins later compounded or became defensible, in one breath?

Check the headline alongside neighboring entries in the generated company directory. Every entry must explain the initial customer benefit and the consequential growth or defense supported by its study. Reject imperatives, aphorisms, abstract fragments and generic praise even when they sound appealing in isolation. Keep a concrete subject and natural variation in sentence structure. Confirm that the published index and article use the reviewed `headline`; assess the rendered text as well as the authoring field.

## 5. Make "What shaped the outcome" worth reading

Give each reason a heading that states a company-specific action or consequence. "Partners brought customers and supplied specialist tools" tells the reader more than "Platform ecosystem." Such a heading still needs evidence for both claims.

Build each entry around one coherent causal argument, which may connect several mechanisms. Ground it in a documented decision, customer episode or revealing number; explain how that changed behavior or economics; compare it with the relevant alternative. A reason about account expansion can also explain how accumulated training and connected workflows made replacement disruptive. Give that defense its appropriate tag and link to its advantage history; it need not earn a separate block. Use concrete details to carry the explanation. Never invent a scene, dialogue or a founder's private motivation to make the story vivid.

Preserve the evidence that distinguishes the explanation from its competitors. Compression should not remove the customer choice, economic constraint or failed approach that makes the argument convincing. Apply the competitive test above to each leading reason, credit borrowed interpretations where used, and give the most consequential mechanisms appropriate space.

Keep the reading path in connected prose. Put claim-level facts, inference, comparator, locators and review status in expandable evidence. Bring a qualification into the main paragraph when it changes the conclusion.

Keep routine research commentary in the limit field and review. Repeated sentences such as "no source measures" or "the record does not show" can interrupt the explanation without helping the reader assess it. State what happened, credit the interpretation and qualify the causal claim where the qualification matters. The company's size does not establish why it succeeded. If uncertainty changes which explanation deserves weight, express that uncertainty in the main prose. A fact that qualifies the conclusion — a discount that bought a renewal, a failure, an unfinished transaction — also stays in the prose. Avoid repeating the same methodological caveat after every entry, and avoid burying decisive counterevidence in a drawer.

Use the [humanizer writing principles](https://github.com/blader/humanizer/blob/main/SKILL.md) for the editorial pass. Prefer concrete subjects and active verbs. Cut staged openings, inflated significance, sales language, empty contrasts and closers that repeat the point. Vary sentence length and paragraph shape; avoid repeated triads, decorative bold labels and habitual dashes. Read aloud, revise awkward paragraphs, then check that every fact, citation, causal qualification and uncertainty survived. A cleaner sentence must not make a stronger claim than its evidence supports.

## 6. Make the taxonomy serve the explanation

Read `brands/strategy/CLAUDE.md`, the current `data/taxonomy.json` and the [diagnostic catalog](diagnostics/CATALOG.md). Use stable IDs and each concept's actual question. Wiki examples are research prompts, not company evidence. Complete the tag-specific evidence checklist before applying a tag; [Applying tag-specific rules](diagnostics/TAG_CLASSIFICATION.md) explains the ledger and outcomes. Existing case study placements are leads for review, not evidence that a classifier passed. Tags whose classifier sets `build_gate` (Modular Products today) cannot join the site until `build/classifier_gate.py import <batch>` records a supported result from the study's own ledger; see the [production reference](TEARDOWN_PRODUCTION.md#build-gated-classifiers).

| Layer | Test the explanation against this question |
| --- | --- |
| Arena | Before this company existed, what could a prospective customer do about this problem, and what did it cost them? |
| Intent | Given that assessment, who did the company choose to serve, how would it win, and what did it give up? |
| Product | What customer need or learning changed the product, and what value resulted? |
| Go-to-Market | Who bought, how were they reached, and what made the sale work? |
| Operating Model | What funded capability or repeated practice made this possible? |
| Advantage | What benefit persisted, and what constrained a relevant rival? |

Assign Arena tags to the supported external conditions in entry paragraphs and relevant arguments. Later assessments require their own date, scope and evidence. For the other layers, assign tags to the mechanisms each argument actually explains. One to three is a useful default, not a hard ceiling: retain an additional distinct, supported tag when dropping it would hide part of the explanation. Remove synonyms and incidental labels before considering another block. Keep tags linked and visible by default, with an option to hide them. The prose must make sense with tags hidden. The table guides investigation; the site's six-layer order remains Arena, Intent, Defensibility, Product Strategy, Go-to-Market Strategy, Operating Model.

### Explicitly review advantages and moats

For every study, investigate what helped the company win and what made those gains persist. Give this review particular attention for large, sustained winners: explaining their entry alone leaves much of their success unexplained. Size, valuation, growth and retention are reasons to investigate advantages, not proof of any particular moat.

For each material advantage, identify the customer or economic benefit, the mechanism constraining a rival or customer exit, the relevant business and alternatives, when it emerged, and the strongest competing explanation. Distinguish evidence for the mechanism from evidence for its magnitude and durability. Documented training, embedded workflows and accumulated records can support a qualified Switching Costs interpretation even when migration costs have not been measured. High retention alone cannot establish switching costs, and a broad suite alone cannot establish Scope Economies or Network Effects.

Tag a materially relevant, evidence-backed advantage on the What shaped the outcome argument that explains it, including a qualified candidate when the mechanism is a reasoned inference from documented facts. State that status in the argument and linked advantage record; the tag itself does not certify a proven moat. An unsupported possibility stays in research notes. Missing evidence about strength or durability should qualify the claim, while missing evidence for the mechanism itself may prevent the tag.

Use advantage history to show emergence, accumulation and erosion over time. It complements the explanation in What shaped the outcome; it is not the exclusive home for later defenses. A later defense that helped retain or expand the installed base belongs on that argument even if it did not win the first customer. For ServiceTitan's third reason, connected job records and trained staff support a qualified Switching Costs tag alongside account expansion; the absence of measured exit costs remains a limit.

After merging or cutting reasons, audit tag coverage separately from argument count. Preserve every supported mechanism that still matters, on the relevant argument, timeline event or advantage record. Check that an important defense has not disappeared from What shaped the outcome merely because its standalone block was removed. Repeated tags warrant an overlap review, but can remain where distinct applications are explained; fewer blocks must not mean fewer supported advantages.

### Intent tags describe committed choices

Classify Intent before considering the company outcome. Record the chosen customer, approach, alternative declined, resources committed and intended mechanism. An implemented choice can qualify when adoption is weak, economics fail or the company later closes. A mission, audience label or unimplemented plan is insufficient. Attribute participant reasoning and distinguish our reconstruction from documented management intent.

Use this test: By choosing this approach over that alternative, the company committed these activities to change this customer task or economic relationship. Then assess the observed effect separately in `contribution`. The legacy `winning_mechanism`, `specialist_win` and similar predicate IDs do not require success. Defensibility still needs its own benefit and rival-barrier evidence.

Apply each concept's definition. Monopolize a Small Market First needs a deliberate dominate-then-expand sequence, even if dominance never arrives. Vertical Specialization needs industry-specific requirements and tailored activities; a job function or customer size is not an industry. Developer-First Strategy needs an implemented developer adoption route. Component Specialization needs a deliberate boundary within another firm's finished offering. Focus Strategy needs tailored activities and a broader opportunity declined. Ordinary expansion, fundraising and being acquired do not establish any of these choices.

For M&A Strategy, the company must be the acquirer and undertake a substantial acquisition commitment or sustained program with an explained build-versus-buy rationale. Record integration, returns and write-downs separately. A company's own sale is an outcome event. For Product Leadership, identify successive delivered advances and the customer value pursued; investment or a superiority claim alone is insufficient.

For Blue Ocean Strategy (`blue-ocean-strategy`), identify the targeted noncustomers or new use, prior alternatives, value and cost factors changed, and the implemented commitment. Explain the path to demand beyond taking existing share. New demand need not materialize, and the company need not win. Record adoption and the business outcome separately. A category name, cheaper copy, generic underserved segment or unimplemented ambition does not qualify.

### Finish classification across the whole study

Review every claim, dated event cell and chain step, including those on unsuccessful and unresolved companies. Review the action at its date; do not backdate adoption or copy all claim tags onto its events. Add supported tags through reviewed current placements. Retain a record-specific reason for contextual milestones, observed results, unimplemented plans and actions no current tag describes. Missing research stays a visible gap, never an implied negative observation.

Save coverage in `data/case-study-coverage.json` with the current batch and input fingerprints. New studies and successors require a coverage record. An existing study's tag correction must update the affected record review. The build checks recorded reviews for stale or missing inputs; `build/case_study_coverage.py --complete --company <id>` checks delivery completeness. Read the generated coverage report before calling a batch finished.

Every new study needs a sourced, dated causal chain regardless of its outcome. Use the same scope and level of detail for both sides of a comparison. Tag each step's implemented move, and identify pure outcomes separately. Do not force the final step to be a moat or a shutdown. A losing company can retain a scoped Defensibility tag supported in its own study; a rival's moat or an advantage it only hoped to build cannot supply that evidence. A missing chain is a delivery gap, recorded in the coverage report. Legacy gaps remain a named backlog rather than disappearing from the denominator.

Review and save an official outcome assessment before delivery. An explicit unresolved assessment is acceptable when the source, missing fact and next research action are recorded. Do not substitute analyst guesses, private financing values, enterprise values or asset prices for a measure the outcome policy requires. Outcome labels, paired-comparison roles, mechanism contribution and operating status are different fields.

For comparisons, report denominators, unresolved labels, event and chain coverage, and tag counts by outcome tier. Missing tags are not absence until coverage has been reviewed. Lead with official labels. Any provisional scenario must be opt-in, show its assumptions and be reported separately. Treat raw incidence as descriptive: compare within tag-count strata and show company tag shares, then check a comparably reviewed subset. Report thin or empty strata. No predictive or causal claim follows from a raw winner gap in this curated corpus. Chain comparisons must disclose missing chains and exclude any outcome-dependent final-step construction from claims about sequence.

### Educational Seeding under Reach

Use `educational-seeding` when educational use builds familiarity that can travel into workplace adoption. Identify the school or university users, how access or learning was supported, and the mechanism or observed examples connecting that use to employers. Distinguish a dated seeding activity from proven commercial conversion. Free licenses are optional; ordinary school sales, employee training and education-market focus alone do not establish the route. Do not infer original management intent from later adoption. Any network effects or switching costs require separate evidence.

### Name the operating method and chosen product approach

Capability Building is retired as a company tag. Keep “What capabilities did this require?” as a research question, then identify the specific operating method and its contribution to winning. Generic engineering, hiring, reliability, implementation and investment are not sufficient. Preserve those events as context when relevant; do not fill the gap with a generic replacement tag.

- **Forward-Deployed Engineering**: engineers work directly in customer operations, get a solution into use, and return reusable improvements to the core product. Show the adoption or outcome benefit and the cost of the method. Interviews alone belong to Customer Discovery; ordinary installation or support is insufficient.
- **Fulfillment Network Design**: explain how facility locations, inventory placement, processing capacity and transport connections work together to improve delivery, selection or economics. Identify the coordination problem, trade-offs and observed results. Difficulty can explain a competitive barrier only with evidence; a list of warehouses, acquired sites or planned investments is insufficient. Preserve candidate status when relative cost or durability is unmeasured.

Do not introduce Design Partners, Repeatable Implementation or Reliability Engineering as replacement tags. Design-customer learning belongs to Customer Discovery. Specific sales-motion tags or Scope Economies may fit particular records, but require their own evidence. A failed logistics investment does not establish a winning fulfillment network; routine implementation does not explain why Epic won. Process Power requires a separate test of routines that take rivals a long, costly effort to match.

Replace the combined End-to-End vs. Modular Products tag with the approach actually chosen:

- **All in One Solution**: name the customer job, related tasks combined, delivered workflow, observed combined use and benefit compared with separate solutions.
- **Vertical Integration Strategy**: name connected value-chain stages, the internalized stage, substantive operating control, implemented commitment, outside alternative and how control helps the business compete. A broad suite or shared hosting alone does not qualify.
- **Modular Products**: name the components that can work, change, scale or be supplied independently, the interface that enables that separation and the customer benefit. An API or data exchange alone does not qualify.

Tag the business, period and boundary. All in One Solution concerns customer tasks combined in a usable offering; Vertical Integration Strategy concerns ownership or operating control across value-chain stages. A company can do either or both. Modular interfaces can support an all-in-one offering. Review each tag against its own evidence, and require both the concept classifier and shared layer requirements. Customer Discovery and Founder Domain Expertise have separate before-delivery tests. Epic’s clinical and administrative workflows illustrate the combined offering. Adobe’s cross-supplier PDF tools illustrate modularity. Integration vs. modularity is retired as an Arena tag; preserve useful industry conditions as context and review them against the current Arena tags. No retired placement receives an automatic replacement. Component Specialization and Platform Strategy remain distinct Intent choices.

### Propose a new tag when the taxonomy has a gap

When an important, supported explanation fits poorly, check existing definitions, variants and retired concepts. If a distinct mechanism still lacks a suitable tag, propose one. The proposal should explain what the new concept helps us recognize in company histories and why the closest existing tags would misdescribe or omit it. A synonym, company-specific feature name or unsupported moat claim does not justify an addition.

Prepare a concrete proposal before asking for approval. Include:

- The proposed name, a short definition, and its layer and group.
- The closest existing tags and the distinction that warrants a separate concept.
- The case-study passage and source evidence that motivate it, including uncertainty about the mechanism or its importance.
- A diagnostic question and the evidence needed to apply the tag, with an example of what would not qualify. For an Advantage tag, address both benefit and barrier.
- Source attribution, or an explicit label identifying it as an editorial addition. Mention other plausible applications when known; do not invent examples to imply broader support.

Present the proposal to David in chat and ask for explicit approval before adding or applying the new tag. Link this section as the reason approval is required. A proposal recorded only in `EDITORIAL_REVIEW.md` is not sufficient, and a request to write or revise a teardown does not itself approve a taxonomy addition.

Record the proposal as pending in `EDITORIAL_REVIEW.md`. While awaiting a decision, continue the case study using supported existing tags and leave the unmatched mechanism in plain prose. Keep the proposed tag out of the active taxonomy, diagnostic rules and page tags until approved. If David declines it, record the decision and preserve any supported explanation without forcing it into another tag.

After approval, record the decision and implement the agreed concept under the brand's conventions: add its stable ID, definition, diagnostic question, attribution and relationships to `data/taxonomy.json`; update affected diagnostics and the study's placements; then validate and rebuild. Preserve existing IDs and dated study snapshots. Approval of a concept does not establish that every proposed company placement meets its evidence test.

### Sales-motion tags

Sales Motion is retired. Use Product-led Growth, Enterprise Sales, Channel Sales, Land and Expand, Consultative Selling or Reference Selling when the record establishes that approach and explains its contribution. Product-led Growth requires product use to drive adoption or conversion; it is not implied by a free tier or developer audience. Enterprise Sales requires a managed buying process; customer size alone is insufficient. Channel Sales requires a partner’s selling role. Land and Expand requires an initial foothold and a path to wider account use. Consultative Selling requires evaluation of the buyer’s specific problem. Reference Selling requires comparable customer experience to help a later buyer evaluate. Multiple approaches can coexist, but do not stack synonymous tags on one mechanism. Generic launches, renewals and migrations may remain untagged. Preserve dated research and apply reviewed placements through the current tag-update file.

### Trust

Use Trust in Advantage when customers rely on credible competence or reliability and that confidence changes buying behavior. For founders, identify the prior history, the customers who recognized it and evidence that it transferred to the new firm. Background, credentials, fame and a customer-oriented slogan alone do not qualify. Prefer the specific Trust tag over Branding for the same risk-reduction explanation. Reference Selling is the selling activity that presents proof; expertise describes capability. Neither alone proves trust. Preserve the distinction between an entry benefit and a durable barrier against named rivals.

### Founder Domain Expertise

Use `founder-domain-expertise` in Product when prior experience informs a concrete initial product or market decision. Name the experience, the customer-work knowledge it supplied and the choice it shaped. Family ties or credentials alone are insufficient. Distinguish knowledge brought into the venture from Customer Discovery experiments, Vertical Specialization and later customer Trust. Review this concept editorially before delivery; the automated delivered-value gate does not establish or reject prior knowledge. Preserve retrospective disclosure dates and do not turn a founding benefit into an assumed moat.

## 7. Finish the page and review it

Lead with the summary, a concise entry assessment and "What shaped the outcome," then advantage history and a strategic timeline with an optional matrix. Aim to stay within roughly 1,200 to 1,800 words including the matrix; shorter is welcome. Evidence detail belongs in companion records. Existing pages demonstrate the content format, not a ceiling on writing quality.

Choose five to seven periods around real strategic transitions and six to ten consequential developments. Include entry, the first customer-acquisition mechanism, compounding and meaningful reversals or adjacencies where they matter. A recent announcement earns space only if it changes the explanation. Date events to when they happened. A matrix uses periods as rows and the six layers as columns, with 20 to 40 words per populated cell. Leave empty cells empty and avoid repeating full arguments.

Before delivery, read only the summary and reason headings, then read the prose with all tags hidden. Can a reader explain the company's first wins, its major sources of growth, what defended them and the limits of its success? Compare the emphasis in the page with the explanation-selection note: do the headline, summary and space given to each reason reflect its assessed importance and confidence? Then show the tags and perform the separate coverage check: are supported advantages attached to the arguments they explain, with evidence status intact and no blocks added solely to house tags?

### Compare the finished study with the best outside work

Complete this record in `EDITORIAL_REVIEW.md`, naming the reviewer, date and exact draft assessed. Compare explanations within the relevant business, period and outcome; an outside piece's narrower scope can still expose a material omission in ours.

| Review question | Required judgment |
| --- | --- |
| Did we find the major relevant analytical accounts? | Search coverage, sources actually read, material access gaps and why further searches are unlikely to change the explanation. |
| Have we captured their strongest explanations? | Each material explanation is included, challenged with evidence or unresolved, with a draft location and credit for its origin. |
| Does our emphasis reflect what mattered? | Selection and weighting by stage, importance versus confidence, dependencies and the disposition of the strongest competing account. |
| Do competitive tests explain customer choice? | The actual alternative, consequential difference, supporting observations and limits for every leading reason. |
| What does our study contribute? | A specific improvement in explanation, reconciliation, evidence or synthesis, tied to a passage. Breadth or convenience alone cannot compensate for weaker analysis. |
| Is another account still materially stronger? | Name the account and the gap, the change required, and whether that change has been completed. |
| Do the headline and summary carry the conclusion? | Supported initial benefit and subsequent development, consistent emphasis, and a check of the generated directory and article. |

Record the result as `meets standard`, `revision required` or `comparison incomplete`. A material analytical shortfall requires revision; documenting it does not satisfy the standard. A material access or coverage gap leaves the comparison incomplete. When both apply, use `comparison incomplete` as the overall result and separately list the known revisions required; incomplete discovery does not defer corrections already supported by the evidence. Specify the next research or editorial action and reassess the changed draft. A bounded causal uncertainty can remain when it is represented honestly and does not leave a stronger material explanation unanswered. Never claim superiority over unread work or imply an exhaustive search of all published analysis. Passing schema checks cannot settle this judgment, and `meets standard` does not replace human publication review.

Use the [evidence and production reference](TEARDOWN_PRODUCTION.md) for ledgers, diagnostic commands, structured content, validation and delivery. Keep observed facts distinct from causal interpretation and historical events distinct from source-disclosure dates. Publication requires human review. Update the [research index](../) and preserve prior dated studies.

## 8. Rate the finished study

Every new case study and substantive revision must receive an editorial rating before production is marked complete. Do this after the final copy, evidence review, tags and current-study integration are settled. Rate the version the reader will see, including its research review and documented comparison with outside accounts.

Use the six criteria and 0-to-4 anchors in Case study ratings (`../build/CASE_STUDY_RATINGS.md`). Save the judgment in `../data/case-study-ratings.json` with a rationale for every criterion, supporting argument IDs, a concrete next action, reviewer, review date, current source batch and the assessed draft and standards fingerprints. Identify model self-review honestly; a rating does not constitute human publication approval. A low score or incomplete comparison still needs a rating that records the unfinished work.

Rebuild the admin and confirm that the completed study has a score, criterion rationales and a next action at `admin/case-studies.html`. Its saved fingerprints must match the final reviewed version. If a substantive edit follows the rating, reassess it before delivery. Preserve other studies' saved scores and fingerprints unless they were actually reviewed. The [production reference](TEARDOWN_PRODUCTION.md#final-editorial-rating) gives the final checks.

## Changelog

- 2026-10-05: Arena tagging now covers batch (non-authored) pages too, reads classifier predicates as definitions rather than an evidence gate, rejects evidence-gap `untagged_reason`s, and adds the `kind: "arena"` tag-update placement. Backfilled 28 untagged batch pages (`claude/strategy/arena-tag-audit-20261005.md`).

- 2026-10-05: Made an editorial rating a required final production step for each new study and substantive revision, with saved rationales, current fingerprints and an admin verification.

- 2026-10-02: Made Arena tagging a required authoring step with a build check (tags or an `untagged_reason`). Added Scattered supply and Regulatory shift (fourteen Arena tags) and their boundaries with Information asymmetry, Limited local selection and Regulatory constraints. Backfilled the 55 untagged v4 pages.

- 2026-09-26 (after Snowflake): Build-chain research reads founders' technical papers and engineering essays, whose lessons-learned and related-work sections name rejected alternatives and rivals.
- 2026-09-26 (after Slack): Build-chain searches include early employees' own company-history newsletters and blogs, which date founding weeks and name rejected design alternatives.
- 2026-09-25 (after Netflix): When a moat's first building events predate the study's period, the scope extends to the earlier business under its own business label.
- 2026-09-25 (after Datadog): An interview page that fetches empty is opened in the browser before it is recorded as unreadable.
- 2026-09-25 (after Veeva): Build chains date contract terms from the document that first discloses them, not from the partnership announcement.
- 2026-09-25 (after Shopify): Build-chain research starts with the existing study's saved source texts, which often already hold the dated actions and declined alternatives, before spending web searches.
- 2026-09-25 (after Figma): Build-chain searches check public podcast transcript archives before recording an episode as unreadable, and read board members' IPO-day essays for the reasons behind pricing and go-to-market decisions.
- 2026-09-25 (after Airbnb): Build chains record the alternative a decision turned down when a participant names it, and searches cover investors' own podcast and essay series and early employees' essays, where rejected alternatives most often appear.
- 2026-09-25 (after Uber): Build-chain searches also cover contemporaneous trade reports of each launch, which often carry the only dated record and a participant quote for later mechanisms.
- 2026-09-25: Added "Trace how each strategy and moat was built": participant build chains for every material product, go-to-market and advantage mechanism, levers tagged on the action rather than the result, and advantage onset reset from at least two dated building events. Prompted by the eight-company moat build-out search (`moat-how-search-20260925/`).
- 2026-09-23: Required saving each source's text at first reading and quoting evidence from it, so later classifier changes are re-checked against saved text rather than refetched.

- 2026-09-22: Required broad company-level product and go-to-market fact inventories, separate from selected causal arguments, with dated source locators, coverage review and structured delivery.

- 2026-09-17: Added business-scoped industry assignment and an unassigned-study check to the teardown procedure.
- 2026-09-17: Added the admin outcome procedure, separate milestone and operating-status records, and research guidance for unsuccessful and ongoing companies.

- 2026-09-15: Made comparison with the strongest outside analysis an acceptance requirement. Added broad analytical-source discovery and attribution, a staged explanation-selection process with a challenge pass, customer-choice competitive tests, directory headline checks and explicit review outcomes.
- 2026-09-15: Barred evidence commentary from the reading path. Statements about what a source does not establish belong in the limit field and the review; qualifying facts stay in the prose as facts.
- 2026-09-15: Gave first-person testimony its proper standing. A participant is the primary source on decisions, intent, foregone alternatives and internal constraints, and such an account is supported on its own; source weight follows the speaker's access rather than the source type. Bounded that standing so it does not reach outcomes, magnitudes, the company's own causal attribution of its success, or a competitive barrier.
- 2026-09-14: Allowed proposals for distinct, evidence-backed taxonomy gaps, with a concrete proposal and explicit approval from David in chat before adding or applying a new tag. Research and writing continue while a proposal is pending.
- 2026-09-14: Required comparison of candidate explanations before outlining, separate assessments of importance and confidence, research aimed at evidence that could change their ranking, and an explanation-selection note. Added a final check that the page's emphasis matches those judgments.
- 2026-09-23: Linked the build gate for classifier-gated tags (Modular Products v2 adds a required `assembler` check separating it from Platform Strategy).
- 2026-09-14: Incorporated the ServiceTitan review: rank a few causal arguments, trace product value through customer outcomes to referrals, retain supported tags when merging blocks, and explicitly review later advantages. Made tag counts a default rather than a ceiling and distinguished evidence for a moat mechanism from its unmeasured strength. Integrated sales-motion, Trust and Founder Domain Expertise guidance into the taxonomy section.
- 2026-09-13: Retired Capability Building in favor of specific supported operating methods; added Forward-Deployed Engineering and Fulfillment Network Design. Split the combined product architecture tag into End-to-End Products and Modular Products with boundary-specific placement rules; excluded generic implementation and reliability tags.
- 2026-09-13: Required an explained contribution to winning for Intent tags; replaced the broad Where to play tag with four specific choices, distinguished Focus Strategy and Crossing the Chasm, and retained unsupported expansion events as untagged context.
- 2026-09-13: Renamed Value innovation to Blue Ocean Strategy and added a new-market-creation evidence rule under Intent.
- 2026-09-13: Anchored Arena to a named industry's entry conditions; added eligibility, attribution, customer-side scope, later reassessment and dated Arena-to-Intent rules. Piloted complete rewrites of Netflix, Shopify and Spotify.
- 2026-09-13: Added one-line headline guidance (subject-first, storytelling, origin plus moat) with worked Adobe/Airbnb examples.
- 2026-09-12: Added summary and narrative guidance, early-win reasoning, comparison with outside analyses, causal judgment checks, taxonomy-gap handling and a humanizer pass. Moved technical procedures into the production reference.
- 2026-09-12: Added VC websites to the source-map workflow and linked the expanded recurring-source allowlist.
- 2026-09-09: Added a causal editorial pass, source-review provenance, nine/ten-event reference histories, separate advantage continuity, and reading-page acceptance tasks. Applied to Workday, Amazon, Microsoft and Qualtrics in the v2 reference pages.
- 2026-09-09: Expanded the pilot beyond scope economies; added five other-layer diagnostics, corrected cultural resistance to match customer norms, and applied the workflow to Microsoft and Amazon.