Hallucinated, not contracted, or not available: three different failures

When a drafted itinerary proposes a property you cannot sell, work out which of 3 things happened before deciding what to fix. The property may not exist at all. It may exist, be excellent, and be one you have no contract for. Or it may be a product you hold and cannot sell on those particular dates, because the allotment is gone, the release date has passed, or the season is closed.

These look the same in the document and share nothing else. The first is a retrieval failure, the second is a scoping failure, the third is a currency failure. A team that hardens retrieval and declares the problem solved will keep shipping the other 2 — and the second is the one that costs money, because it is the only one that passes every check a reviewer can run.

What each defect looks like on the page

The fourth row is a variant of the third and it is worth separating, because seasonality is usually held somewhere different from allotment — in a rate calendar, or in a supplier PDF, or in one person's head. The diagnosis for that one is the model that keeps proposing a place that is shut, and it is a genuinely different data problem from an exhausted allotment even though the client experience is identical.

The middle case is the expensive one

An invented hotel is embarrassing and cheap. It fails the first check anyone runs, and a consultant reading a draft for a region they sell will spot it immediately. A real property you do not hold fails nothing. The name is right because the model has seen it. The description is right. The location is right. It survives the review pass in checking an AI draft before it reaches a client precisely because every verifiable thing about it verifies.

Then the client reads the proposal and wants that hotel. You now have 3 options and none of them is good: buy it ad hoc at a worse rate with no allotment and no cancellation protection, substitute something else and explain why the itinerary changed before it was even confirmed, or hold the line and look like a business that does not know its own inventory. The damage is commercial, not technical, and it lands weeks after the defect was introduced.

The suggestion that hurts you is not the one that is obviously wrong. It is the one that is completely correct about a property you cannot sell.

Three controls, and why one never covers another

1. Constrain retrieval to your own products. The candidate set the model reasons over contains only rows from your contracted catalogue, with their seasons, allotments and terms — building that index is its own piece of work, described in indexing your own products so a model can find them. This kills the invented property and does nothing about the other 2, because the model can still name a hotel it knows in prose that was never retrieved.
2. Gate on resolution. Before a draft is stored or shown, every product-shaped noun in it must resolve to an id in your catalogue. Unresolved means blocked, not cleaned. This is the only control that catches the real-but-uncontracted case, and it is the one most implementations skip because retrieval feels like it should have handled it.
3. Check availability at draft time and again before sending. Allotment, release date, stop-sell and season, all read as facts rather than assumed — the field-level split behind that is set out in what grounded means when a model drafts a trip. The second check matters because a draft that sat in a consultant's queue for 4 days is quoting a 4-day-old answer, the same decay that makes the results price never the checkout price on any inventory-backed site.

The three are genuinely independent. A perfect index does not stop a model writing a famous property into a paragraph. A resolution gate does not know the room is sold out. An availability check does not care that the property was never yours. Any 2 of the 3 leave a live failure path, and it is always the path nobody is watching.

The suggestions worth keeping rather than suppressing

There is a real signal buried in the blocked suggestions. A model constrained to your catalogue, given a brief in a region where your coverage is thin, will keep reaching for the same handful of properties you do not hold — because they are the obvious answer to that brief. Suppressing them silently throws that away.

• Log every blocked property name with the brief that produced it, and count frequency by region and month. A name that appears 30 times in a quarter is a contracting conversation, not a bug.
• Separate the invented names from the real-but-uncontracted ones in that log. Only the second list is useful, and mixing them makes the whole thing look like noise.
• Show the consultant what was blocked, not just that something was. A consultant who can see the drafter wanted a property in a particular area can make the substitution deliberately instead of accepting whatever the constrained set produced.
• Feed the list to whoever owns supplier relationships on a schedule. Coverage gaps found this way are cheap to find and expensive to discover from a lost booking, and this is the one place a drafting system tells you something about the business rather than about itself.

Two adjacent failures are deliberately out of scope here. A price that nobody can find in the rate card is a different defect with a different trace, covered in the draft that quotes a number that is not in the rate card. And the end-to-end version, where one brief is followed field by field through a constrained drafter, is one brief run through a grounded drafter. Both sit inside letting a model draft the trip, and the controls above are ordinary MVP and product build work in our travel and tourism practice — a resolution gate is a database lookup, not a research project.

• inventory
• hallucination
• contracting
• itinerary drafting