• 1 <= nums.length <= 10⁴
• -10⁴ <= nums[i] <= 10⁴
• nums is sorted in strictly increasing order, so there are no duplicates
• Any height-balanced BST over these values is accepted

Two separate demands are being made here, and it pays to keep them apart. The tree must be a binary search tree, and it must be height-balanced.

A binary search tree is an ordinary binary tree with one extra rule imposed at every node: everything in its left subtree is smaller than it, and everything in its right subtree is larger. That rule is what makes searching cheap — comparing your target against a node tells you which single subtree to enter and lets you discard the other one entirely, without looking inside it. Discarding half the remaining candidates at each step is what turns a search into roughly log₂N comparisons instead of N.

But that speed is a promise about height, not about the ordering rule, and the ordering rule alone does not deliver it. Insert 1, 2, 3, 4, 5 into an empty BST in that order: each value is larger than everything present, so each becomes the right child of the last, and you get a chain of height 5. The search property holds perfectly and searching still costs N steps. Hence the second demand — height-balanced, in the sense checked by Balanced Binary Tree: at every node the two subtree heights differ by at most 1, which keeps the height at O(log N).

Here is the connection worth internalising. Read a binary search tree in in-order — left subtree, node, right subtree — and the values come out in increasing order. That is not a coincidence: in-order visits everything smaller than a node before it and everything larger after it, which is precisely the BST rule restated as a sequence.

So the given array is the in-order reading of the tree we must build. The values' relative order is fixed and not ours to choose. All the freedom lies in deciding which value sits at the top of each range — and that choice alone determines the height.

Pick some value as the root. Everything before it in the array must go to its left, everything after to its right — the BST rule leaves no alternative. So the split sizes are decided entirely by where in the range you pick.

Pick the first value, and the left subtree gets nothing while the right gets everything: that is the degenerate chain again. Pick the middle, and the two sides differ in size by at most one, which is the most even split available. Apply the same choice recursively to each half and no node can ever end up lopsided — with n values, each side gets ⌊(n-1)/2⌋ or ⌈(n-1)/2⌉ of them, so the two subtree heights can differ by at most 1 at every node, which is exactly the balance condition. Repeated halving also means the height is about log₂N, since the range size halves each level.

def build(lo, hi):                  # inclusive index range
    if lo > hi:
        return None                 # empty range: no subtree here
    mid = (lo + hi) // 2            # the middle value becomes this subtree's root
    node = Node(nums[mid])
    node.left  = build(lo, mid - 1) # strictly smaller values
    node.right = build(mid + 1, hi) # strictly larger values
    return node

return build(0, len(nums) - 1)

The node is created before its children, since we need something to attach them to — a pre-order construction, the same shape as the two reconstruction problems, and for the same reason.

When the range has an even number of values there is no exact middle, and (lo + hi) // 2 picks the lower one. Choosing the upper instead is equally valid and simply produces a different accepted tree — the balance argument above never depended on which of the two you take.

Each value produces exactly one node and is touched once: O(N) time, which is optimal since every value must appear in the output. The recursion is O(log N) deep because the range halves each level, so the extra space is O(log N) — noticeably better than the O(H) of most tree recursions, precisely because we are guaranteeing the tree is shallow rather than accepting whatever shape we are handed.

Two things generalise. First, in-order is the traversal that exposes a BST's ordering, and that fact drives most BST problems: validating one, finding its k-th smallest value, or converting it back to a sorted list are all in-order walks. Second, the balancing move — take the middle so both sides stay equal — is the same instinct behind binary search and merge sort, and it recurs whenever a structure's cost depends on its depth. When someone hands you sorted data and asks for a balanced structure, the middle element is almost always the answer.