Do not explode a multi-value field and sum blindly

A customer may hold several labels. Joining an order to every label copies its amount, so label totals can exceed company sales.

Model membership in a bridge and specify whether the metric uses deduplication, overlap, or allocation.

Declare the set semantics of the question

Sales from customers containing a label usually deduplicates customers; contribution by label may overlap; management allocation needs weights.

These are distinct metrics and should not share one default sum rule.

Each row represents an entity-member relationship for an effective interval with source and confidence.

If weights drive allocation, validate the expected total per entity and time slice.

Use an explicit unclassified member and route conflicting labels or invalid weights to quality review.

Query generation must know that the dimension overlaps and warn when results are not additive.

Test one, several, and no labels, changing membership, and bad weights across deduplicated, overlapping, and allocated totals.

BuildTable can be assessed for relationship semantics; bridge generation, validation, history, and AI aggregation behavior need confirmation.