Quote from: PrimeNumber7 on Today at 03:32:43 AM

If I understand correctly, address A belongs to Alice. Address A can send to any address upon the signature of address A.

That's correct

Quote from: PrimeNumber7 on Today at 03:32:43 AM

Address B, belonging to Bob, Alice’s son, (the associated private key) can also cause unspent outputs from address A to be sent from address A to address B. The private key associated with address B can spend any output from address A, but only after x blocks since a transaction was sent to address A from address B. Address A can spend any output from address A to address B at any time.

That is not quite true. There are not 2 but 3 addresses in the schema: A (Alice), B(Bob), E(Escrow). A and B are just some regular addresses (like P2PKH) where only one private key can spend. No person can spend from other person addresses.
And then we have address E which has spending rules like this:

Code:

OP_IF
<Alice Public Key> OP_CHECKSIG
OP_ELSE
<N days> OP_CSV DROP <Bob Public Key> OP_CHECKSIG
OP_ENDIF

I can quote this paragraph to help understanding the role of the E address. It is from this site

Quote

The key point is that there is no need for an Owner to permanently keep her bitcoins in such CSV locked escrow UTXOs. It should be enough for Owner to only construct a transaction, which spends Owners's bitcoins and has CSV locked outputs as above. The transaction should not be broadcasted but rather shared directly to Heir. A Heir will broadcast the transaction only when inheritance time comes. As a result, bitcoins will be transferred to the escrow address without Owner's participation. Then Heir need to wait for the time defined in the locking script and redeem bitcoins from the escrow UTXOs.

Alternatively you can skim through the app screenshots to understand the flow.