At creation time, each content item becomes permanently either a baseline content item or a variant content item. A variant always refers, in its base property, to exactly one baseline that it can replace, and it identifies the segments and test cases that enable it. When a baseline is rendered, the delivery service detects the presence of variants and replaces the rendered baseline content as needed.

A variant always has the same content type as its baseline. This ensures that the same templates that render the baseline can also render the variant. A variant stores a copy of its baseline's properties with the necessary changes; as a consequence, you must propagate any change to the baseline to its variants explicitly.

Variants are not nested: every variant refers directly to its baseline, never to another variant. If certain user segments should override others, you express this by a variant priority. If a user matches the conditions of multiple variants, the site chooses the variant with the highest numerical priority. For example, a variant for the segment "vegan food interest" should get a higher priority than a variant for the segment "food interest".

Native Personalization ignores deleted variants for all intents and purposes. You must publish a variant for it to take effect in the delivery environment; publishing a baseline does not publish its variants automatically. Because links should never point to variants, you can publish and withdraw variants easily.

Variants reside close to their baselines in the folder hierarchy. A variant with the name X for a baseline Y in folder Z is placed by CoreMedia Studio at Z/.variants/Y/X. CoreMedia Studio maintains this location even during moves and renames. The same rules determine access rights for variants and baselines; because a variant resides close to its baseline, a user typically has the same rights on both.