Cascade corrections in conversational booking

Cascade-aware correction is a booking-form pattern in which editing one field clears every downstream field that depended on it. Typelessity declares dependencies in config (dependsOn), walks them depth-first when a filled field changes, asks the user before clearing anything, and drops the enrichment results that read a cleared field. Read how it works for the full extraction pipeline.

The bug this prevents

Consider an auto repair booking. A customer says "Brake pads for my RAV4 on Friday at 2pm." The widget extracts service=brake_pads, date=Friday, time=14:00, calls the shop's enrichment API, and offers a mechanic who does brakes and a slot with them. On the review screen the customer changes service to "timing belt." Nothing else.

Without dependency tracking, the mechanic and the slot stay. The booking ships with a brakes mechanic's slot under a timing-belt job, and the shop's backend either rejects it or books the wrong person.

The fix: changing service has to clear mechanic, and clearing mechanic has to clear slot. That relationship has to be written down somewhere the engine can read it.

Bottom line: in any extraction system with cross-field dependencies, an edit without a cascade is an undetected bug.

What is a cascade-aware correction?

A cascade-aware correction is a mid-booking field edit that clears every downstream field that depended on the edited one. The enrichment results fetched for the old value are dropped too, so the options the user sees next match the new value. Before any of this happens, the user is told which fields will be cleared and asked to confirm.

This is the difference between a booking flow that survives mid-edits and one that ships broken bookings.

How does Typelessity model field dependencies?

Field relationships are part of the config. Each field can list the fields it depends on:

{
  "fields": [
    { "id": "service" },
    { "id": "date" },
    { "id": "mechanic", "dependsOn": ["service"] },
    { "id": "slot", "dependsOn": ["mechanic", "date"] }
  ]
}

A field filled from an enrichment also depends on that enrichment's inputs: if the mechanic list is fetched with the chosen service, mechanic depends on service even without the explicit line.

When a filled field changes, the engine builds the reverse map — for each field, the fields that depend on it — and walks it depth-first from the changed field. Every field it reaches that already holds a value goes on the list to clear. The dependency graph is in config, not in code, so a new kind of business does not need changes to the orchestration layer.

Bottom line: cascade behaviour is config-driven. The same engine handles an auto repair shop and any other business that takes bookings because the dependency shape lives in config alongside the field schema.

Why not just clear every later field?

Two reasons.

1. Most fields are independent. Editing phone_number should not clear slot. Editing passenger_name should not clear pickup_location. Indiscriminate clearing makes the user re-enter data they did not change, and that is exactly the friction that conversational booking is supposed to remove.
2. Enrichment APIs are not free. Each cleared field that feeds an enrichment means another call to the business's backend, and each call can take up to its timeout — 10 seconds by default. Clearing fields that did not change wastes those calls and the user's time.

Targeted invalidation respects the user and the network. The dependency graph is the unit of restraint.

How is the reset surfaced to the user?

The user is asked before anything is cleared. If the change would clear fields that already hold values, the widget replies:

"Changing Service will also clear: Mechanic, Time slot. Do you want to proceed?"

The field names come from the labels in the config. The fields are cleared only after the user agrees. If nothing downstream holds a value yet, there is nothing to lose, and the new value is taken without a question.

The UX rule is older than the algorithm: a state change the user did not initiate must be explained in plain language before it happens. Silent state changes feel like bugs.

Bottom line: the graph walk decides what to clear; the question to the user is what makes it usable.

Where does cascade-aware correction generalize?

Any extraction system with cross-field dependencies has the same problem:

• Lead-capture forms with state-dependent dropdowns (state → city → ZIP).
• Tax software with line items that affect totals.
• Booking systems with capacity constraints (date → vehicles available → drivers available).
• Multi-step intake where later questions depend on earlier classifications.

The mental model: fields are not independent variables. Treat them like a spreadsheet — when a cell changes, recalculate the dependents. A spreadsheet without dependency tracking is a grid of typos. A booking flow without it is the bug at the top of this article.

FAQ

What is a cascade-aware correction in a booking flow? An edit that clears every downstream field that depended on the edited one. Typelessity uses a config-declared dependency graph, walks it depth-first when a filled field changes, and drops the enrichment results that read a cleared field.

How does Typelessity model field dependencies? Each field can declare a dependsOn list in config, and a field filled from an enrichment depends on that enrichment's inputs. The orchestration layer reads this graph at runtime — no per-business code, no hardcoded relationships.

Why not just clear all later fields when one changes? Indiscriminate clearing makes the user re-enter unrelated data and wastes enrichment calls. Targeted invalidation only touches fields that actually depended on the edited one.

What does Typelessity tell the user before a cascade clears fields? If any dependent field already holds a value, the widget asks first — "Changing Service will also clear: Mechanic, Time slot. Do you want to proceed?" — and clears the fields only after the user agrees.

Where else does cascade-aware correction apply? Any extraction or intake system with cross-field dependencies — lead capture, tax software, multi-step booking with capacity constraints. The pattern is the spreadsheet model applied to forms.

For the extraction call that produces the initial fields, see Why we replaced the booking form with a single GPT call. For the latency target that enrichment calls count against, see Latency budgets. For the four phases end to end, see How it works.

— Alex Isa, founder of Typelessity. Also founder of Webappski and TypelessForm.