Classes 54 and 55 gave you the vocabulary: a specific person, a recurring job, a trustworthy outcome, a usable flow, and a reason to return. This class puts that vocabulary to work on real products. Before we open a single case study, you need the method — because the point of this class is not to admire Sonariq, Outbid.lol, Replit Agent, or Perplexity. It is to take any of them apart and carry the working part home.

Admiration copies features; builders extract decisions

Most people read products the way tourists read buildings: they notice the surface. The leaderboard looks exciting, so they build a leaderboard. The cited answers look trustworthy, so they bolt citations onto a chatbot. Then they wonder why the copy feels hollow.

A builder reads for decisions. Every working application is a stack of bets: this user, this job, this input, this data source, this trust promise, this reason to return, this way of finding the first users — and a long list of things deliberately not built. Your job is to recover those bets from the visible surface, because the surface is the only part you can see and the decisions are the only part worth copying.

That is why this lesson comes first. Lessons 56.2 through 56.5 each analyze a different shape — a research workflow, a shareable loop, a coding platform, a source-linked answer product. Lesson 56.6 turns your notes into your own blueprint. All of them use the same card.

The nine-question card

Use these nine questions in order. They move from the user inward to the machinery, then outward again to distribution and risk — the same arc the whole course follows.

1. Who is the user?
2. What recurring job are they completing?
3. What is the wedge / first useful action?
4. What inputs, data, models, and tools make it possible?
5. What must the user trust?
6. What happens when the system is wrong or unavailable?
7. What creates a reason to return?
8. What distribution path made the first users aware of it?
9. What would be too expensive or risky to copy blindly?

Questions 1–3 are the product bet. Be ruthless here. "Investors" is not a user; "someone researching one public company before deciding what to read next" is. "Get answers" is not a job; "turn scattered filings and articles into one organized brief I can revisit" is. If you cannot name the wedge — the single first action that delivers value — you have not understood the product yet.

Questions 4–6 are the system bet. What goes in, what machinery touches it, and what promise holds when the machinery fails? Every AI product is wrong sometimes and unavailable sometimes. The serious products decide this in advance: visible sources, uncertainty labels, refresh behavior, saved state, logs, human approval. A demo hides failure; an application prices it in.

Questions 7–9 are the survival bet. Why would anyone come back after the novelty fades? How did the first hundred users actually arrive — not the myth, the path? And what part of this would punish a blind copier: moderation load, payment disputes, data licensing, support burden, abuse, infrastructure cost? Question 9 is the one beginners skip and professionals ask first.

Evidence levels: not all facts weigh the same

A case study is only as honest as its sources. Rank everything you claim on five levels:

Two rules follow. First, cite the level in your card: "launched August 19, 2026 (L1, About page)" beats a bare date. Second, mark unknowns explicitly instead of filling them. "Unknown: server cost per bid spike; not disclosed" is a finding, not a gap. The outline for this class is strict on this point: cite sources in every case lesson and do not invent internals. That standard starts here.

A worked micro-example helps. The Outbid.lol About page embeds a buyer post claiming "6,550+ clicks" from a bought #1 rank (CrowdReply, August 2026). That is L4 — a user report, quoted on the product's own page. It tells you one buyer had a good 48 hours. It does not tell you the median buyer outcome, the refund rate, or the traffic a month later. A builder writes all three sentences down: the claim, the level, and what is still unknown.

Observed facts versus assumptions

Draw a hard line down the middle of your notes. Left column: what you saw or what a source states. Right column: what you inferred.

• Observed: "The rules page says rank equals amount paid; payments are non-refundable." (L1)
• Assumption: "Therefore the business keeps all bid revenue as margin." (Unverified — payment fees, refunds under dispute, tax, and operating cost are undisclosed.)

Beginners merge the columns and then build on the merge. Builders keep them apart and then design around the unknowns. When Lesson 56.3 analyzes Outbid.lol, the mechanism — pay, rank, get outbid, pay again — is observable. The unit economics are not. The lesson teaches the loop, not the ledger, and says so.

Exercise: card one app you use weekly

Pick something unglamorous you actually open every week — a transit app, a notes tool, a bank app. Glamorous products tempt you to admire; boring ones force you to analyze.

Fill in the full card in a file called APPLICATION-CASE-CARD.md using this structure:

# Application Case Card — [Product name], [date]

## 1. User / 2. Job / 3. Wedge
## 4. Inputs, data, models, tools
## 5. Trust required
## 6. Wrong or unavailable behavior
## 7. Reason to return
## 8. Distribution path
## 9. Too expensive or risky to copy

## Sources (with evidence levels L1–L5)
## Unknowns (explicit list)
## Transferable decision (one sentence)

The last line is the whole point of the exercise: one decision you can carry to your own product. Not "add a leaderboard" but "make the first useful action completable in under two minutes with a visible saved result." If your card cannot produce that sentence, your analysis is still a summary — push one level deeper.

Done means: one APPLICATION-CASE-CARD.md with all nine questions answered, at least three cited sources with evidence levels, at least three explicit unknowns, and one transferable decision. Verify: hand the card to someone else and ask them to point to which claims are observed and which are assumed — they should be able to do it without asking you. Common failure: a card full of feature descriptions ("has dark mode, has mobile app") with no user, no job, and no reason to return. Features describe the surface; the card describes the system.

Check your understanding

• Why do questions 1–3 come before any question about models or tools?
• What is the difference between an L1 source and an L3 source, and why does it change what you can claim?
• Why must unknowns be written down instead of left blank?

In the next lesson you will use this card on the instructor's own project — Sonariq / Research Desk — and see how a research workflow turns public sources into a repeatable private asset.