Technical architecture · 26 October 2026 · Neerej Sasikumar
Dynamic Bundling Needs Product Catalogue Governance, Not Just a Pricing Engine
Why bundling is a governance problem
Dynamic bundling sounds like a pricing task: select a flight, add a bag or seat, calculate a compelling total and present the result. Yet a pricing engine cannot rescue a product whose identity is ambiguous, whose eligibility rules disagree across channels or whose delivery owner is unknown. A bundle can be commercially attractive and still be impossible to honour after a schedule change.
Imagine a journey with a flight, an extra bag and priority boarding. The bag may apply only to certain segments, boarding benefits may depend on the operating airport, and a partner may publish a different description of the same product. The dynamically assembled Offer must reconcile those facts before becoming a customer promise. The challenge is not generating endless combinations; it is assembling a valid, understandable and deliverable combination.
Standards boundary: IATA's Dynamic Offers programme describes continuous pricing and dynamic bundling as complementary capabilities. IATA AIDM supplies industry vocabulary and relationships. The control model, lifecycle states and thresholds below are practitioner proposals, not mandatory IATA rules.
Begin with durable product identity
A catalogue should assign a stable identity to each sellable service definition while allowing customer-facing labels to evolve. “Extra bag”, “Checked bag” and a translated equivalent may identify the same product, or they may hide materially different entitlements. A display name is therefore an unsafe reconciliation key.
Separate product definition (what is supplied), eligibility (when it can be offered), price (what the shopping context costs), bundle composition (what is grouped) and fulfilment obligation (how delivery is proven). This is an architecture recommendation, not an assertion about exact NDC message fields.
Give each product a versioned definition and stable supplier reference. Include measurable attributes such as allowance, applicable segment, refundability and restrictions where appropriate. Keep translation and marketing descriptions tied to a revision so a seller can explain the promise actually purchased, even after catalogue content changes.
The minimum product governance contract
Before a product becomes eligible for dynamic assembly, require an accountable owner, scope, approved definition, applicable rule set, effective period and delivery evidence model. Distinguish commercial ownership from the operational party that fulfils the service. A product without an accountable delivery owner should not silently enter a live bundle.
| Dimension | Proposed control | Failure avoided |
|---|---|---|
| Identity | Stable ID and immutable approved revision | Historic Orders resolving to new entitlements |
| Eligibility | Passenger, itinerary, market and channel rules | Unsellable combinations |
| Composition | Required, optional and incompatible components | Duplicated or contradictory benefits |
| Fulfilment | Supplier and delivery evidence | Paid but undeliverable services |
| Publication | Audience, effective time and acknowledgement | Partner content drift |
| Withdrawal | Stop-sell and existing-Order policy | Deleting an outstanding customer promise |
The AIDM product catalogue publication-management process refers to products, markets, conditions and bundling, but its public model labels it Proposed. It is useful modelling direction, not evidence of a universally implemented obligation.
Version products, rules and recipes independently
A product revision need not be a bundle revision. Consider a comfort bundle containing seat choice and lounge access. The lounge provider changes operating hours, while the price and seat entitlement remain unchanged. Governance must identify which approved recipes depend on the affected product revision and which live Offers might be impacted.
Track three revisions independently: product definition, eligibility rule set and bundle recipe. A recipe should reference exact approved component revisions rather than whichever definition happens to be current when a downstream system reads it. Store a content fingerprint for the published snapshot, including terms and restrictions. This makes a purchased promise reconstructable and enables comparison of what different channels received.
At shopping time, a dynamic engine can choose approved recipes or construct permitted combinations, but should not invent entitlements outside the catalogue. Price can change dynamically without changing the product. Equally, a new bundle may be assembled while prices remain filed or constrained. Product, composition and price are related but distinct dimensions.
Eligibility must return a reason
Eligibility is a hidden source of friction. A service may apply to one segment but not another, or be excluded when a conflicting benefit is included. Eligibility should return a decision and an explanation, not only a Boolean. This supports investigations, seller disclosures and safe recovery after rejection.
A proposed decision sequence is: confirm approval and effective dates; check passenger and itinerary scope; evaluate dependencies and incompatibilities; verify delivery capacity where necessary; apply partner restrictions; then construct and price the Offer. The exact sequence varies by architecture, but material restrictions must be resolved before the Offer becomes a commitment.
Test combinations, not just happy paths. Generate multi-segment journeys, mixed suppliers, an ineligible passenger type and overlapping baggage entitlements. Assert that the final Offer never contains mutually exclusive components or promises a service without an identified delivery party. Also test whether a rule revision can be applied consistently to all shopping channels.
Publish the same promise to every receiver
Governance continues after approval. A seller may cache descriptions, a partner may require different attributes, and servicing may use a legacy representation. A publication contract should identify which revision was sent, when it takes effect, how acknowledgement works and what happens if a receiver has not applied the update. HTTP success alone does not prove a business revision is live.
At ATPCO Elevate 2026, ATPCO described its Product Catalog direction as shared product-data exchange, with airlines managing catalogues within their own Offer systems. That is a public statement of direction, not proof of universal production deployment. ATPCO's developer documentation describes products, bundles and rule sets; implementers should check applicable API versions and access conditions.
We recommend a versioned publication manifest containing the snapshot hash, effective time, receiving party, markets, schema version and acknowledgement status. Keep a rollback pointer, but never use rollback to rewrite historic Orders. A rollback should correct future Offers while preserving purchased terms.
A sample contract, not an industry schema
The following JSON illustrates an internal governance envelope. It is not an NDC, ONE Order or ATPCO payload. Its purpose is to expose dependencies for review and replay.
{
"bundleRecipeId": "comfort-pack",
"recipeRevision": 12,
"status": "APPROVED",
"effectiveFrom": "2026-10-26T00:00:00Z",
"components": [
{"productId": "seat-choice", "revision": 4, "required": true},
{"productId": "priority-boarding", "revision": 7, "required": false}
],
"eligibilityRuleSet": {"id": "comfort-eligibility", "revision": 9},
"supplierEvidence": "SERVICE_DELIVERY_EVENT",
"publicationScope": ["DIRECT", "PARTNER_APPROVED"]
}Do not store passenger profiles or sensitive payment details in the product catalogue. Eligibility can evaluate necessary context through controlled interfaces without duplicating personal information in every definition. A published snapshot should contain only attributes needed to present and service the promise. Maintain access controls and an audit trail for approval, publication and withdrawal.
Withdrawal is not the end of the obligation
A dangerous anti-pattern is to delete a product from the catalogue and assume the obligation disappears. An existing Order can still require the original benefit or an agreed remedy. Separate stop selling from stop fulfilling. A withdrawn lounge product might vanish from new Offers while a previous customer remains entitled to delivery, substitution or refund.
Classify each change as presentation-only, eligibility-changing, price-affecting, fulfilment-changing or terms-changing. A copy edit may propagate without invalidating Offers. A material fulfilment change may require stop-sell, partner notification, customer remediation and reconciliation of affected Orders. Commercial and operational owners should approve the classification.
Store product and recipe revisions with the Order Item or in durable associated evidence. During servicing, compare the historic purchased snapshot with the current catalogue and determine whether the original entitlement can be delivered, substituted under agreed rules or refunded. Do not reconstruct a customer's historic promise from current marketing copy.
Release gates, failure drills and KPIs
Use a staged release pipeline: draft, validate, approve, publish to a limited audience, reconcile acknowledgements, then expand. Reject missing delivery ownership, overlapping mandatory entitlements, expired rules, incompatible components and incomplete partner publication. Apply equivalent controls when importing an external catalogue.
Test a late supplier withdrawal, delayed partner update, Offer assembled from mixed revisions, failed delivery after payment and voluntary change that invalidates a bundle component. Each scenario should either produce a valid alternative or decline to sell, while existing Orders retain an auditable fulfilment or remedy path.
Useful measures include products with approved delivery ownership, publication lag by channel, invalid-bundle suppression, OrderCreate rejection attributable to product rules, service-not-delivered rate and age of unreconciled partner revisions. Segment by product family and channel. Define alert thresholds from measured baselines rather than unsupported industry averages. Optimize conversion and incremental margin alongside delivery quality, complaints and refund effort.
A 30-day implementation path
Week one: inventory the ten most-used products, identify missing owners and trace one product from display to delivery. Week two: establish IDs, revisions, eligibility, effective dates and evidence requirements. Week three: implement publication manifests, snapshot storage and combinatorial tests. Week four: trial one low-risk bundle in limited distribution, compare channel acknowledgements and rehearse withdrawal and post-sale servicing.
Dynamic construction should increase relevance without weakening the product contract. A bundle that converts better but creates unserviceable promises is not a sustainable retail outcome. Evaluate customer understanding, margin and fulfilment together.
For adjacent reading, see dynamic bundle merchandising, product catalogue fundamentals and ATPCO Product Catalog interoperability. This guide focuses on the governance controls that make those capabilities reliable.
Primary sources and interpretation
These are original industry publications. Programme direction and proposed processes are not treated as deployed obligations. Engineering controls above are recommendations for local adaptation and testing.
Editorial note: Independent educational analysis based on public sources. Illustrative contracts, processes and thresholds are not official requirements. Validate standards, agreements and controls for your context.