Which relationships can a generated customer change dataset contain?

A generated dataset can contain more than a customer table with changed fields. It can represent individual customers, shared households, service contracts, authorised contacts and correspondence destinations as separate entities. Each relationship can carry a purpose and a validity period.

This matters when one household member changes circumstances. A new personal address does not automatically establish that every household member moved, that a joint contract ended or that another person's correspondence should follow. The task needs enough structure to make these distinctions explicit.

A release could include relationship records with fields such as `subject_id`, `related_entity_id`, `relationship_type`, `valid_from` and `valid_to`. Associated policies could specify whether a change affects an individual, a contract or a shared delivery destination. Tasks could ask an agent to update the relevant records while identifying dependencies that require separate instructions.

Evaluation teams can inspect whether these relationships create meaningful decisions. A dataset in which every customer owns exactly one contract and one address offers little evidence about relationship reasoning. Request generated cases where the same change has different consequences because ownership, membership and communication relationships differ.