Identity resolution across consent boundaries

A customer's relationship with the brand is rarely consistent across consent states. They browse anonymously and decline cookies; later they create an account and accept marketing consent; later still they log in from a different device where the consent banner showed a different default. The stack that resolves them as one person needs to also reconcile the consent states, and the question of which state survives the merge is not a technical detail. It is a customer-trust question and a regulatory question, and the wrong answer in either direction creates exposure.

The wrong answers come in two shapes. The lenient merge: collapse the consent states into the most permissive one (anonymous declined plus authenticated accepted equals consented), letting the brand act on behavior the customer never consented to having attributed to them in the consented context. The strict merge: collapse to the most restrictive (any decline anywhere blocks all use), making it impossible to deliver an experience the customer did want when they accepted. Both produce customer confusion and regulator interest. The right answer is in the middle and requires explicit rules: which consent state applies to which signal, how the merge surfaces to the customer, and what the customer can do to dispute it.

This recipe builds the cross-consent resolution as a deliberate rule rather than a default, with the propagation, the disclosure, and the audit trail that make the merge defensible.

A reconciliation rule that handles consent-state differences at merge correctly: the authenticated identity's consent state is authoritative for actions tied to the authenticated identity, the anonymous session's consent state is authoritative for behavior captured under it, and the merge does not silently re-attribute behavior to a consent context it was not collected under. The metric is cross-consent resolution correctness: the share of merge decisions that the audit confirms applied the rule, measured by sampling. The value shows up in customer trust (the brand does not behave as if the customer consented to something they did not) and in the regulator-facing posture (the rule is explicit, documented, and applied consistently).

The second outcome is the customer-facing transparency: at the moment of merge, the customer is told that prior anonymous behavior will be joined to their account, what the consent implications are, and how to dispute or restrict the join. The transparency is the work that turns the merge from a technical event into a customer-understandable one.

A warehouse-side identity-resolution layer that supports the explicit join, holds the consent context on each edge, and exposes the merged identity with the consent state per signal-type. Composable stacks suit this because the graph is the source of truth and the activation layer reads it; packaged stacks may merge silently as part of the sign-in flow, and the question is whether the merge respects consent or collapses it. The capability that decides whether the recipe is defensible is the propagation: a merge that lands in the resolution layer but does not propagate to downstream activation systems still produces consent-mismatched behavior, because the activation systems read their own joined view and apply it.

Work in this order. The merge rule is a gate on activation, not a join.

1. Collect every signal with its consent context attached. Without it, the merge cannot see what was consented to when.
2. Write the consent merge rule before any join runs.
3. Stitch anonymous to known, reconciling consent as part of the stitch. A join that skips the check defaults to using everything, the failure GDPR-strict was written to address.
4. Disclose the join at authentication: prior behavior will be associated with the account, and what the customer can do about it. The statement is short; its absence becomes a regulator finding.
5. Propagate the resolved consent state per signal to every system that consumes the joined identity.
6. Retire local join logic in activation systems. One system firing on the linked identity without reading consent undoes the rule.
7. Log every merge with the rule applied, the input consent states and the resolved state per signal type.

Consent-scoped signal collection covers step 1, anonymous-to-known stitching steps 2 to 4, consent state propagation across systems steps 5 and 6, and audit trail generation at the decision point step 7.