Lesson 46.1 gave you a small set of boxes. This lesson draws the lines between them — because architecture is not just boxes. Every line between boxes carries an agreement, and every agreement carries a failure mode.

This builds directly on Part X, where interface contracts let parallel workers build compatible pieces. There, the contract was a planning tool. Here, it becomes the architecture itself: the deliberate dividing line between responsibilities.

A boundary is a deliberate dividing line between responsibilities, with a clear contract governing what crosses it. The contract says what shape crosses, who owns the definition, what happens when input is missing or invalid, and how both sides prove they agree.

Six boundary types you will actually meet

Small apps reuse the same six boundaries. Learn to tell them apart, because each fails differently:

A queue unused is not "future-proofing." A webhook without signature verification is not an integration. Name only the boundaries your flows actually cross, and contract each one.

Follow one object across the boundaries

Take the ResearchBrief — the heart of Research Desk. Watch it travel:

1. The UI requests a ResearchBrief and renders it. It does not know there are two upstream providers with incompatible field names. 2. The backend owns authorization and source selection. It validates the ticker, checks the caller's rights, enforces quota, and decides which sources qualify. 3. A provider adapter turns provider-specific data into the app's internal shape. Provider A calls it headline; Provider B calls it title; the adapter emits title in both cases. 4. The database stores the watchlist and cached snapshots — not five provider formats, just the one agreed shape.

The frontend never parses five provider formats. That is the whole point: provider quirks stop at the adapter and never leak into pages, caches, or watchlists.

The adapter: a small layer with a large payoff

An adapter is a small layer that translates a provider's vocabulary into the application's vocabulary. It is one function or module with one job: provider shape in, app shape out — plus explicit handling for missing fields, rate limits, and timeouts.

Why it matters: providers change field names, deprecate versions, throttle aggressively, and disagree about dates. Without an adapter, every one of those quirks spreads into your routes, your database writes, and your UI. With an adapter, you change one module, update its fixture, and the rest of the app never notices. Switching or adding a source becomes a bounded task instead of a rewrite — which is exactly the kind of bounded task AI workers handle well.

The 8-item contract checklist

Every boundary contract — UI, API, schema, adapter, queue, or webhook — must answer these eight questions:

1. Owner — who may change this definition? (Name a role, not "whoever touches it.") 2. Input shape — exact fields, types, required versus optional. 3. Output shape — exact fields the other side may rely on. 4. Error behavior — named failures and what each side does next (retry, show message, drop, alert). 5. Limits and timeouts — size caps, rate limits, how long to wait before giving up. 6. Version and change rule — how a change is announced, and what compatibility is promised. 7. Test fixture — a concrete sample both sides build and test against. 8. What must never cross — secrets, raw provider internals, other users' private rows, invented data.

If any answer is "we'll figure it out," the boundary is fuzzy — and fuzzy boundaries are where AI agents collide.

Why agents collide at fuzzy boundaries

Imagine three agents working from a vague "brief object." Agent one changes database fields to match Provider B. Agent two changes the API response to match Provider A. Agent three rewrites the UI wording to match a screenshot. Each change is reasonable alone. Together they produce three incompatible versions of the same idea, and integration fails in ways no single diff explains.

Contracts prevent this. When the ResearchBrief note names the owner, freezes the shape, and ships a fixture, each agent builds against the same truth. Review then checks conformance to the contract instead of guessing which agent was right.

Practical exercise: the ResearchBrief note plus fixture

Write an interface note for ResearchBrief (in contracts/research-brief.md or beside your API contract):

• A small JSON example with ticker, companyName, summary, and sources[], each source carrying title, url, publishedAt (nullable), and publishedAtStatus (known or unknown).
• Null and absence rules: when publishedAt is missing, send null plus "publishedAtStatus": "unknown" — never an empty string, never an invented date.
• Source attribution requirements: every factual claim renders at least one source link; no unattributed numbers cross into the UI.
• One compatibility promise: e.g., "v1 adds only optional fields; renames require a new version and a migration note."

Then create one test fixture — a sample ResearchBrief JSON file — that both frontend and backend work import. The UI renders it in known and unknown-date states; the API test asserts its routes return that shape.

Finish line: one reviewed ResearchBrief contract and one shared test fixture that both sides use.

Verify: change one fixture field and run both sides' checks. Both should fail together — proof they share one truth. If only one side fails, the other side was never really contracted.

Common failure mode: documenting the happy-path shape but skipping null rules, error behavior, and the never-cross list. Those three are where real integrations break.

Check your understanding

1. How does this lesson's boundary differ from the Part X interface contract? 2. Name the six boundary types and give the Research Desk example of each. 3. What crosses the adapter in each direction, and what stops there? 4. Recite the 8-item checklist from memory — which item do AI workers most often skip? 5. Why do three agents with no shared fixture produce three incompatible "briefs"?