Markets

A Market represents a geographical location that the platform targets. Markets are defined as combinations of countries and regions.

Subdivions vs Regions

In Orbital, Region is a domain-specific term equivalent to subdivision, referring to a geographical subdivision within a single country (for example, a state or province).

Configuration

Each market is associated with a Market Configuration, which defines:

• Countries & Regions
• Supported Languages
• Supported Currencies
• Number & Currency formatting rules PLANNED

This configuration acts as the context in which Ørbs operate. All Messages are tied to a single market configuration.

Localization

All non-transactional Entries support localization through a fallback mechanism. Each Entry may have a unique variant per market defined in the system. If the Entry is translatable, it may have a unique value per market and per language supported in the market.

Market Fallback & Specificity

Market resolution in Orbital follows a deterministic fallback chain based on market specificity. Each level represents a progressively broader scope. Resolution always starts at the most specific level and moves upward until a match is found.

Orbital defines six specificity levels:

1. Single Country + Single Subdivision - A market that targets one country and one specific subdivision within that country.

2. Single Country + Multiple Subdivisions - A market that targets one country and a defined set of subdivisions within that country.

3. Single Country - A market that targets one country without subdivision constraints.

4. Multiple Countries - A market that targets a defined set of countries.

5. Rest of the World (ROW) - A fallback market used when the user’s geo location does not match any of the configured market specifications above.

6. Default - While not technically a market, Default represents the root level of all content. It provides baseline values that are always available, independent of geography. More specific markets may fall back to Default for individual fields when no market-specific value exists, even in cases where a language is not configured for the system’s ROW market.

More specific markets may define languages or language-specific values that do not exist anywhere else in the market hierarchy. In such cases, field-level fallback may resolve directly to Default for that language, even if the language is not defined for ROW or any other market.

Resolution proceeds from level 1 to 6. If the user’s location is not covered by any explicit market definition, the system resolves content against ROW.

Example: A user in New Jersey inherits data from:

flowchart TD
  NJ["1. New Jersey, USA"] -->  NJNY["2. New Jersey & <br> New York, USA"] --> USA["3. USA"] --> NA["4. North America"] --> ROW["5. Rest of World"] --> DEF["6. Default"]

When resolving data for a specific market, Orbital:

• Selects the most specific matching market
• Uses data from less specific markets if no data is defined for the active market
• Overrides only where differences are required

This avoids duplication while still supporting strict local requirements. Only differences need to be defined at each level.

Managing Markets with Equal Specificity

In most cases, market resolution in Orbital is deterministic based on specificity alone. However, there can be situations where multiple markets match the same user location at the same specificity level.

This occurs when:

• a region is included in multiple single-country, multi-region markets, or
• a country is included in multiple multi-country markets.

In these scenarios, geographical structure alone is insufficient to determine which market should take precedence.

By default, Orbital resolves such ambiguity using a deterministic fallback rule: markets at the same specificity level are evaluated in reverse creation order: The most recently added market taking priority.

When this default behavior does not reflect the intended behaviour, markets can be manually reordered within the affected specificity level. This explicit prioritisation overrides the default ordering and defines the evaluation order during resolution.

Note

Manual prioritisation applies only to markets at the same specificity level; all other steps in the market fallback chain remain automatic and unchanged.

Translations & Language Fallback

This market fallback chain is also evaluated independently per language defined in its configuration; language defaults are applied only after market resolution has been exhausted for the requested language.

If a market in the fallback-chain doesn’t support the language, the system will automatically look in the next, less specific, market in the fallback chain.

flowchart TD

  subgraph NJ["New Jersey, USA"]
    direction TB
    NJ_EN["EN"]
    NJ_ES["ES"]
  end

  subgraph USA["USA"]
    direction TB
    USA_EN["EN"]
  end

  subgraph NA["North America"]
    direction TB
    NA_EN["EN"]
  end

  subgraph ROW["Rest of World"]
    direction TB
    ROW_EN["EN"]
  end

  subgraph DEF["Default"]
    direction TB
    DEF_EN["EN"]
    DEF_ES["ES"]
  end

  %% Language fallback chains
  NJ_EN --> USA_EN --> NA_EN --> ROW_EN --> DEF_EN
  NJ_ES --> DEF_ES

• Content can be reused across markets
• Localized or regulated differences are isolated
• Global updates propagate automatically unless overridden

Field-Level Fallback Control

Fallback behavior in Orbital can be controlled per field by explicitly allowing or disallowing fallback when the field is empty. This applies equally to language-specific fields and non-translatable fields. If no value is defined at the current specificity level, and fallback is prevented, the field is treated as unset, and no market, language, or Default fallback is applied.

When a field has a value defined at a given level, it is always treated as specific to that level and is never inherited, regardless of fallback settings.

---