In Lesson 18.1 you mapped the public data universe with the ByeBuy Data directory. Now comes the decision that universe forces on you: which facts should come from the model, and which must come from data you supply? Get this wrong and even the best sources produce a confident, fluent, subtly wrong product.

Think back to Part V. An API is a road; data is what travels on it. Class 13 taught you the road. Part VI teaches you to choose the cargo.

Three things beginners blur together

Beginners talk about "what the AI knows" as one blob. Builders split it into three layers with different owners, freshness, and failure modes:

A model is a reasoning engine with a blurry memory of the world. Your product is the thing that hands it sharp, dated facts and a workflow — then shows the evidence. That split is the whole formula for this part of the course:

MODEL + RELEVANT DATA + A USEFUL WORKFLOW = A USEFUL APPLICATION

Remove any term and the product collapses: a great model with no facts invents; great facts with no workflow drown the reader in JSON; a great workflow with a weak model fumbles the summary.

One question in three versions

Ask: "What was Apple's last reported revenue?" Watch how each layer answers differently:

1. Model alone: "Apple's revenue is typically in the hundreds of billions, mostly from iPhone…" — plausible background, no period, no figure, no source. Useless as a fact. 2. Model + runtime fact: EDGAR's XBRL company-facts JSON names the concept, unit, period end date, and filing. Now the answer can say "$391 billion for fiscal 2024" with a link. 3. Model + fact + workflow: Sonariq's research file adds judgment — which period counts as "last reported," which concept maps to "revenue," how to phrase the comparison. The reader gets a number *and* its meaning.

The model explains; the source states; the workflow decides what belongs in the answer.

Walk through a real SEC filing fact

SEC EDGAR serves filing history and XBRL facts as JSON — XBRL being the labeled-data format in which each financial fact carries its concept, unit, and period, so a machine can read it precisely. A research app does not paste the whole response into the prompt — it selects the company, concept, period, and source link that belong in a reader-facing answer:

{
  "cik": "0000320193",
  "entityName": "Apple Inc.",
  "facts": {
    "us-gaap": {
      "Revenues": {
        "units": {
          "USD": [
            {
              "end": "2024-09-28",
              "val": 391035000000,
              "form": "10-K",
              "filed": "2024-11-01",
              "accn": "0000320193-24-000123"
            }
          ]
        }
      }
    }
  },
  "source": "https://data.sec.gov/api/xbrl/companyfacts/CIK0000320193.json"
}

Every field earns its place. The CIK pins the company even if the name changes. The concept plus unit pins the meaning. The end date plus filed date pins the period. The accession number plus source URL pins the evidence.

The same discipline applies elsewhere: a FRED observation needs its series ID, date, value, and release; an Open-Meteo reading needs location, timestamp, and units. Facts without their coordinates are rumors with formatting.

Why more data is not better

Handing the model "everything we could find" feels safe. It usually makes answers worse:

• Stale data answers last year's question. A cached forecast or an old filing presented as current misleads more than no data at all.
• Mismatched data answers a neighboring question. Quarterly revenue is not annual revenue; CPI is not unemployment; forecast is not observation.
• Private or unlicensed data creates liability. Data the user should not see, or data you have no right to redistribute, must never enter the prompt.
• Irrelevant data buries the signal. Ten loosely related documents push the decisive paragraph out of the model's attention.

Relevance beats volume. One filing excerpt with the right period beats fifty search results. One FRED series with documented units beats a folder of spreadsheets with unknown columns.

Retrieval vs. reasoning: a preview

Model knowledge → live / private data → product workflow → answer with evidence
         (reasoning)      (retrieval)          (judgment)          (trust)

• Retrieval finds the relevant material: the right filing, the right series, the right support article, filtered by permission, date, and scope.
• Reasoning makes sense of it: compares periods, explains a move, drafts the summary, follows the product's rules.

When an answer is wrong, ask which half failed. Did we fetch the wrong period — or fetch correctly and interpret badly? Class 23 builds the full retrieval-plus-generation system (RAG) on exactly this split. For now, practice naming the half before fixing anything.

Practical exercise: write DATA-NEEDS.md

Choose one product question — ideally one row from your Lesson 18.1 DATA-IDEAS.md. Create a file called DATA-NEEDS.md with one question and a three-column card:

Worked mini-example: did Apple beat the trend while rates fell?

Question: "Did Apple's FY2024 revenue beat FY2023 while long-term rates fell?"

Retrieval rows (copy this concreteness — source + identifier + period + evidence link):

Model explains (left column): what revenue means, how to read a 10-K, what a falling DGS10 implies for margins. Product calculates (right column): YoY change = (391035000000 − 383285000000) / 383285000000 = +2.0%, aligns filing year with FRED window, renders brief below.

Decision/output (paste-ready brief you can reuse):

Do this now (15 minutes)

1. Open your Lesson 18.1 DATA-IDEAS.md, pick one question, copy it as line 1 of a new file named DATA-NEEDS.md. 2. Under it, paste the three-column header above and fill left column with 2 bullets the model can explain with no lookup. 3. Fill middle column with at least two retrieval rows in this exact shape: source name + identifier/series + period end/filed date + evidence URL. 4. Fill right column with one calculation (YoY %, threshold, score) and one output shape (brief, card, alert). 5. Save DATA-NEEDS.md next to DATA-IDEAS.md so Lesson 18.3 can classify each middle-column row.

Finish line: a DATA-NEEDS.md with one question and three filled columns — at least two retrieval rows each naming source, identifier or series, period, and evidence link.

Verify: cover the middle column and re-read your answer draft. If any number survives without a visible source, it belongs in the middle column, not in the model's head.

Common beginner mistake + what to do instead: writing "model knows Apple's revenue is ~$390B" in the left column and citing no period. Instead, move every number to the middle column with CIK + concept + end date + filing URL, and leave the left column for definitions only ("revenue = us-gaap:Revenues in USD; YoY = (new − old)/old").

Check your understanding

1. What lives in each of the three layers — learned knowledge, supplied context, runtime source? 2. Why does "What was Apple's last reported revenue?" need all three layers for a trustworthy answer? 3. Copy the formula from memory. What breaks when each term is missing? 4. In one sentence each, what are retrieval and reasoning — and which one does Class 23 combine?