Boundaries

The most common architectural mistake is trying to turn ToonUI into a workflow engine.

Do NOT do that.

Ownership map

Why the boundary exists

If prompts start deciding product behavior, you lose clarity FAST.

You also lose:

• testability
• security boundaries
• explicit ownership
• maintainable architecture

The model should describe the interaction surface.

Your application should decide what that interaction actually does.

Good boundary example

Model output:

button secondary "Open customer" reply="open:customer-42"

Then the flow is:

1. ToonUI parses the button
2. ToonUI renders the button
3. the user clicks it
4. ToonUI creates a typed payload
5. your app decides whether to fetch data, deny access, log the action, or open a new UI state

That is the correct split of responsibility.

Bad boundary example

Bad mindset:

• "the model executes the customer workflow"
• "the ToonUI block decides mutations"
• "the prompt owns behavior"

If that happens, you no longer have a UI protocol.

You have hidden application logic inside generation.

That is fragile, hard to test, and hard to trust.

Design rule

Use ToonUI for:

• expressing interface intent
• structuring AI responses
• capturing user intent cleanly

Use your app for:

• deciding behavior
• calling tools
• enforcing permissions
• managing product state

Next step

1. Package Architecture
2. Events and Messages
3. Protocol and Types