Runtime Context

In short. Runtime context is the always-on resolution layer that determines which site and environment an operation belongs to. SGEN reads the URL on every request and sets four values: account-vs-site tier, active site, active environment (staging or live), and operator permissions. When those four agree with what you intended, context is invisible. When they don't, the platform surfaces the mismatch rather than silently running the wrong operation.

On this page: What it resolves · Where resolution runs · Cross-surface handoffs · Drift detection · Examples · Vocabulary

How this connects to other features

• Workflows Overview — parent Reference area.
• Site Provisioning — workflow that creates the site this resolves context for.
• Shared Concepts — site context vs account context vocabulary.
• SG-Admin Overview — surface where site-context operations land.
• SG-Builder Overview — surface where page-context operations land.

Definition

Runtime context is the cross-cutting resolution layer that determines which site and which environment an operation belongs to at runtime. The resolution combines four inputs: the URL pattern (account vs site tier), the active site (when in site context), the active environment (staging vs live), and the operator's permission scope.

The defining property is always-on. Every operation goes through context resolution; it is invisible when correct and surfaces only when context drifts — for example, when an action lands on the wrong site.

Context dimensions

Where resolution happens

Resolution runs at every request boundary — not just on page load.

• Page load — context resolves from the URL and the operator session.
• Action submission — re-resolves before executing to confirm nothing drifted between page load and click.
• Surface handoff — when moving from SG-Dashboard to SG-Admin, or from SG-Admin to SG-Builder, the resolved context carries forward so the next surface opens in the correct scope.

Context propagation across handoffs

Context propagates with the surface you open. Switching context is always intentional — moving from SG-Dashboard into a site's admin is the operator's deliberate context switch.

• Within the same site — all operations stay in the resolved site context until the operator navigates back to SG-Dashboard.
• Switching sites — use SG-Dashboard → Site Manager. Direct URL navigation between sites also works but is less guided.

Drift detection

When context resolves unexpectedly, the platform surfaces the mismatch rather than silently running the wrong operation.

• Breadcrumb — every surface shows the active site name and environment at all times. This is the fastest check.
• Permission mismatch — if the operator lacks permission for the resolved operation, the action either disables or routes to the permission-grant flow. It does not fail silently.

Examples

Example 1 — Operator publishes a page on the correct site. The operator opens the admin for their site, edits the homepage, publishes. Runtime context resolves to that site throughout; the publish lands on the correct site.

Example 2 — Operator switches sites mid-workday. The operator finishes editing on one site, returns to SG-Dashboard, opens a second site via the site card. Runtime context resolves to the new site for all subsequent operations until the next switch.

Example 3 — Permission mismatch surfaces. A new operator with read-only permission attempts to publish. Permission resolution surfaces the mismatch; the publish action disables with a permission-grant prompt rather than failing silently.

Vocabulary cross-reference

Related reading

• Workflows Overview — parent Reference area.
• Site Provisioning — sibling that creates the site this resolves context for.
• Shared Concepts — site context vs account context vocabulary.
• SG-Admin Overview — site-context surface.
• SG-Builder Overview — page-context surface.