variation.json

variation.json defines which content options Divekit may choose from during individualization.

This file is optional, but required if you want per-UUID variation selection.

Format

{
  "objects": [
    {
      "ids": "Vehicle",
      "objectVariations": [
        {
          "id": "car",
          "type": "class",
          "name": "Car",
          "variables": {
            "Vehicle": "Car"
          }
        },
        {
          "id": "truck",
          "type": "class",
          "name": "Truck",
          "variables": {
            "Vehicle": "Truck"
          }
        }
      ]
    }
  ],
  "relations": [
    {
      "id": "ownership",
      "type": "association",
      "source": "Vehicle",
      "target": "Owner",
      "options": ["one-to-one", "one-to-many"],
      "variables": {}
    }
  ],
  "logic": [
    {
      "id": "algorithm",
      "type": "implementation",
      "location": "src/logic",
      "options": ["simple", "complex"],
      "variables": {}
    }
  ]
}

Top-Level Sections

Variation Fields and Token Overrides

Each object variation can contain more than just id, type, name, and variables.

Additional fields become tokens by combining the object key with the field name.

Example:

{
  "objects": [
    {
      "ids": "Plz",
      "objectVariations": [
        {
          "id": "ZipCode",
          "": "Zip code",
          "Class": "ZipCode",
          "Parameter": "zipCode",
          "DocLabel": "ZIP code"
        }
      ]
    }
  ]
}

This produces tokens such as:

• $Plz$ / $plz$ from the empty-string field ""
• $PlzClass$ / $plzClass$ from Class
• $PlzParameter$ / $plzParameter$ from Parameter
• $PlzDocLabel$ / $plzDocLabel$ from DocLabel

Notes:

• "": "..." is the explicit override for the base display token.
• Named fields such as Class or Parameter override the corresponding generated transformer output.
• Lowercase object aliases such as $plzClass$ are generated automatically.
• If you do not provide an explicit override, Divekit falls back to the built-in transformer behavior.

This is the preferred way to control exact wording for display labels, acronyms, or project-specific names.

{
  "id": "asd-012",
  "": "asd-012",
  "name": "Example supplier"
}

Built-In Token Suffixes

When an object variation is selected, Divekit generates tokens from the object key and the selected variation ID. The token without a suffix uses the display transformer.

Example selection:

{
  "objects": {
    "Basket": "ShoppingBasket"
  }
}

This produces a base token such as $Basket$ and suffix tokens such as $BasketClass$. Divekit also creates lowercase object aliases such as $basket$ and $basketClass$.

The following built-in suffixes are available by default:

If a variation entry defines a field with the same suffix name, that explicit value wins over the generated value. For example, "Class": "ShoppingCart" makes $BasketClass$ resolve to ShoppingCart.

Resolution Order

Divekit accepts variation.json as a legacy source within the unified variation lookup order:

1. distribution individualization.json
2. distribution variation.json
3. project .divekit/individualization.json
4. project .divekit/variation.json
5. user ~/.divekit/individualization.json
6. built-in defaults with no variations

An explicitly empty legacy variation file disables variations at its level. The old ~/.divekit/templates/variation.json fallback is no longer read. Run divekit inject --scope variation to create an example file explicitly.

Output

Concrete selections are persisted to individuals.json, and selected variation metadata may also be persisted into remotes.json.

Related pages:

• individualization.json
• State Files
• Individualization