# Meal plan mapping

Meal plans — what is included with a stay — are conceptually simple but encoded in a stunning variety of ways across partners. **Meal plan mapping** turns the partner's code into one of your canonical board basis values, so pricing, contracts and outbound feeds all speak the same language.

## What a meal plan is, canonically

The canonical board basis values that almost every partner uses, in some form:

| Canonical value         | What it means                                           |
| ----------------------- | ------------------------------------------------------- |
| **Room only**           | Stay only; no food included                             |
| **Bed & breakfast**     | Breakfast included                                      |
| **Half-board**          | Breakfast + one other meal (typically dinner)           |
| **Full-board**          | Breakfast + lunch + dinner                              |
| **All-inclusive**       | Meals + most drinks + often activities                  |
| **Ultra all-inclusive** | All-inclusive plus premium options (varies by property) |

Some partners include a few more — *Self-catering* for vacation rentals, *Continental breakfast* as a sub-distinction, *Drinks-only* for niche cases. Your canonical taxonomy is whatever set you choose to support; each partner's encoding maps into it.

## How partners actually encode meal plans

A small sample of how the same concept reaches you across sources:

* *Bed & breakfast* arrives as **BB**, **BNB**, **B\&B**, **BREAKFAST\_INCL**, **Bed and breakfast**, **Frühstück inkl.**, depending on the source.
* *Half-board* arrives as **HB**, **HALF\_BOARD**, **HALF-BOARD**, **DEMI\_PENSION**, **HP**, depending on the source.
* *All-inclusive* arrives as **AI**, **ALL\_INCL**, **ALLINCL**, **HER ŞEY DAHİL**, depending on the source.

Without mapping, your rate plans end up with a soup of codes that nobody can search consistently. With mapping, every code lands on one of your canonical values.

## What you map

For each canonical board basis value in your taxonomy, you list the source codes that correspond to it:

<figure><img src="/files/txoWZTugcSOVW5e0hOly" alt="Per-source meal plan codes fan into one canonical board basis"><figcaption><p>Source-specific meal plan codes (BB, B&#x26;B, Frühstück, Bed-Breakfast) all resolve to one canonical board basis.</p></figcaption></figure>

Once mapped, a rate that arrives from any of those codes lands on your canonical *Bed & breakfast* row. A rate going out to that source carries the right code in the outbound message.

## When a code is unrecognized

Partners send codes you have not mapped yet — either because they have a niche meal plan, or because they renamed an existing one. You handle this safely:

* The message **does not silently fail.** It is held in a curation queue with the unrecognized code visible.
* The property is **flagged** as having a meal-plan mapping gap so it shows up in your inbox.
* You decide: map the code to an existing canonical value, create a new canonical value if it really is a new concept, or mark the code as ignored if the partner is sending a category you do not support.

Until you decide, the rate is parked. As soon as you map, the queued messages process on the canonical row.

## How Adragent helps

Meal-plan mapping is one of the cleanest places to use Adragent because the universe is small and the matches are mostly obvious:

* "Map BB / B\&B / BREAKFAST\_INCL across all our sources to *Bed & breakfast*."
* "Show me every property where a meal plan code is unmapped."
* "Find canonical meal plans that are mapped on fewer than five properties — probably outliers."
* "Suggest mappings for the new codes that arrived this week."

The agent reads the same canonical taxonomy you do; suggestions are previews you confirm.

## What about per-channel exposure

A canonical meal plan does not have to be exposed to every outbound channel:

* A property might offer *Ultra all-inclusive* on direct sales but only *All-inclusive* on a public metasearch feed (premium options stay direct).
* A *Self-catering* canonical plan exists for vacation-rental properties and would be irrelevant in a hotel-focused B2B feed.

You decide which canonical meal plans go to which channels — the same per-channel exposure mechanism that controls rate plans, attributes, and content.

## Where to next

* **Reconciling room types in detail** → [Room mapping](/console/mapping-and-curation/room-mapping.md)
* **Reconciling amenity, category and feature codes** → [Attribute mapping](/console/mapping-and-curation/attribute-mapping.md)
* **The pricing engine that consumes these mappings** → [Pricing engine](/console/pricing-and-availability/pricing-engine.md)
* **What happens when a partner sends a meal-plan-bearing message at runtime** → [Connector bindings](/console/mapping-and-curation/connector-bindings.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://adrasis.gitbook.io/console/mapping-and-curation/meal-plan-mapping.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
