Constraint you stated
- Smith & Adam may not share a billing account with John
- Relationship must not affect billing
- Prepaid / Postpaid / Broadband / DTH mix
Putting a "spouse / parent / child" label on an Account would overload a commercial object with identity semantics - a classic anti-pattern that leaks into billing extracts, revenue reports, and dunning logic.
Why TMF629 (Customer) is correct ??
TMF629 represents the party engaged in a business relationship with the operator - i.e., the person/identity view, independent of what they buy or how they pay.
Household, family, and personal relationships are attributes of IDENTITY. They persist even if John churns a service, switches from postpaid to prepaid, or closes a billing account.
In TMF629 we can model this via the relatedParty construct (or, more purely, delegate to TMF632 Party Management which owns PartyRelationship)
// On John's Customer resource
{
"id": "cust-john-001",
"name": "John",
"relatedParty": [
{
"id": "cust-smith-044",
"name": "Smith",
"role": "spouse", // household label
"@referredType": "Customer"
},
{
"id": "cust-adam-088",
"name": "Adam",
"role": "child",
"@referredType": "Customer"
}
]
}
------------------------------
Nitin Srivastava
Jio Platforms Limited
------------------------------