Lesson 90.1 gave you one job. This lesson draws everything that job touches — and marks everything it does not yet need. The ByeBuy stack is a chain: files/context → models → tools → data → infrastructure → agents → application → distribution → monetization → scale. Every project lives somewhere on that chain. No first version needs the whole chain.

A map, not a checklist

Beginners treat the stack as a shopping list: one model, one database, one agent framework, one frontend, one payment provider, one analytics suite — before the first user exists. The map does the opposite job. It shows dependencies ("the brief needs filings, so we need a source fetcher before we need an agent") and exposes unnecessary complexity ("why does a one-page brief need three databases?").

The rule: draw all layers, use few. A layer you name and defer is a decision. A layer you never drew is a surprise.

Learn the system vocabulary. Use it consistently in your map and in every later artifact:

• Input — what enters: a question, a form, a filing URL, a booking request.
• Transform — what changes it: a model call, a calculation, a human edit, a filter.
• Output — what leaves: a brief, a confirmation, a lesson page.
• Storage — where state rests: a Markdown file, a Postgres row, an object store.
• Model call — one bounded request to a model with named inputs and an inspectable result.
• Tool / API — a function or service the system (or agent) invokes: search, fetch filing, send email.
• Human review — the named checkpoint where a person approves, corrects, or blocks.
• UI — what the user sees and touches.
• Route — the distribution path from Lesson 90.8.
• Payment event — the moment money moves, if v1 has one.
• Operating loop — the observe-respond-learn cycle from Lesson 90.9.

If two boxes on your diagram do the same transform, merge them. If a box has no named input and output, delete it or define it.

Sonariq, traced end to end

Use the Research Desk as the reference trace. Research specification files and source data inform bounded agents; agents prepare evidence; a human reviews it; the application delivers a report; distribution and subscription are separate layers:

SPEC + filings/peers (input/storage)
  → fetcher tool (tool/API)
  → structuring agent (transform/model call)
  → evidence draft (output)
  → human review gate (human review)
  → report workspace (UI/application)
  → newsletter placement (route/distribution)
  → seat subscription (payment/monetization)
  → weekly quality + cost review (operating loop/scale)

Notice what is absent on day one: no multi-agent debate club, no vector database empire, no dashboard suite, no automated publishing. The agent collects and structures; judgment stays human (Lesson 90.5). The brief is a file before it is a platform. Distribution is one placement, not seven channels. Each deferred item is written down, not forgotten — it waits for evidence.

Run the same trace for the other examples:

• ByeBuy Classroom: course map + research (storage) → draft + artwork brief (transform) → editorial review (human review) → lesson page (UI) → search (route). Payments and cohorts deferred until readers return.
• Local service launcher: form submission (input) → qualification check (transform, rules first, model only if needed) → calendar + notification (tools) → review queue (human review) → confirmed slot (output). No agent autonomy over booking until the manual path works.

Exercise: create SYSTEM-MAP.md

Create FINAL-PROJECT/SYSTEM-MAP.md with a small diagram and one sentence per used layer. Mark the rest deferred.

# SYSTEM-MAP — [Project name], [date]

## Diagram (keep it small — 5–9 boxes max)
[ASCII or bulleted flow: input → transform → review → output → route]

## Layers actually used (one sentence each)
- Files/context: …
- Models: …
- Tools/data: …
- Infrastructure/storage: …
- Agents/automation: …
- Application/UI: …
- Human review: …
- Distribution route: …
- Payment (if v1): …
- Operating loop: …

## Deferred (named, with trigger to revisit)
- [layer/choice] — deferred because … — revisit when …
- [layer/choice] — deferred because … — revisit when …

## Riskiest dependency
- [the one box that, if wrong, breaks the outcome — and its fallback]

Worked miniature for the analyst brief: input (company ticker + question) → fetcher (SEC + peer prices) → structuring model call → draft brief → human source check → one-page workspace → one newsletter placement → manual invoice. Deferred: vector search (revisit at 50+ briefs), auto-publish (revisit after 20 clean reviews), subscription billing (revisit after 5 paying pilots).

Finish line: a map with 5–9 boxes, a sentence per used layer, at least three named deferrals with revisit triggers, and one riskiest dependency with a fallback.

Verify: cover the diagram and read each layer sentence aloud. Can you name its input and output without pointing? Trace one real request end to end on paper. Any box the request never touches is deferred or deleted.

Common failure mode: the aspirational map — every layer filled because "we will need it eventually." Eventually is not v1. Its mirror is the missing human box: a fully automated flow with no review gate. Every transform a model touches needs a named reviewer until Lesson 90.7 proves otherwise.

Check your understanding

1. Why does naming a deferred layer prevent more risk than omitting it? 2. In the Sonariq trace, which step is a tool call, which is a model call, and which is human review? 3. What is the riskiest dependency in your map, and what is its fallback?

Next

Your system fits on one page. Lesson 90.3 gives it memory — the files that let any new session or collaborator orient before changing anything.