Slot filling is the mechanism by which a dialogue system collects the specific values needed to fulfill an intent. BookFlight needs origin, destination, and departure_date. GetAccountBalance needs account_number and possibly a date range. Every piece of information required to complete an action is a slot; the process of extracting those pieces across multiple turns is slot filling. It sounds straightforward. It is not. Slot schema design errors are the most common cause of multi-turn dialogue failures after coreference resolution problems, and the failure modes are subtle enough that they often manifest as mysterious bot behavior rather than visible errors.
Required vs. Optional vs. Conditional Slots
The first design decision in slot schema definition is cardinality. Required slots must be filled before the intent can be fulfilled - missing them means the system must ask the user. Optional slots have defaults or can be omitted without affecting fulfillment. Conditional slots are required only if another slot has a specific value: if payment_method is "credit card," then card_number and expiry_date become required; if payment_method is "account balance," they are irrelevant.
Misclassifying a conditional slot as always-required is a common schema mistake that produces excessive clarification turns. A flight booking bot that always asks for a seat preference when 70% of users are satisfied with any available seat is adding unnecessary turns for the majority to serve the minority. Make seat_preference optional with a default value; ask for it only when the user has demonstrated a preference in prior turns or explicitly requests it.
Misclassifying a required slot as optional is the opposite failure: the system attempts to fulfill an intent without all the needed information, produces a partial or incorrect result, and the user has to correct it in a follow-up turn. This typically manifests as the system making assumptions that seem reasonable (defaulting departure_date to today when no date was specified) but are wrong often enough to generate frustration.
Slot Interdependencies and Validation
Slots within an intent are often not independent. A departure_date and return_date must be ordered correctly: return cannot precede departure. A seat_count must not exceed available seats for the flight. An expiry_date must be in the future. These are cross-slot constraints that must be validated during slot filling, not after intent fulfillment attempt.
Inline validation - checking constraints as slots are filled - prevents errors from accumulating across turns. If departure_date is filled, validate that it is in the future. When return_date is filled, validate that it is after departure_date. When seat_count is filled, validate against availability. Each validation failure generates a targeted clarification prompt for the specific constraint that was violated, rather than a generic "something went wrong" error after the fulfillment attempt fails.
Inline validation requires that slot constraints are explicitly modeled in the schema, not embedded in downstream business logic. Business logic that validates constraints after slot collection is filling turns a single validation failure into a multi-turn correction cycle: the user completes all slot filling, the system attempts fulfillment, the fulfillment fails, the system backtracks to ask the user to correct a specific value. This is a poor experience that schema-level validation prevents.
Handling Partial Fills and Incremental Slot Collection
Users provide slot values in unpredictable orders and often provide multiple values in a single utterance. "I need a round trip from New York to London, leaving March 15, coming back March 22, for two people" provides five slot values at once: trip_type, origin, destination, departure_date, return_date, and passenger_count. The slot filling model must extract all five from a single utterance and mark all as filled before checking for missing required slots.
Incremental slot collection means that slot values may arrive in any order across multiple turns. The system should accept and store slot values whenever they are provided, regardless of whether prior required slots are filled. A user who mentions the return date before the departure date is not making an error - they are providing information in their natural order of salience. The system should accept the return date, hold it, and later validate it against the departure date when that slot is filled.
Partial fills also arise from extraction ambiguity. A user who says "March" without a day is providing a partial date. The slot filling system must represent partial slot values explicitly: departure_date = {month: 3, year: 2026, day: null}. A null field in a partial value is a prompt trigger: the system asks for the missing day. A system that discards partial values and treats the slot as empty misses the information that was provided and forces the user to repeat themselves.
Slot Value Conflicts Across Turns
Slot value conflicts occur when the user provides two different values for the same slot in different turns. "I need to fly on Tuesday" followed by "actually, make it Wednesday" is a conflict that should resolve cleanly: the newer value wins, and the system confirms the update. "I'm traveling with three people" followed by "and my wife will join us, so four total" is a conflict that requires arithmetic: the newer value (4) supersedes the older value (3) by explicit user correction.
The hard case is implicit conflict: the user provides a value consistent with one intent and then provides new information that implies a different value for a prior slot. "I want the aisle seat" followed by "I'm traveling with a small child - what would you recommend?" should not necessarily update the seat preference to something else, but it might prompt the system to offer information about family seating options that could cause the user to revise their preference.
Conflict resolution policy should be explicit in the schema: for each slot, define whether newer values automatically supersede older ones (update semantics), whether both values should be retained pending explicit user selection (queue semantics), or whether conflicts should trigger a clarification prompt. Different slot types warrant different policies: date slots typically use update semantics; preference slots may warrant clarification when the revision reason is unclear.
Inter-Intent Slot Propagation
As we explored in our article on building intent graphs, slot values from one intent can and should propagate to related intents. When a user books a flight and then books a hotel for the same trip, the destination slot from BookFlight should propagate to BookHotel's location slot. When a user cancels a booking and immediately tries to rebook, the original booking's slot values should initialize the rebooking flow. This propagation is automatic when intent graphs are used and completely absent when intents are classified independently.
Propagation requires explicit slot mapping rules: which slots from IntentA map to which slots in IntentB, and under what conditions. These rules are part of the schema definition, not the NLU model. They are deterministic: given the same context and intent graph, the same slots always propagate. This predictability is essential for debugging: when propagation produces unexpected results, the schema rules are the correct place to look, not the NLU model.
Designing Schemas for Maintainability
Slot schemas grow over time. New product features add new required slots. New user behaviors surface new conditional dependencies. The schema must be maintainable: changes to one intent's schema should not silently break others. Versioned schema definitions - where each slot schema has an explicit version and intent handlers declare which version they consume - prevent breaking changes from propagating unexpectedly. Schema migration tooling that validates that all active sessions' context objects are compatible with the new schema prevents deployment failures when schemas change.
Conclusion
Slot schema design is dialogue system design. A poorly designed schema produces systems that ask too many questions, ask the wrong questions, lose values that users have already provided, and conflict with themselves when users revise prior answers. A well-designed schema - with explicit cardinality, inline validation, partial fill representation, conflict resolution policies, and inter-intent propagation - produces systems that feel like they are paying attention. The NLU model quality matters. The schema design matters more for the multi-turn experience that users actually encounter.