You already know how to keep an AI project under control: small slices, named files, contracts, task cards, review gates. Now that control has to produce something a real person can use. That is where most AI-built projects get fuzzy, because everything on screen gets called "the app."

Open your Research Desk idea and pick its simplest action: search for a company. A person types AAPL, presses Enter, and sees a research brief with linked sources. It feels like one thing. It is five responsibilities cooperating:

1. Interface — the search box, the button, the results layout the person sees. 2. Browser interaction — what the browser itself does: capture the keystrokes, send a request, wait, render whatever comes back. 3. Backend rule — the trusted application code that checks the input, enforces product rules, and decides what may happen. 4. Data access — reading approved data or a cache, or calling an approved outside provider through the backend. 5. Rendered result — the brief on screen, or an honest empty state or error when there is nothing good to show.

Call all five "the app" and you will hand an AI a task like "build search" with no boundaries. It will invent all five at once — and hide your paid provider key in the browser bundle while it is at it.

Five definitions that prevent that

These are responsibilities, not necessarily five separate companies or codebases. A small Research Desk can ship them together in one application (Class 46 makes that the default). But you must know which job each line of code is doing.

Neighborhood Events shows the same split with less financial context: the events list page is frontend; the rule "only the organizer who created a listing may edit it" is backend; the listings table is the database; a map-tile service is an external provider; the hosted site is the deployment.

The request path, step by step

Trace what happens when a person chooses AAPL:

Person chooses AAPL
  → browser sends a request
  → backend checks permitted input and applies product rules
  → data layer reads approved data / cache
  → backend returns a defined response
  → frontend renders result, empty state, or useful error

Walk it slowly, because every later lesson in Part XI points back here:

1. The person types aapl and submits. The frontend normalizes the display (uppercase, trimmed) and sends a request such as GET /api/brief?ticker=AAPL. It does not fetch market data itself. 2. The backend receives the request. It validates the ticker shape (more in Lesson 45.3), applies product rules — is this caller allowed this action, is the provider quota intact, should this come from cache? — and only then touches data. 3. The data layer reads approved data or cache, or the backend calls the approved provider with a secret the browser never sees. 4. The backend returns a defined response: the brief fields the UI is allowed to show, in a shape agreed in advance. 5. The frontend renders one of three honest outcomes: the result, an empty state ("no brief for this ticker yet"), or a useful error ("provider data unavailable — try again shortly").

When something breaks, this path tells you where to look. No result? Check what the browser sent. Wrong data? Check the backend rule and the data read. Secret exposed? The backend boundary was skipped.

What belongs where

Keep this separation strict from day one:

• Belongs in the browser: presentation, interaction, and local temporary state. The search box contents while typing, which tab is open, a collapsed panel, a client-side hint that "tickers look like 1–5 letters." All of it improves the experience; none of it protects the system.
• Must remain trusted on the server: secrets, authorization, privileged provider calls, payment actions, and sensitive data rules. Who may save to a private watchlist, which provider key pays for the data, what fields a signed-out visitor may see — those decisions run in backend code the user cannot rewrite.

Assume the person using the browser is curious, clever, and in a hurry. They can open developer tools, replay requests, and skip your interface entirely. Anything enforced only in the browser is a suggestion, not a rule.

View Source is not a vault

Here is the moment to internalize: code delivered to a browser is available to its user. Right-click, View Source, open the network tab — your JavaScript bundle, your API URLs, your hidden form fields are all inspectable. Hiding a button labeled "Admin refresh" does not protect the refresh action. Burying an API key in frontend code does not hide the key; it publishes it with extra steps.

Therefore an API key, an admin rule, or a private-data policy cannot be protected by merely hiding a button. If the browser can see it, the user can see it. Secrets live in the backend's protected configuration. Permissions are re-checked on every request. Private records are filtered server-side before anything crosses the network, never merely hidden with CSS after arrival.

Tell an agent "add live prices to the search page" with no boundary and it will take the shortest path: call the paid provider straight from the browser with your secret key. Fast demo, leaked credential, unbounded bill.

Practical exercise: label the boundary

Take any existing screen — Research Desk search is ideal, any dashboard works.

1. Screenshot or sketch it. Label every element as frontend, backend, data, external service, or cross-boundary contract (a place where two responsibilities agree, such as the shape of the brief response). 2. Ask an AI to propose corrections — but require it to explain each boundary: "For each label, say whether you agree, what evidence in the visible behavior supports your answer, and which file or request would prove it." 3. Record disagreements. Where you and the AI differ is exactly where your next task card needs a sharper contract.

Finish line: one request-flow diagram for a single user action (search for a company, using the five-step path above) plus a 10-line FEATURE-MAP.md naming the action, each responsibility it touches, and the contract between them.

Verify: cover the diagram and read only the FEATURE-MAP.md. Can a friend point to where the ticker is validated, where the secret lives, and what renders when the provider fails?

Common failure mode: labeling everything "frontend/backend" without naming the contract. "Backend returns data" is not a contract. "Backend returns ticker, companyName, summary, sources[] or an error class" is.

Check your understanding

1. Why is "build search" a dangerous AI task as stated? 2. Name the five responsibilities in the AAPL request path, in order. 3. Give one example of local temporary state and one thing that must stay server-side. 4. Why does hiding an admin button fail as a security control? 5. What must your FEATURE-MAP.md let a stranger locate without seeing the diagram?

Going deeper: MDN Learn Web Development — practical foundation for how browsers, requests, and pages fit together; MDN accessibility guidance — preview of the accessibility duties Lesson 45.2 makes concrete.