                    ┌─────────────────────────────────────┐
                    │          Event Model                │
                    │                                     │
                    │  ┌───────────┐  ┌───────────┐       │
                    │  │  Slice 1  │  │  Slice 2  │  ...  │
                    │  │ STATE_    │  │ STATE_    │       │
                    │  │ CHANGE    │  │ VIEW      │       │
                    │  └───────────┘  └───────────┘       │
                    │         │              ▲            │
                    │         │  (events)    │            │
                    │         └──────────────┘            │
                    └─────────────────────────────────────┘

Slice Types

Three types. Every behavior in the system fits one:

STATE_CHANGE — user does something

Screen → Command → Event
Command produces one or more events
May have error events for failure paths

STATE_VIEW — system shows something

Events → Read Model → Screen
Read model aggregates data from one or more events

AUTOMATION — system reacts to something

Event → Processor → Command → Event
Background process, no user interaction

See references/slice-types.md for element rules, dependency patterns, and naming conventions.

Conversational Design Process

Work with the user through these phases. Move at the user's pace — they might want to go deep on one slice before seeing the full picture.

Phase 1: Understand the Domain

Identify aggregates (core business entities), actors, and high-level use cases. Ask about the business processes, not technical implementation.

Phase 2: High-Level Model

Draft all slices without field details. Show the flow between them — which events feed which read models, which screens lead to which commands. This is the "map" of the system.

Format as a markdown document with one section per slice. Include slice type, aggregate, elements, and how slices connect.

Phase 3: Slice Detail

Walk through one slice at a time. For each:

Define fields with types and example values
Identify business rules (not simple validations — real domain rules)
Write specifications as Given/When/Then scenarios

Phase 4: Executable Specifications

Turn specifications into approval fixture files using the bdd-with-approvals skill. That skill teaches how to:

Design scannable fixture formats adapted to the domain
Structure input/output for human validation
Build parsers and formatters

Read that skill when it's time to design fixtures. The event model specs (Given events / When command / Then events) map naturally to the approved fixture pattern.

Analyzing Existing Code

When working with an existing codebase instead of greenfield:

Read the code to extract domain concepts
Map existing operations to slice types (writes → STATE_CHANGE, reads → STATE_VIEW, background → AUTOMATION)
Put code references (class names, packages) in element descriptions
Extract specs from unit tests and comments

Output Format

Produce markdown, not JSON. Design for human readability — someone should look at the model and understand the system.

Write model artifacts to files. Ask the user where they want them (e.g., docs/event-model.md). Update the files as the model evolves through conversation.

High-Level Model

One document showing all slices and their relationships:

# [System Name] Event Model

## Aggregates
- Owner — pet owners who use the clinic
- Pet — animals registered to owners

## Slices

### Register Owner [STATE_CHANGE]
Aggregate: Owner
Screen: Owner Registration Form
Command: Register Owner → Event: Owner Registered
Error: → Owner Registration Failed

### View Owner Profile [STATE_VIEW]
Aggregate: Owner
Events: Owner Registered, Pet Registered → Read Model: Owner Profile
Screen: Owner Profile

### Notify Vet of New Patient [AUTOMATION]
Trigger: Pet Registered → Processor: New Patient Notifier
Command: Send Notification → Event: Vet Notified

Detailed Slice

Per-slice detail includes fields and specifications:

## Register Owner [STATE_CHANGE]
Aggregate: Owner

### Command: Register Owner
  firstName: String — "George"
  lastName: String — "Franklin"
  address: String — "110 W. Liberty St."
  city: String — "Madison"
  telephone: String — "6085551023"

### Event: Owner Registered
  ownerId: UUID — <generated>
  firstName: String — "George"
  lastName: String — "Franklin"
  address: String — "110 W. Liberty St."
  city: String — "Madison"
  telephone: String — "6085551023"

### Event: Owner Registration Failed
  errors: Map — {"lastName": "required"}

### Specifications

#### Successfully register with valid data
Given: (no prior state)
When: Register Owner
  firstName: George, lastName: Franklin
  address: 110 W. Liberty St., city: Madison
  telephone: 6085551023
Then: Owner Registered
  ownerId: <generated>, firstName: George, lastName: Franklin

#### Fail when required fields missing
Given: (no prior state)
When: Register Owner
  firstName: George, city: Madison
Then: Owner Registration Failed
  errors: {address: required, telephone: required}

#### Business rules
- All fields mandatory: firstName, lastName, address, city, telephone
- Telephone must be numeric, max 10 digits

These are defaults. Adapt the format to the domain — what matters is that a person can scan it and quickly validate correctness.

Anti-Patterns

Technical language in element names ("insertOwnerRecord" → "Register Owner")
Skipping STATE_VIEW slices — every query/display is a slice
Circular dependencies between elements
Specs that test simple validation ("must be a number") instead of business rules
Jumping to fixture format before the model is understood
Combining multiple commands in one slice — one command per STATE_CHANGE

event-modeling

What Event Modeling Produces