Children and rooming — developer reference¶

Audience: engineers working on Booking/BookingWizard/Step1 - Input parameters, Booking/BookingWizard/Step2 - Availability check, Booking/BookingWizard/Step4 - Quote, the API booking and quote operations, or BookingMasterData/RARA policy master data.

Source of truth: the Mendix model, read via model/ and db/model.db at commit 80b58aeb8, Mendix 10.24.21. Node numbers in [n] match model/<Module>/flows.txt and the steps table. Branch labels are the model's own case true / case false.

Anything the model does not state is marked (inferred). Quoted NOTE: lines are Studio Pro canvas annotations, reproduced verbatim.

1. Three different rule sets, one word¶

"Children rules" means three separate mechanisms with different owners, different storage and different consequences. Most confusion about this area is a conflation of two of them.

Rule set	Owner	Question it answers	Consequence
Camp admission	`BookingMasterData.Supplier.ChildPolicy`	may a child of this age be at this camp at all	availability status `No_Children`, captioned "Age restrictions apply"
Bedroom occupancy	`BookingMasterData.Policy` + `Availability.RoomTypes`	may this child be in this room, with these people	warnings, and on some paths the room is silently emptied
Charging	`BookingMasterData.Option.P_*` and `BookingMasterData.ChildOptionPolicy`	what does the child cost	rate basis per age band

The trap: Option.P_ChildMustShareWithAdults reads like an occupancy rule and is a pricing attribute. No step in Booking.RoomingChecks reads it. See §7.

2. Who counts as a child¶

Two independent definitions, and they do not have to agree.

By guest record. Administration.Guest.IsChild (Boolean) and Administration.Guest.Age. Booking.Get_ChildrenByAgeLimit($UpperAgeLimit, $LowerAgeLimit, $GuestList) counts guests where Age <= upper and Age >= lower [4] — inclusive at both ends, and it ignores IsChild entirely. Three clones exist: XtremeAvailability.GetChildrenByAgeLimit, XtremeAvailability.Get_ChildrenByAgeLimit_Overall and BookingTemplates.GetChildrenByAgeLimit.

By configured age band. BookingMasterData.Policy carries InfantAgeFrom/To, ChildAgeFrom/To and AdultAgeFrom/To, per policy record, reached from an option through the BookingMasterData.Option_Policy association. All six default to 0, and 0 means "not configured", which switches the rule off rather than making everyone an adult (§4).

The camp-admission checks do not use the configured bands at all. They call Get_ChildrenByAgeLimit with hard-coded ages:

Call	Variable	Used against
`(16, 0)`	`$ChildrenUnder17`	`NoChildren`
`(5, 0)`	`$InfantsUnder6`	`InfantFriendly`
`(12, 6)`	`$Children6to12`	`Teens_allowed`, `ChildrenAllowedWithPVE`

So "child" means under 17 for admission and whatever Policy.ChildAgeTo says for rooming (inferred: unintentional — nothing in the model reconciles them).

3. Camp admission — `Supplier.ChildPolicy`¶

Six values, captions verbatim from the enumeration:

Value	Caption
`NoChildren`	No children
`InfantFriendly`	Infant friendly
`Teens_allowed`	Teens allowed
`ChildrenAllowedWithPVE`	Children allowed with private activities
`Children_only_no_PVe_required`	Children only no P. Act. required
`Unknown`	Unknown

Enforced in Booking.UpdateAvailabilityStatusForAccom_X [24-34] and, for the partner API, in API.CheckPveRequired — two implementations of the same ladder. The sequence:

[24] find the party cost group with Pax_Children > 0
[25] if none, or AvailableRoomConfig/SoleUse  -> skip the whole check
[26] retrieve the guests for this travel location where IsChild
[27] if ChildPolicy is InfantFriendly or Unknown  -> [28] count children under 17
[29] if ChildPolicy is NoChildren and ChildrenUnder17 > 0
[30] count infants under 6
[31] if ChildPolicy is ChildrenAllowedWithPVE / Children_only_no_PVe_required / ...
[32] count children 6 to 12
[33] if ChildPolicy is Teens_allowed and Children6to12 > 0
[34] if ChildPolicy is ChildrenAllowedWithPVE and Children6to12 > 0

API.CheckPveRequired [19] is where the refusal is recorded: XtremeAvailability.AvailabilityStatus.No_Children. SoleUse bypasses admission entirely [25] — a whole-camp booking is not age-checked.

The private-vehicle link is weaker than the caption suggests¶

ChildrenAllowedWithPVE reads as "children require a private activity vehicle", but the vehicle entitlement in Booking.QualifyForPve is computed from room counts, TotalPax - Staff thresholds (>= 11 → 2, >= 17 → 3) and camp class, plus a hard-coded supplier list (MOM001, LIT003, ABU001, DUM002, …) [4]. No term in it refers to children. Booking.CheckIfPVeRequired [2] then exits early when SoleUse is set. The policy decides whether a vehicle is required; nothing makes the requirement scale with the number of children (inferred).

4. Bedroom occupancy — `Booking.RoomingChecks`¶

Booking.RoomingChecks($AvailableRoomConfig, $RequiredRoom, $Supplier, $Booking, $Quote, $KeepRooming, $Option, $Policy) : Boolean — 95 steps, per required room. Two callers, and the last two arguments decide how forgiving it is:

Caller	`$Quote`	`$KeepRooming`	Effect on failure
`Booking.CheckRoomSelection` [41]	`false`	`false`	the room is emptied — see §5
`Booking.CheckRooming` [10]	`false`	`true`	warnings only, rooming survives

Booking.CheckRooming is the quote-time sweep: every BookThis room configuration on the booking, every Required room, $Policy resolved per option through BookingMasterData.Option_Policy [9]. Booking.CheckRoomSelection runs in step 2 from the room-selection buttons (Booking.IVK_SelectRooms, Booking.IVK_SelectRoomTypes, Booking.SelectRoomTypes, Booking.SelectRoomTypes_SingleRoom, Booking.IVK_OnRequest) and from API.SetAccommodationToBooked on the partner API.

The head: a child can be counted as an adult¶

[13] SPLIT if $countGuests != ($RequiredRoom/Adults + $RequiredRoom/Children + $RequiredRoom/Staff)
  [14] case false: LOOP over GuestList
    [15] SPLIT if $IteratorGuest_1/IsChild
      [16] case false: $adults = $adults + 1
      [17] case true:  SPLIT if $IteratorGuest_1/Age >= $Policy/AdultAgeFrom
        [18] case true:  $children_asAdults = $children_asAdults + 1
        [19] case false: $children = $children + 1
  [92] case true: MESSAGE "You have not roomed your guests correctly, there are {1} guests
       allocated to the room but you have indicated rooming for {2} guests"

Three counters, not two. A guest flagged IsChild whose age reaches Policy/AdultAgeFrom becomes children_asAdults and is then charged against the room's adult capacity — and told so: "Please be aware N of the children in this room are considered adults at this supplier" [70]. With AdultAgeFrom left at its default 0, every child counts as an adult, because Age >= 0 is always true. That is the single most consequential default in this area.

Note the guard at [13]: the declared rooming (Adults + Children + Staff) must match the number of guests actually linked to the room, or nothing else is checked at all.

The capacity ladder¶

Room capacity comes from Availability.RoomTypes: NormalAdults, NormalChildren, GuestNormal, GuestMax, resolved by Booking.getRoomType($RequiredRoom) [4] — and if that returns empty the flow logs "There is no room type attached to the required room" and returns false [94-95].

Test	Node	Message when it fails
`adults + children_asAdults = 0`	[22]	the children-alone path, §6
`adults + children_asAdults > NormalAdults`	[24]	"Too many adults in the room." [70], or "Max pax exceeded." [75] when also over `GuestMax`
`children > NormalChildren`	[26]	"Exceeded normal children." [67], or "Exceeded normal children and max guests." [63]
`Adults + Children + Staff > GuestNormal`	[28], [40], [56]	"Exceeded normal guest count." [42]

AvailableRoomConfig.MaxPaxAllowed is the permission switch: with it set, exceeding a normal count is a logged warning; without it the room is emptied. Two hard-coded specifics live in this ladder: $Country/CountryNameEnum = Countries.Countries.Botswana [38] and $Supplier/SupplierID = 'ABU001' [50].

The model's own doubt. At [74], the split $adults + $children_asAdults + $children > $RoomTypes/GuestMax carries the annotation:

NOTE: Doesn't look correct

Left as found. Unattached notes on the same flow include NOTE: JG 21/11/19 allow max pax any amount.

5. Failure empties the room¶

On the non-quote path with $KeepRooming false, the flow does not merely refuse — it clears what the consultant entered:

Node	Cleared
[61], [73]	`Adults = 0`, `AdultsEnum = empty`, `RequiredRoom_Guest = empty`
[66], [78]	all three counts and their enums, plus the guest links
[88]	`Children = 0`, `ChildrenEnum = no_children`, guest links

So a rooming mistake in step 2 looks like the room reset itself. At quote time ($KeepRooming true) the same conditions only warn. (inferred: deliberate — step 2 is interactive, the quote sweep must not destroy a booking being priced.)

6. A child alone in a room¶

Reached when a room has no adults and no children-counted-as-adults — [22] case true. Never a hard block; three graded outcomes, and the branch that decides is the booking method:

[81] SPLIT if $AvailableRoomConfig/BookingMethod = Booking.BookingMethod.Wish
  [82] case false:  "Please be aware, that on the ground, children may not be allowed in a room
                     on their own."                                   -> continue
  [84] case true:   SPLIT if $Option/AllowTriples
    [89] case true:  "...we assume there is space in another room for this child (not already
                      using max pax)."                                -> continue
    [85] case false: "...we cannot assume this child will be allowed in another room as this
                      supplier does not allow triples."
                     -> [88] empty the room, unless $Quote or $KeepRooming

Non-Wish accommodation therefore gets the mildest treatment of the three. The strictest outcome depends on Option.AllowTriples — a flag about third beds, standing in for "can this child be moved in with someone" (inferred).

Both branches also write a booking event, Booking.Event.Error_Warning with object type Booking.Object_Type.Room_allocation [83], [90], so the decision is on the booking's history even though nothing was blocked.

7. The age floor per room — `Booking.CheckYoungestChild`¶

Called from Booking.RoomingChecks [20] via Booking.ValidateChildrenAllowed, which filters the guest list to IsChild and returns true immediately when there are none [3-4].

Booking.CheckYoungestChild (20 steps) sorts the children by age ascending, takes the youngest [2-3], and then:

[5]  if $Policy/AdultAgeFrom = 0                      -> return true   (unconfigured, no rule)
[6]  if ChildPolicyOverride or SoleUse                -> return true
[7]  if $Policy/ChildAgeTo = 0                        -> ...
[8]  if $Policy/InfantAgeTo = 0                       -> return true
[10] if $Guest_Child/Age >= $Policy/ChildAgeFrom      -> return true
[12] MESSAGE "You have a child that is younger than the allowed age policy for this room. You may
     not be allowed to book this room, unless you get special permission..."
[13] return false                    -> RoomingChecks [91] logs "Child below age limit and no
                                        permission." at severity Error
[14] if $Guest_Child/Age < $Policy/AdultAgeFrom       -> [15] same message, [16] return false

Three of the first four tests are "is this configured at all", and each unconfigured value returns true. An option whose policy record is blank admits any age.

8. The two overrides¶

Flow	Writes	Behaviour
`Booking.IVK_OverrideChildPolicy_Ac`	`AvailableRoomConfig.ChildPolicyOverride`	toggles: `if ChildPolicyOverride then false else true` [2] — the same button withdraws it
`Booking.IVK_OverrideChildPolicy_BL`	`BookingLine.OverrideChildPolicy = true` [2]	one-way; nothing in the live model sets it back to `false`

Both log to the booking through Booking.LogEvent(… Booking.Event.Provisional, 'Child policy overridden' / 'Child policy override reversed', …) with object type Booking.Object_Type.Room_allocation [4]. The wording is chosen from the flag's new value, so the line-level flow can only ever write the first of the two. ChildPolicyOverride is what CheckYoungestChild [6] honours, and Booking.CheckRoomSelection [163] reads it as well; it is also copied onto draft copies of a booking (Booking.Sub_CopyBookingToDraft [152]), so an override survives a copy.

Neither microflow checks a role. Whether the buttons are restricted is page security (inferred — confirm with the team).

Where these are triggered from¶

entry_points has no scheduled event, no commit hook and no published operation for any of the rooming flows: they are sub-microflows called from screens, plus the API operations in §11. Every page, qualified:

Flow	Pages and widgets
`Booking.IVK_SelectRooms`	`Booking.SupplierRoomAvailability_SelectConfig` and `Booking.SupplierRoomAvailability_SelectConfig_140526`, `microflowButton2`
`Booking.IVK_SelectRoomTypes`	`Booking.SupplierRoomAvailability_SelectRoomType` / `actionButton2`
`Booking.IVK_OnRequest`	`Booking.SNP_Step2Form` and `Booking.SNP_Step2Form_300426`, `microflowTrigger8`
`Booking.IVK_OverrideChildPolicy_Ac`	`Booking.SupplierRoomAvailability_SelectConfig` and `Booking.SupplierRoomAvailability_SelectConfig_140526`, two buttons each (`actionButton16`, `actionButton24`)
`Booking.IVK_OverrideChildPolicy_BL`	`Dashboard.BookingLine_Service_Edit`, `actionButton36` and `actionButton37`
`BookingMasterData.IVK_ChildPolicy_Save`	`BookingMasterData.ChildOptionPolicy_NewEdit` / `actionButton1`
`Booking.OCh_AddUpPax_Booking`	dropdowns on `Booking.Sn_Booking_RRoom`, `Booking.Sn_Booking_RRoom_270126`, `Booking.Sn_Booking_RRoom_Allocate`, `Booking.Sn_Booking_RRoom_Other`, `Booking.Sn_Booking_GuestOnly`
`Booking.OCh_AddUpPax_Booking_GuestOnly`	`Booking.Sn_Booking_GuestOnly`, `dropDown2`, `dropDown3`
`Booking.OCh_SetTotalPax_RR`	dropdowns and selectors on `Booking.SNP_RequiredRoomsSelected`, `Booking.SNP_RequiredRoomsSelected_Room`, `Booking.SNP_RequiredRoomsSelectGuide`
`Booking.OCh_Commit_ReqRoom`	`Booking.Sn_Booking_RRoom_270126` / `dropDown1` and its siblings — commits a required room and resets `ChildrenEnum` to `no_children` when the count goes to zero

Two buttons per override page is worth noticing: the flow toggles, so a single button would suffice — the pair suggests separate "override" and "reverse" affordances against one toggling microflow (inferred).

9. Where the child flags come from¶

Everything above reads three flags. None of them is set by the rules that read them, which is why a wrong flag is usually a rollup problem rather than a rules problem.

Administration.Guest.IsChild — seven live writers, and the first two are the normal path: Booking.SetGuests_Children and Booking.CreateGuestPerPCG create guests from a party cost group. BookingGuestManagement.AddContactDetailsToGuest sets it while capturing contact details, and BookingTemplates.Sub_CreateTripBooking, XtremeAvailability.CreateBookingFromAvail, XtremeAvailability.XAvailCreateBookingFromAvail and XtremeAvailability.IVK_CreateBookingSuggestBooking each set it when they build a booking from somewhere other than the wizard.

Booking.Booking.PartyContainsChildren — fourteen live writers, all computing the same thing from a different starting point: if $SumChildren > 0 then true else false (Booking.OCh_AddUpPax_Booking, Booking.OCh_AddUpPax_Booking_GuestOnly), if $SumChildPax > 0 … (API.CreateBooking, API.CreatePartyCostGroup), if $Booking/TotalChildren > 0 … (API.SetPrefferedRoomConfig), plus Booking.UpdateBooking_Pax, BookingTemplates.Sub_CreateTripBooking, the three Booking.Sub_CopyBookingToDraft* copies, DataManagement.BHL_LogEntry_Create and the three XtremeAvailability create-from-availability flows. (inferred: no single owner — the flag is recomputed wherever pax change, so a path that forgets to recompute leaves it stale.)

Booking.Booking.ChildrenInFamily / ChildrenInStandard — the family-versus-standard split, written by Booking.SetPax_Room_Booking and Booking.SetPaxAndRooms_PCG_PG_Booking as $sumChildrenInFam and $sumChildrenInDb + $sumChildrenInHm + $sumChildrenInTwin, carried by the draft-copy flows and logged by DataManagement.BHL_LogEntry_Create.

Booking.RequiredRoom.Children has an enumeration twin, ChildrenEnum, whose members are no_children, _1, _2, _3, _4, _5, _6, _7, _8, _9 and _10 — the dropdown the consultant actually uses, mirroring the integer. Ten is therefore the per-room ceiling on the screen, against five on the API (§11). Booking.OCh_SetTotalPax_RR, Booking.OCh_Commit_ReqRoom and Booking.OCh_Commit_ReqRoom_NotPartOfAll keep the two in step, and set ChildrenEnum = no_children when the count is cleared.

Who fills the room in¶

The rules in §4 to §7 judge a RequiredRoom that something else populated, and the populators write both the integer and the enumeration together. All live, all in step 2:

Flow	Steps	What it does
`Booking.Reset_RequiredRoomsPerARC`	279	the big one: rebuilds every required room for a room configuration, called from six places including `Booking.UpdateAvailabilityStatusForAccom_X` [37]
`Booking.Reset_RequiredRoomsPerARC_Explorations`	80	the explorations variant of the same
`Booking.GetAvailableRooms_Wish`	85	builds rooms from what Wish reports as available
`Booking.Populate_RR`	47	fills one room: `Children = $AllocateChildren + $AllocateChildrenAsAdults` [13], with the enumeration set alongside
`Booking.PopulateFamilyRoom_RR`	47	the family-room twin of the above, zero callers — dead or dynamically invoked
`Booking.Trips_CreateLR_RequiredRooms`	40	required rooms for a long-stay trip
`Booking.RequiredRoomsConvertEnums`	23	reconciles the integer counts with their enumeration twins
`Booking.ClearGuestsPerRoom_RR`	6	empties a room's guests and counts

Note what Booking.Populate_RR [13] does: it writes AllocateChildren + AllocateChildrenAsAdults into Children. The population step folds the two buckets back together, and Booking.RoomingChecks [15-19] then separates them again from the guest records. The two are only consistent while every child's Age and the option's AdultAgeFrom agree with what the allocator assumed (inferred).

Booking copies carry all of this: Booking.Sub_CopyBookingToDraft, Booking.Sub_CopyBookingToDraft_Skeleton and Booking.Sub_CopyBookingToDraft_Debug copy RequiredRoom.Children, ChildrenEnum, AvailableRoomConfig.ChildPolicyOverride and the booking-level child totals onto the draft, so a copied booking inherits both the rooming and the permission to break the rules. The _Debug twin is live but reachable only from a debug screen, and is recorded as out of scope in journeys/children-and-rooming.toml.

10. Charging is configured somewhere else entirely¶

BookingMasterData.Option carries thirteen policy flags, none of which any rooming flow reads:

Attribute	Type
`P_ChildMustShareWithAdults`	Integer
`P_ChildSharingAtChildRate`	Integer
`P_FirstChildrenFree`, `P_FirstChildrenChargeable`	Integer
`P_OnlyChargeAfterChildNo`, `P_ChildrenFreeAfter`	Boolean
`P_ChildrenMustShareWithAdults_ForFirstFreeChildren`	Boolean
`P_ChargeAdultRates_ChildrenNotSharingWithAdult`	Boolean
`P_ChargeChildrenAdultRateAfter_x_ChildrenSharing`	Boolean
`P_ChargeMin2AdultsIfShareingWithChildren`	Boolean
`P_DoNotChargeSingleSuppWithChildren`, `…WithInfants`	Boolean
`P_SeasonalChildPolicy`	Boolean
`P_Suite_ChargeChildrenAfter_xPax`, `P_First_xPaxSuite`	Boolean, Integer

Seasonal variants live on BookingMasterData.ChildOptionPolicy (StartDate, EndDate, P_FirstChildrenFree, P_OnlyChargeAfterChildNo, P_ChildrenMustShareWithAdults_ForFirstFreeChildren), selected by Pricing.GetChildPolicy, which is four steps: retrieve the option's policies, find the one whose date range contains $FirstDay, return it [2-4]. No fallback if two ranges overlap — FIND returns the first.

Rate basis per age band sits on BookingMasterData.ExtractedRate (and _P): ChildAgeMin/Max, InfantAgeMin/Max, ChildRatePercentage, ChildRateBasisType and InfantRateBasisType, whose values are FOC, FixedAmount, PercentageOfAdultSharing, PercentageOfAdultSingle, SameAsAdult, None.

So "children must share with adults" is never enforced as occupancy. The only thing standing between a child and a room of their own is the warning in §6.

11. The partner API validates differently¶

API.CreateWindowBooking, API.ReplaceBooking, API.ReplaceQuote and their dated copies call three checks the UI does not:

API.ValidateChildAges (34 steps) — for each required room with ChildPax > 0, every ChildAge1..5 up to ChildPax must be present and greater than zero, else $ChildAgesValid = false [20] and the loop breaks [21]. Five ages is the hard ceiling: ChildPax > 5 is never checked, because the ladder stops at ChildAge5 [22-24].
API.CreateChildrenGuests (27 steps) — turns those ages into API.Child objects, one per age, again ceilinged at five [7-20].
API.ValidateRequiredRooms and API.ValidateRequiredRooms_ThirdParty — 31 and 28 steps respectively, room-shape validation for the same payloads.

The ages arrive as five numbered attributes on API.RequiredRoom, API.BookingRequiredRoom and API.BookedRoom rather than as guests, which is why a separate creation step exists.

12. Defects and traps¶

ID	What	Where
C1	`Policy.AdultAgeFrom` defaults to `0`, so with an unconfigured policy every child counts as an adult against `NormalAdults`	`RoomingChecks` [17]
C2	Three of four tests in the age floor are "is it configured", each returning true, so a blank policy admits any age	`CheckYoungestChild` [5], [7], [8]
C3	Admission uses hard-coded ages (under 17, under 6, 6-12); rooming uses configured bands. Nothing reconciles them	`UpdateAvailabilityStatusForAccom_X` [28], [30], [32]
C4	A child alone in a room is never blocked — three warnings, and only the strictest empties the room	`RoomingChecks` [81-90]
C5	`P_ChildMustShareWithAdults` is a pricing attribute that reads like an occupancy rule and is read by no rooming flow	§9
C6	The partner API supports at most five children per room, silently — `ChildPax > 5` is accepted and the sixth age is never validated or created	`API.ValidateChildAges` [22-24], `API.CreateChildrenGuests`
C7	`SoleUse` bypasses camp admission and the age floor	`UpdateAvailabilityStatusForAccom_X` [25], `CheckYoungestChild` [6]
C8	The configuration-level override toggles, the line-level one only ever turns on	`IVK_OverrideChildPolicy_Ac` [2] vs `_BL` [2]
C9	`Get_ChildrenByAgeLimit` ignores `IsChild` and counts purely on age, so an adult recorded with a low age is counted as a child	`Get_ChildrenByAgeLimit` [4]
C10	Two implementations of the admission ladder, UI and API, kept in step by hand	`UpdateAvailabilityStatusForAccom_X` [27-34] vs `API.CheckPveRequired` [6-13]
C11	A step-2 rooming failure empties the room rather than refusing it, which reads as the screen resetting itself	§5
C12	`NOTE: Doesn't look correct` on the `GuestMax` split, unresolved in the model	`RoomingChecks` [74]

13. What this document does not cover¶

Named from the island list, not from memory. 65 documents whose names mention children or rooming are unreachable from this journey's roots; these are the ones a reader might expect here:

Document	Why not covered
`BookingTemplates.OCh_SetChildren_trips`, `BookingTemplates.OCh_SetChildsAge_trip` (driven from `BookingTemplates.Sn_ChildAges_NewEdit_trip`), `BookingTemplates.ResetRequiredRooms`, `BookingTemplates.GetChildrenByAgeLimit`	The templated-trip journey builds its own required rooms with its own clone of the age helper
`XtremeAvailability.CreateRequiredRooms`, `XtremeAvailability.ResetRequiredRooms`, `XtremeAvailability.GetChildrenByAgeLimit`	The availability-search journey, which rooms a hypothetical party rather than a booking
`GuestManagementAPI.GetBookingRoomingList`, `GuestManagement.Sub_MissingRoomingEmailConsultant`, `Booking.Ds_MissingRoomingList_BranchDept`, `History.CleanWishRoomingLists`	A rooming list is the guest-name document sent to a camp. Different subject from the rules that decide who may share a room
`DataManagement.TP_GetRoomingLineFCU`, `TP_GetRoomingLineSCU`	Tourplan service-line assembly
`BookingMasterData.IVK_GenerateChildRateTypeOPDs`	Rate-sheet import, which belongs to the pricing set
`SRM.GetChildSuppliers`, `XLSReport.ACT_GetChildsByParentMxXPath`, `Administration.tmp_setAgeCategory_child`	"Child" in the parent/child sense, or a debug screen — not about children
`Booking.RoomingChecks_160326`, `Booking.RoomingChecks_Test`	Excluded from deployment; dated copies of §4

Also out of scope by decision: the availability engine that produces room-type capacity, the guest-allocation flow Booking.PrePopulateGuests_RR, private-vehicle pricing beyond the admission link in §3, and the whole of §9's charging behaviour, which belongs with the pricing documents.

14. Reproducing this analysis¶

python3 tools/scope.py Booking BookingMasterData Availability API \
        --roots Booking.CheckRoomSelection Booking.CheckRooming \
                Booking.UpdateAvailabilityStatusForAccom_X --all
python3 tools/coverage.py Booking.RequiredRoom --attr Children,ChildrenEnum --ui \
        docs/deep-dives/children-and-rooming.md
python3 tools/verify.py docs/deep-dives/children-and-rooming.md

-- C1: is the adult age still the thing that reclassifies a child?
select node, text from steps where doc = 'Booking.RoomingChecks' and node between 15 and 19;

-- C6: the five-child ceiling on the API
select node, text from steps where doc = 'API.ValidateChildAges' and node between 22 and 24;