Version, variant, revision: three itinerary objects, not one

These are 3 different objects and the confusion between them is the source of most disagreements about what a client agreed to. A version is the whole trip as it stood at a moment, saved and never altered again. A variant is one of several options being offered at the same time — the 10-night and the 14-night, the deluxe and the standard — each with its own version history. A revision is the narrower thing: a version that was actually sent to the client.

The last definition is the one that gets lost. Revisions are a subsequence of versions, not another word for them. A consultant may save 17 versions while building; if only 3 of those were ever sent, the client has seen 3 revisions, and when they say the second one you sent, they mean revision 2 and not version 2.

Each one answers a different question

• Version answers what did this trip look like at 14:32 on Tuesday. It exists so that a document issued then can still be reproduced now. Immutability is the whole point: a version that can be edited is a draft with a number on it.
• Variant answers which options are we putting in front of this client. Variants are siblings under one enquiry, they coexist, and none of them is the trip until the client picks one. Modelling them as separate enquiries loses the fact that they were alternatives.
• Revision answers what has the client actually seen. It is the only one of the 3 the client can quote back at you, and it is the only one whose numbering they will ever refer to.

A common shortcut is to treat an extension — a pre-tour city stay, a post-tour beach week — as a variant. Sometimes it is, and often it is not: an extension that can be switched on alongside the main trip is a set of optional days rather than a parallel option, and the modelling argument either way is in are extensions separate trips or optional days. Getting it wrong produces variants that multiply, because every combination becomes its own option.

What each downstream document has to point at

The rule underneath the table is short: nothing that leaves the building points at a mutable object. The most common violation is a proposal delivered as a live link, which is a real and defensible choice with a real cost — a client refreshing the page sees a different trip from the one they discussed, and the trade-off is argued in a PDF the client keeps or a link you can still change.

Choosing a variant is an event, not an edit

When the client picks the 14-night option, something happens that is worth recording as a fact rather than absorbing as a state change. The temptation is to copy the chosen variant over the parent trip and move on, which loses everything: what else was offered, what the alternatives cost, and which document the decision was made against.

1. Record the selection with a timestamp, the person or channel it came through, and the revision the client was looking at when they chose. The last of those is what makes the decision defensible.
2. Keep the losing variants. They are evidence of what was offered, and they are the best template material you own — a shortlist somebody already thought was appropriate for this brief.
3. Do not renumber anything on promotion. Version numbers stay where they are; the chosen variant does not become version 1 of a new object, because that severs its own history.
4. Freeze the chosen variant's current version as the confirmed version, and point operations at that id. Everything issued from here — vouchers, supplier bookings, the operational manifest — references it explicitly.
5. Treat any change after that as a new version plus, if the client sees it, a new revision. The approval loop that governs which changes require re-sending is the loop between draft, sent and client approved.

A variant that is silently promoted takes the record of the alternatives with it, and the first person to need that record is the one arguing with a client six weeks later.

Naming that survives contact with a client

Clients do not say version 17. They say the cheaper one, the second one you sent, the one with the extra night in Udaipur. Your system says trip 4821, variant B, version 17. Both vocabularies are correct and the interface has to translate between them, because every misunderstanding in this area happens at the join.

• Name variants by their difference, not their sequence. Highlands, 10 nights reads better than Option 2 and survives the addition of a third option in the middle, which Option 2 does not.
• Give revisions a client-facing counter and a date: revision 3, sent 14 March. That is the phrase you want quoted back at you, and it maps to exactly one stored document.
• Never expose the internal version integer. It jumps — a consultant working hard produces version 9 then version 17 — and every jump invites the question of what happened to the other 8.
• Keep the internal id on the document anyway, in small print or metadata, so support can resolve a client's screenshot to a stored version without guessing.
• Do not reuse a revision number after a correction. If revision 3 went out with a wrong date, the fix is revision 4, because the client may still have the original open.

This page defines the objects; it does not build the approval workflow around them, and it does not help when the records were never kept in the first place. Reconstructing what a client approved from a system that edited trips in place is a genuinely harder problem, worked through in nobody can say what changed since the client approved. Getting the 3 objects right at the start is what makes that reconstruction unnecessary — which is why they belong in the first schema review of any build in itinerary building and the trip data model, inside our travel and tourism practice, and it is ordinary internal tools and ops work rather than anything exotic.

• data modelling
• versioning
• proposals
• itinerary builder