Skip to content

Designing TTYT-apps

This guide helps you design well-structured TTYT-apps. You will learn how to model your domain, structure your data, and write business rules that control how your app behaves.

It is aimed at people with App Builder rights who want to go a level deeper than the basics of building an app.

Info

If you are new to TTYT-apps, start with the Building and Managing TTYT-apps guide and then come back here for more detailed design guidance.

What Is a TTYT-app?

A TTYT-app is a conversational, rule-driven application backed by a micro-Postgres database. Each app is defined by an AppDefinition, which describes:

  • The data structure: entities, attributes, relationships, and constraints.
  • The business rules: how AI agents should interpret data and respond to events.

Put differently, your AppDefinition is the blueprint that keeps the conversation grounded and predictable.

Core Building Blocks

A good TTYT-app design starts with a clear structure:

  • Entities: The core objects or concepts in your domain (for example, User, Subscription, Magazine).
  • Attributes: The details you need to remember about each entity (for example, a user’s name, email, or subscription status).
  • Constraints: Rules that keep data valid (for example, an email must be unique, an amount must be positive).
  • Relationships: How entities relate to each other (for example, a subscription links a user to a magazine).
  • Rules: The logic that controls behaviour (for example, who can do what, when a status can change, or what to do when something is missing).

These building blocks work together to give AI agents enough structure to make reliable decisions.

Model Your Domain

Define Entities and Relationships

  • Identify the main entities in your domain. For a magazine subscription service, you might start with User, Magazine, and Subscription.
  • For each entity, list the attributes you care about, such as names, contact details, prices, and statuses.
  • Decide how entities relate to each other. For example, a user may have many subscriptions, and a subscription belongs to exactly one user and one magazine.

Note

If you are unsure where to start, describe your process in one or two sentences. The nouns you use are often good candidates for entities.

Avoid Many-to-Many Pitfalls

Many real-world relationships are many-to-many. Rather than modelling these directly, look for the concept that sits in the middle.

For example:

  • Instead of connecting User and Magazine with a many-to-many link, add a Subscription entity.
  • Subscription then carries the business meaning: start date, end date, status, and pricing.

This makes your model clearer, easier to reason about, and simpler to extend over time.

Good Domain Modelling Practices

  • Keep each entity focused on a single concept.
  • Use relationships deliberately and name them clearly.
  • Prefer explicit entities (such as Subscription) over vague many-to-many links.
  • Add constraints where they reflect real-world rules, not just technical limits.

Write Effective Business Rules

Once your domain is in place, you can define the rules that drive behaviour. In TTYT, rules are the main way to control how your app reacts to user actions and changes in data.

Descriptive Rules

Descriptive rules express facts, policies, and constraints about your data. They do not describe a sequence of steps, but rather what must always be true.

Examples:

  • “Every active user must have at least one active subscription.”
  • “Only admins can delete magazines.”
  • “A subscription end date cannot be earlier than its start date.”

These rules keep your data trustworthy and aligned with your real-world policies.

Behavioural Rules

Behavioural rules describe what should happen when something changes. They define the dynamic behaviour of your app.

Examples:

  • “When a new user is created, automatically create a default subscription.”
  • “Before handling a user request, always check their subscription status.”
  • “When a subscription is cancelled, notify the relevant account manager.”

Behavioural rules make your app feel responsive without needing a traditional BPMN-like flow.

Tips For Writing Rules

  • Be specific but reusable. A rule such as “On user creation, ensure the default setup exists” can cover multiple setup actions over time.
  • Combine descriptive and behavioural rules. Use descriptive rules to protect the structure, and behavioural rules to define what happens in response to events.
  • Keep rules small and focused. It is easier to understand and adjust several simple rules than one very complex rule.

Warning

Rules that change data can have broad impact. When you refine or add rules, test changes in a sandbox branch first and review the resulting behaviour in your tables and conversations.

Bringing It All Together

Designing a good TTYT-app means combining solid domain modelling with clear, well-defined rules:

  • Start with entities, attributes, relationships, and constraints that reflect your real-world process.
  • Add descriptive rules to keep data accurate and aligned with your policies.
  • Add behavioural rules to control how the app responds to user actions and data changes.

Together, these pieces form a flexible AppDefinition that AI agents can use to drive consistent, predictable conversations.

For guidance on deploying and iterating on your design in sandbox and live environments, see the Building and Managing TTYT-apps guide.