Lessons 18.1 and 18.2 gave you a universe of sources and a rule for using them: the model reasons, the data states, the workflow decides. Before you pick a provider or design a table, you need one more sort — because a weather forecast, a product manual, a support ticket, and a traveler's saved itinerary behave nothing alike inside a real app.

The four kinds, plainly

Every fact your product touches belongs to one of four families:

• Static reference data — curated, slow-changing material you maintain: a destination guide, a catalogue snapshot, a handbook.
• Live external data — facts owned by someone else on their schedule: weather, filings, inventory, prices. You query them; you never own them.
• Private organization data — internal records with an audience boundary: tickets, CRM notes, operations documents. Valuable because they are *not* public.
• User-provided data — what one person hands you: a form answer, an upload, a preference, a saved trip. It belongs to them.

A builder treats them as four contracts with different owners and promises.

How they differ in practice

Read the failure row twice. Static data fails by *age*; live data fails by *absence*; private data fails by *exposure*. Each needs a different guard: a review date, a fallback plan, an access check before the prompt is assembled.

One product map: the travel planner

A weather-aware trip planner — the same idea you sketched from the ByeBuy Data directory in Lesson 18.1 — uses all four kinds at once:

Live external:  Open-Meteo forecast (lat/lon, dates, units) + place/event data
Static:         destination guidance, packing rules, stable area descriptions
User-provided:  travel dates, budget, interests, dietary needs
Private/saved:  the user's saved itineraries (app-owned, permission-scoped)
        → workflow filters live options against user + static constraints
        → output: dated recommendation with source links

The forecast decides Saturday's hike; the static guide explains the trail system; the user's dates constrain both; the saved itinerary remembers the choice. Swap any two layers and the product breaks: a cached forecast treated as a guide sends hikers into a storm; a saved itinerary treated as public leaks one traveler's plans.

Live example: a forecast is not an itinerary

Open-Meteo makes the live-data contract visible because every response carries its coordinates:

{
  "latitude": 50.85,
  "longitude": 4.35,
  "timezone": "Europe/Brussels",
  "hourly": {
    "time": ["2026-09-12T12:00", "2026-09-12T13:00"],
    "temperature_2m": [14.2, 14.8],
    "precipitation_probability": [65, 40]
  }
}

Location, timestamps, timezone, units — without all four the numbers are meaningless, and tomorrow they change. Contrast that with the app's own saved itinerary:

{
  "itinerary_id": "it_4821",
  "user_id": "u_917",
  "dates": ["2026-09-12", "2026-09-14"],
  "choices": ["Grand-Place walk", "Saturday museum"],
  "forecast_seen": "2026-09-11T08:00Z Europe/Brussels"
}

The forecast is borrowed and timestamped; the itinerary is owned, keyed to one user, and remembers *which* forecast informed the decision. That remembered link is provenance, and Lesson 18.4 makes it a habit. FRED observations and SEC EDGAR facts work the same way: the provider owns the truth, you keep a dated, sourced reference.

Source of truth: do not make a second copy

Every important fact should have one home — its source of truth — and everywhere else should point at it, not duplicate it. The provider's API is the truth for live facts; your cache is a dated copy with a refresh rule. Your editorial file is the truth for static guidance. The access-controlled store is the truth for private records — a pasted copy in a chat log is a leak waiting to happen. The user's profile row is the truth for preferences; a second copy in a spreadsheet drifts within a week.

Duplication feels faster and rots faster. When two copies disagree, nobody knows which one the product believed.

Preview: files versus databases

A file can be exactly right for a small static resource — a short Markdown guide, a JSON config. Files are readable, versionable, and easy to hand to an agent as context.

A database becomes right when records must be saved, filtered, connected, and updated: many users, many itineraries, permission checks, queries like "all saved trips for this user in October." Classes 20 and 21 teach that decision with Postgres and SQL. Rule of thumb: one author's stable text belongs in a file; many people's changing records belong in a database with IDs, timestamps, and access rules.

Practical exercise: classify four items

Take one idea from your DATA-IDEAS.md — use the trip planner if you have no other. Create a four-row table in a file called DATA-SORT.md with columns: item | type | owner | update schedule | store-or-refer | model visibility.

Worked mini-example: Brussels weekend trip filter (2026-09-12 to 2026-09-14)

Decision/output (the filter this classification enables — reusable rule):

Do this now (15 minutes)

1. Open DATA-NEEDS.md from Lesson 18.2, copy each middle-column fact into a new file DATA-SORT.md as a row. 2. Add one row for your static guide (*-guide.md) and one for the user/saved record — you need four rows total. 3. For each row fill owner + docs link: Open-Meteo, FRED, or SEC EDGAR for live rows; file path + review date for static; user_id for user/private. 4. Write the store-or-refer cell as an instruction: "cache 1h, keep URL" or "DB row keyed to user_id" — not just "store." 5. Save DATA-SORT.md next to DATA-NEEDS.md; Lesson 18.4 will normalize one live row.

Finish line: a four-row table with type, owner, update schedule, store-or-refer decision, and model visibility for each item.

Verify: for every "live" row, point to the docs page stating the refresh reality — Open-Meteo, FRED, SEC EDGAR. No docs link, no live claim.

Common beginner mistake + what to do instead: marking the cached forecast "static" because "I saved it in a file yesterday" — then sending hikers into a storm. Instead, ask "what happens when the world changes?" If the product would lie, label it live, add retrieved_at + refresh rule (e.g. re-fetch hourly), and never treat the cache as the source of truth.

Check your understanding

1. Define the four data kinds in one sentence each, with one example per kind. 2. In the travel planner, which layer supplies the forecast and which supplies the saved itinerary? Why must they stay separate? 3. What is a source of truth, and why is a second unofficial copy dangerous? 4. When is a file enough, and when does the product need a database?