Layout templates (blueprints) module — JetSetGo MCP reference

The blueprints module manages layout templates: reusable capacity structures that model how a physical space holds bookable capacity. A template is a tree of nested capacity units (IHU, Inventory Holding Unit) covering containers such as decks and areas down to leaves such as seats, lanes, and cabins. Templates hold no live capacity themselves; scheduling copies a template into per-service instance records that carry the live, independently editable capacity.

What the operator uses it for

An operator designs a space once — for example, a vehicle deck divided into zones, where each zone exposes a number of passenger spaces and lane metres of vehicle space, plus a checked height constraint. That design becomes one named layout template. Any resource that allows the template can be scheduled against it, and every scheduled service receives its own copy of the whole tree so capacity can be adjusted per departure without touching the design.

Each capacity unit in the tree carries three kinds of assignment:

Capacity unit types (tracks) — kinds of consumable capacity attached to the unit, each with a numeric capacity (for example, passenger spaces or lane metres).
Limits — check-only constraints with a value, such as a height ceiling; they are validated during booking but never decremented.
Excluded fare item sub-types (forbidden_sub_types) — fare item sub-types barred from that unit regardless of remaining capacity.

Leaf units additionally carry a booking priority and may link to a room (room_id) so accommodation-style leaves resolve to the rooms catalog.

Where it sits

Upstream, templates consume master data owned elsewhere: capacity unit types and limit types come from the tracks catalogue, room links point at rooms, and excluded sub-types point at fare item sub-types from pattypes. Downstream, the resources module controls which resources allow which template; the scheduler instantiates a template into per-service instance tables when a service is created; and booking walks that instance tree by priority, respecting capacities, limits, and exclusions. This module owns only template design — instance editing and bulk application to services belong to the schedule/inventory side, and resource-to-template assignment belongs to resources.

Key concepts

Layout template (inventory_holding_sets_template) — the named top-level record; optionally linked to a default asset.
Capacity unit / IHU (inventory_holding_units_template) — a node in the tree; containers have children, leaves hold bookable capacity. Parentage is a self-reference; a node with no parent is the root.
Capacity unit type assignment (tracks) — a consumable kind plus its capacity on this unit; a null capacity means unlimited.
Limit assignment — a check-only constraint plus its value on this unit.
Excluded fare item sub-type — a sub-type refused at this unit even when capacity remains.
Priority — the order in which booking tries leaf units; lower numbers are tried first.
Instance copy — the per-service duplicate created at scheduling time; live capacity lives there, never in the template.

Tools

Tool	Class	Purpose
`blueprints_list`	Read	List layout templates (id, name, sort_key, asset link) for a tenant.
`blueprints_get`	Read	Fetch one template's full capacity-unit tree with its tracks, limits, and exclusions.
`blueprints_list_tracks_limits`	Read	List the valid capacity-unit-type and limit-type labels a template may reference.
`blueprints_save`	Guarded write	Create a template or atomically replace an existing one's entire unit tree (preview, then confirm).

Rules worth knowing

The whole tree is the write unit. There is no per-unit, per-track, or per-limit CRUD. Saving replaces the entire hierarchy atomically (delete-all plus re-insert); callers must send the complete intended tree every time.
Templates are forward-only. Editing a template never changes already-scheduled services; only services scheduled afterwards pick up the change.
Server-replicated validation. Every unit needs at least one capacity unit type; leaf units need a priority; leaf names must be unique within the template; room_id is accepted on leaves only; capacity-unit and limit labels must match names in the tracks master vocabulary.
Unlimited-capacity encoding. A null capacity and the sentinel value Number.MAX_VALUE both mean unlimited; the tool normalises between them exactly as the staff app does.
Client-side identifiers. Units are addressed by caller-supplied UUIDs (id/parentId); the backend maps them to database ids on insert, so payloads mirror the staff app's wire shape.
Preview-then-confirm safety. Updates fingerprint the current tree before preview and re-check it before execution, so a concurrent edit forces re-review rather than overwriting blind.
Instance operations are out of scope here — editing a scheduled service's copied capacity is a schedule/inventory capability with its own booking-safe-edit gates.

Tracks — owns the capacity-unit-type and limit-type vocabulary templates must reference.
Schedule — instantiates templates into per-service instance capacity.
Resources — assigns which layout templates a resource allows.
Rooms — supplies the accommodation units leaf capacity-units can link to.
Fare item types — source of the fare item sub-types that exclusion rules bar from units.