You now own the full Part VII vocabulary. Say it back in one breath, because the next part of the course — agents — assumes all of it:

• A user request is served by a function: short-lived code that wakes on demand, answers, and ends.
• A data refresh starts on cron: the clock fires at a planned time whether or not the world changed.
• An incoming event arrives by webhook: an outside service knocks because something happened.
• A heavy task enters a queue: the waiting line that absorbs bursts and retries.
• A worker performs it: the background program that does the slow work outside any user's wait.
• State and logs live in durable services: the database, object storage, and log stream that outlast every individual execution.

Six words, six jobs. Every product in this course from here on is some arrangement of those six.

Sonariq, assembled

Watch them work together in the Sonariq-style financial-research system you have followed since the Data section:

• Scheduled refreshes collect factual inputs. A cron trigger fires after the expected release window — SEC filings daily, macro series on their release cadence. Each firing enqueues a job; a worker fetches the source, stores observations with source, timestamp, and units, and flags a missing update instead of inventing one.
• A user request reads prepared data. A visitor asks about a company. A function reads the stored filings, metadata, and macro context from Postgres, calls a model only if fresh synthesis is needed, and returns a cited answer in seconds. Nothing is scraped live during the request.
• Report generation becomes a background job. The visitor clicks "build full report." The function writes a job row, enqueues it, and answers immediately: "report queued." A worker gathers evidence, composes the report, saves it to the database and object storage, and flips the status to ready.
• Source and status changes can produce events. A data provider alert arrives by webhook — a filing amended, a series revised. The endpoint verifies, records the event ID, and enqueues a targeted re-check rather than rebuilding everything.
• Database state makes every step inspectable. Filings, observations, criteria, reports, jobs, events: each is a row with an owner, a timestamp, and a status. A reviewer — human or agent — can trace any visible result back to the trigger that caused it and the data it read.

No step is magic. Each arrow has a reason.

Architecture is boundaries

Beginners draw architecture as boxes with arrows and call it done. The boxes are the easy half. The arrows are the architecture — and every arrow needs five answers:

• Trigger: what started this — a user request, a time, or an outside event?
• Input: what data crosses the boundary, exactly?
• Output: what new fact, file, or message results?
• Owner: which function, worker, or service performs it, and with what credentials?
• Failure response: what happens when it fails — retry, dead-letter, alert, visible stale-mark?

An arrow without those answers is a wish. "The app updates the report" is a wish. "Cron fires at 18:00 → enqueue refresh-filings with {date} → worker fetches EDGAR, writes observations → on failure retry twice, then flag stale and alert the owner" is a boundary. Lesson 27.2 taught you to choose the trigger; Lesson 27.3 taught you to guard the event arrow; Class 26 taught you to carry load in queues. Now write all of it down before automating any of it.

The event-to-action template

Use this row shape for every behavior in your product. One row per trigger — no shared rows, no "and then various things happen":

A Sonariq row, as an example:

Three to five such rows describe most first products completely. If you need twelve, your product is probably three products.

Preview: agents stand on this floor

Here is why this part came before agents. An agent — the subject of Part VIII — is a decision loop that uses tools, remembers context, and takes actions under control policies. But every one of those actions runs on *this* floor:

• Its tool calls arrive as requests served by functions.
• Its recurring checks run on schedules.
• Its reactions to the world arrive as events through endpoints like the ones you just designed.
• Its long tasks belong in queues with workers, or costs and timeouts will eat it alive.
• Its memory is durable state — rows and files, not vibes.
• Its mistakes are found in logs, the same logs Class 26 demanded.

Infrastructure is the floor agents stand on. A builder who can map trigger → bounded action → data → observable result can give an agent a safe surface to act on. A builder who cannot will give an agent an open door and hope. Lessons 27.1–27.3 were the doorbell, the choice of knock, and the lock. This lesson is the floor plan.

Check your understanding

1. Without looking back: define function, cron, webhook, queue, worker, and durable state in one sentence each. 2. Pick any arrow in your product and answer all five boundary questions for it. 3. Why does an agent need the same execution surfaces this class taught?

Exercise: draw the map

Create EVENT-TO-ACTION-MAP.md for one project. Include at least one user request, one scheduled job, and one optional event/webhook. Do not implement anything — make the responsibilities clear first.

# EVENT-TO-ACTION-MAP.md — [product name]

## Row 1: [name] (user request)
- Trigger:
- Entry point:
- Immediate action:
- Background action:
- Data read / written:
- User-visible outcome:
- Verification & failure plan:

## Row 2: [name] (scheduled)
- Trigger:
- Entry point:
- Immediate action:
- Background action:
- Data read / written:
- User-visible outcome:
- Verification & failure plan:

## Row 3: [name] (event / webhook, or "none yet")
- Trigger:
- Entry point:
- Immediate action:
- Background action:
- Data read / written:
- User-visible outcome:
- Verification & failure plan:

Finish line: a reviewer can trace every trigger to a bounded action, a data change, and an observable result — without reading any code.

Verification: for each row, the reviewer asks three questions: *what starts it, what does it change, how would I know it worked?* If any answer requires guessing, the row is incomplete. When all three rows answer cleanly, Part VII is complete — and Part VIII's agents have a floor worth standing on.