Drafts that put a closed property on day four: fixing seasonal blindness

The season is in your prose and not in your metadata. That is the whole finding in most of these cases: the product description says the lodge closes for the wet months, or that the pass is shut in winter, and the retrieval query has no date bound at all — so nothing was ever excluded, and the model chose a component it was legitimately offered. Adding a sentence to the prompt about checking seasonality changes the wording of the draft and not the candidate set.

Keep this apart from supply. A property that is open but sold out, or on stop-sell, or out of allotment, is a different failure with different owners — the distinction is drawn in is a blackout the same thing as a stop sell. Seasonal blindness is about the 2 cases where the place is shut to everyone: the site itself is closed, or the way in is.

Six kinds of shut, and only two of them reach your rate sheet

Only the annual maintenance closure and, sometimes, the activity suspension arrive with the contracted rates. The other 4 have to be gathered and maintained deliberately, which is the real cost of fixing this and the reason it gets patched with prompt text instead. A 7th case behaves like a closure and is modelled differently: the property is open on those dates and the only road to it is not, which no field on the property itself can express.

One query with the dates bound tells you which layer is broken

1. Take the offending draft. Note the component identifier and the calendar date it was placed on — not day 4, the date that day 4 resolves to.
2. Re-run retrieval for that brief with the travel dates bound as a hard filter. If the component still comes back, it carries no structured dates and the investigation is over.
3. Open the row. Find where the closure is actually recorded. In most systems it is a clause inside a paragraph written for a brochure, which is unfilterable by construction.
4. Check whether the closure sentence was even retrieved. Chunked prose competes on similarity, and the passage about the infinity pool routinely outranks the passage about the wet season.
5. Log the query's filters, not only its text. Teams are often surprised to find the date filter was dropped somewhere between the brief parser and the retrieval call.
6. Repeat over 10 drafts across 3 destinations and count failures by region. Clustering in 1 region means data coverage; even spread means the query, and those are different backlogs.

The fields that make a season filterable

The unit that carries these fields is one sellable component, not a document — the argument for that unit is in indexing your own products so a model can find them. Onto each component, add the following.

Filter the candidate set; stop instructing the model about seasons

With the fields in place, the fix is a hard filter in the retrieval query rather than a line in the prompt: every candidate must be open across the dates it would occupy, and every access dependency must be open too. The general mechanics of pushing date and category constraints into the query itself are in metadata filters in a retrieval query.

• Filter on the dates the component would be used, not the trip's start date. A 14-day itinerary starting on 26 September can cross 2 seasons, and day 12 is where this bites.
• Treat unknown as excluded for automatic drafting. A component with no seasonality data is not open; it is unverified, and a consultant can override that in seconds.
• Expand the filter to dependencies. If the pass component is shut, everything whose accessDependencies name it is shut too, regardless of what the property says.
• Keep a second net after generation. A validator that rejects a draft placing a closed component on a date is the same shape as the pacing validator in six stops and nine hours of driving on day two, and it catches the case where the filter was correct and the assembly was not.
• Do not rely on the model's own knowledge of a destination. It has read a great deal about famous places being open, and general knowledge outranks a sentence buried in your product copy every time.

You cannot prompt your way out of a candidate set. If a shut property is in the list the model chooses from, sooner or later it is in the itinerary, and the only durable fix is that it never appears.

What the filter cannot know, and who covers it

A date filter answers only what somebody recorded. It does not know that this year's opening has not been announced yet, that a landslide shut the route last week, that a park closed a zone early, or that entry is capped by a permit quota rather than a gate. Those belong to the review step, which is why the reviewer must see the source and the date beside every seasonal claim rather than a green tick — the queue design is in the consultant review step before a client sees a draft, and a full brief traced through retrieval, drafting and validation is worked through in one brief run through a grounded drafter.

There is also decay to plan for. A component that was open when the draft was built can be shut by the time the client accepts, which is the same class of problem as a held price expiring between basket and confirmation — the failure mode described in booking fails on an expired token mid-checkout. Carry the verification time with the claim, and re-check seasonality at the point the itinerary is confirmed rather than only when it is written.

Keeping the closure data alive without a person reading notices

The maintenance burden is what kills this work, so automate the watching and not the deciding. A scheduled job polls the pages where closures are published — park authorities, road authorities, supplier notices — detects that the text has changed since the last hash, and opens a task with the diff attached. A person confirms the new dates, and only then does the record change, with the source and confirmation date stamped on it. That propose-then-confirm split is the pattern we use for most AI agents and automation work, for the reasons set out in AI in logistics operations: it earns its place by watching 200 sources nobody would read weekly, and it is safe because it changes 0 records on its own.

Two habits make the rest of it hold. Record closures against the component that is actually shut, not against the trip that mentioned it, so 40 itineraries update from 1 edit. And review the seasonality coverage by region each season, because the destinations where drafts fail are the destinations where nobody has loaded the data — the same conclusion the counting step above reaches. The rest of the guardrail set sits in letting a model draft the trip, within our wider travel and tourism work.

• seasonality
• retrieval
• itinerary drafting
• metadata