Lessons 74.1 and 74.2 taught you to ask one question and read the answer honestly. But most teams then lose the answer. The winning video lives in someone's downloads folder, the losing variants vanish, and six months later a new launch starts from an empty prompt. This lesson fixes that with a library that remembers.

Losing variants still teach — if you keep them

Every creative test produces two assets: the winning file and the knowledge of why it won. The file depreciates; ad platforms change, audiences tire, offers evolve. The knowledge compounds, but only if you record the input, the version, the audience, the result, and the interpretation together.

Think of the library as team memory with two faces. Humans need a readable index: what was this, who was it for, what did we learn, and can we reuse the hook? Systems need structured fields to sort hundreds of records: show me all demonstration hooks for research builders that beat control on brief starts since March. Markdown serves the first need; JSON tags serve the second. This mirrors Parts II and III: Markdown for judgment, structured data for sorting.

Without both, familiar failures repeat. The ByeBuy Classroom launches a new course and re-tests a presenter hook that already lost twice to a screen demonstration — because nobody wrote down the two losses. The tailor re-buys the same stock photo that never booked a fitting. A library prevents paid amnesia.

What each record holds

Keep every record small enough to write in five minutes, complete enough to reuse in a year. Eleven tags cover nearly everything:

• audience: who this was for, specifically.
• offer: what was promised and at what terms.
• angle: the underlying customer insight or tension.
• hook: the opening move — first line or first three seconds.
• format: static, carousel, short video, creator clip, demonstration.
• proof type: screen capture, customer quote, before-and-after, data point, endorsement.
• platform: where it ran and its placement.
• result: promising / inconclusive / warning, with the primary metric.
• date: when it ran, for seasonality and fatigue context.
• owner: who can answer questions about it.
• reusable lesson: one sentence starting "Reuse when…" or "Avoid when…"

A record is not the video file itself. It is the card that points to the file, explains the test, and states the lesson. Store files wherever you already store assets; store knowledge here.

Example Markdown entry:

## RD-014 — Screen demo hook, sample brief
- Audience: solo research builders, newsletter + Meta prospecting
- Offer: free source-linked sample brief
- Angle: "I cannot cite a chatbot"
- Hook: 6s screen capture, filing → cited brief
- Format: 30s vertical video | Proof: screen capture
- Platform: Meta Reels + TikTok | Date: 2026-04 | Owner: Maya
- Result: promising — 16 vs 9 starts, cost per start 3.75 EUR
- Lesson: Reuse demo-first openings when proof is visual; avoid for audio-only placements.
- File: /assets/rd-014-demo-hook-v1.mp4 | Test: TEST-PLAN RD-014, READOUT RD-014

And the matching JSON tag block for sorting:

{
  "id": "RD-014",
  "audience": "solo-research-builders",
  "offer": "sample-brief",
  "angle": "cite-every-claim",
  "hook": "screen-demo-6s",
  "format": "short-video",
  "proof": "screen-capture",
  "platform": "meta-reels",
  "result": "promising",
  "date": "2026-04",
  "owner": "maya"
}

You do not need special software. A single Markdown file with a JSON code block per record, or a Markdown table plus a companion .json file, is enough until you pass a few hundred records. The discipline matters more than the tool.

Index humans will actually browse

Organize CREATIVE-LIBRARY.md for scanning, not for impressing auditors:

1. Top: five-line how-to — how to add a record, who approves lessons, and when to retire entries. 2. Best bets section — current controls by audience, with links to records. A new launch starts here. 3. Full index table — one row per record: ID, hook, audience, format, result, date, lesson. 4. Full records below — the Markdown cards with JSON tags. 5. Retired section — fatigued or offer-changed entries, kept for history but marked do-not-reuse-as-is.

A future ByeBuy launch should be able to answer in ten minutes: what are our three best hooks for self-taught builders, what proof did each use, and what should we test next? If the library cannot answer that, it is an archive, not a tool.

Maintenance rules keep it alive. Add every test within a week of readout. Write the reusable lesson as a decision, not a description — "reuse X when Y" beats "this performed well." Review quarterly: mark fatigued entries, update controls, and delete nothing — retire with a reason so the mistake stays instructive.

Exercise: build the ten-record starter

Create CREATIVE-LIBRARY.md with ten empty-but-structured records: three from past or hypothetical tests filled in completely, seven templated and ready. Use this skeleton for each:

## [ID] — [Hook + offer]
- Audience:
- Offer:
- Angle:
- Hook:
- Format: | Proof:
- Platform: | Date: | Owner:
- Result:
- Lesson: Reuse when… / Avoid when…
- File: | Test plan / readout:

{"id": "", "audience": "", "offer": "", "hook": "", "format": "", "proof": "", "platform": "", "result": "", "date": "", "owner": ""}

Seed it with the running examples: two Research Desk hooks (demo versus founder), two ByeBuy lesson hooks (screen versus presenter), two tailor creatives (finished garment versus process), one creator-publication angle, and three blanks for your own project. Even hypothetical seeds teach the habit, labeled clearly as drafts until real data replaces them.

Finish line: a CREATIVE-LIBRARY.md with ten records — at least three complete — that survives the current platform dashboard and can brief the next launch.

Verify quickly: ask a teammate to find "our best hook for [your audience] and what to test next" using only the library. If it takes more than ten minutes, tighten the index table and lesson sentences.

Common failure mode: a library that stores files but not judgments — 200 videos with names like final-v3-REALLY-final.mp4 and no record of what was tested or learned. Files without lessons are clutter.

Check your understanding

1. Why keep both a Markdown index and JSON tags instead of only one? 2. What eleven fields does each record need, and which one turns a description into a reusable decision? 3. Why retire entries with a reason instead of deleting them?

Next

Memory is built. Lesson 74.4 closes the class with governance — when to scale a pattern, when to refresh tired creative, and when to stop entirely.