Shift in Railway Variable Precedence Rules During Environment Promotion

When moving a service from one Railway environment to another, the platform must decide which value wins for a variable defined both at the project level and overridden in the source environment. The current documentation describes hierarchical containment but does not specify whether the project‑level value, the environment‑level override, or the most recent deployment takes precedence during a promotion action. This uncertainty affects teams that rely on consistent secret handling across staging and production pipelines.

Clarifying the exact precedence rule would allow users to predict whether updating a project‑level variable propagates to downstream environments without triggering unwanted redeploys, and whether a local override can shield a service from global changes.

What is the definitive precedence order when a project‑level variable and an environment‑level variable share the same key during an environment promotion? Does updating a project‑level variable cause a redeploy in environments that lack a local override? Are there any scenarios where the most recently deployed value overrides both levels?