Shared Concepts

Cross-platform rules and models that hold across every SGEN surface — the vocabulary the rest of the documentation assumes.

Shared Concepts in SGEN are the cross-platform rules, models, and operating ideas that remain consistent across SG-Dashboard, SG-Builder, Workflows, Automation, Integrations, and Migration and Import. This area exists to provide a stable conceptual layer for the wider platform rather than a description of any one isolated surface.

This page is the Reference definition of the Shared Concepts surface. It establishes the common terminology and platform logic that other Reference areas depend on, so support, implementation, onboarding, and internal documentation share a model for interpreting how the system behaves across multiple surfaces.

What is this for?

Read this page when you want the cross-platform vocabulary the rest of the Reference library assumes — site context, environment separation, ownership boundaries, surface responsibility, and the system relationships that hold the platform together as one operating model rather than a stack of independent tools.

The page is a Reference definition. It does not walk you through any procedure. Step-by-step procedures live in Guides. Per-surface capability detail lives in the SG-Dashboard, SG-Admin, and SG-Builder Reference sections.

Good use cases

• You are new to SGEN and need the cross-platform vocabulary before you start opening per-surface Reference pages.
• You are explaining the platform to a stakeholder, an in-house operator, or an agency client and need the shared model.
• You are scoping a multi-team operations workflow and need the boundary model laid out plainly.
• You hit terminology in another Reference page and want the canonical definition.
• You are writing your own internal docs against SGEN and need the platform vocabulary to anchor your team's documentation.

What NOT to use this for

• Per-surface deep detail — open the corresponding surface's Reference page (SG-Dashboard, SG-Builder).
• Step-by-step procedures — open the relevant Guide.
• Per-release behavior change — open What's New or Changelog.
• Marketing claims about SGEN's positioning — sgen.com is the marketing surface.
• Per-customer infrastructure detail — escalate to support.

How this connects to other features

• Platform Overview — the system map that places Shared Concepts inside the wider Reference library.
• SG-Dashboard Overview — the account-tier surface that applies Shared Concepts to multi-site control.
• SG-Admin Overview — the site-tier surface that applies Shared Concepts to record administration.
• SG-Builder Overview — the page-tier surface that applies Shared Concepts to visual composition.

Definition

Shared Concepts in SGEN are the cross-platform rules, models, and operating ideas that remain consistent across SG-Dashboard, SG-Builder, Workflows, Automation, Integrations, and migration-sensitive operations. The area exists to provide a stable conceptual layer for the wider platform rather than a description of one isolated surface.

The defining property is recurrence. A concept lives in Shared Concepts when it appears across more than one surface and would otherwise be redefined inconsistently in each per-surface Reference page. By centralizing the definition here, the per-surface pages can assume the model without restating it — keeping the documentation legible at scale.

Purpose

The purpose of this page is to establish the common terminology and platform logic that other Reference areas depend on. It gives support, implementation, onboarding, and internal documentation a shared model for interpreting how the system behaves across multiple surfaces.

Scope

This page covers shared platform concepts at the Reference level. It does not act as a procedural guide, a screen walkthrough, or a release note. It should be read as a conceptual reference for the rules and models that appear repeatedly across the SGEN stack.

The page covers:

• Rules and models that apply beyond a single product surface.
• A common language for interpreting platform behavior.
• Consistent reading across Dashboard, Admin, Builder, Workflows, Automation, Integrations, and Migration-related references.
• The conceptual backbone every other Reference page can assume without restating.

The page does not cover:

• Per-surface capability detail — corresponding surface Reference pages.
• Per-area procedures — Guides.
• Per-release shipped change — What's New or Changelog.
• Internal engineering implementation — internal-only documentation.

Responsibilities

The Shared Concepts area is responsible for keeping cross-platform understanding consistent.

Concept definition

Defines the shared models and operating ideas that appear across the wider SGEN platform — site context, environment separation, ownership boundaries, structured administration, platform-level flow continuity. Each concept has a single canonical definition here and is referenced from elsewhere rather than redefined.

Terminology alignment

Provides a stable vocabulary for support, implementation, onboarding, and product documentation. The vocabulary on this page is the vocabulary the rest of the docs use. Per-team or per-customer renaming should adapt to this vocabulary, not the other way around.

Cross-surface consistency

Reduces interpretation drift when operators move between Dashboard, Admin, Builder, Workflows, and system-level Reference areas. A concept defined once here behaves the same way every time it appears downstream.

Key concepts

Shared Concepts covers platform-wide ideas such as ownership boundaries, cross-surface responsibility, system models, operational separation, and recurring rules that should not be redefined differently in every section.

Site context vs account context

Site context is the operating context bounded by {site-domain}.com/sg-admin/... — work in this context affects the active site's content, settings, modules, or layout. Account context is the operating context bounded by dashboard.sgen.com/... — work in this context affects the account portfolio, billing, multi-site reporting, or invitations.

The boundary between site context and account context is structural. Operators switch contexts intentionally — opening a site card from SG-Dashboard moves into that site's SG-Admin (site context); navigating back to dashboard.sgen.com returns to account context. The browser address bar tells you which context you are in.

Environment separation

Staging and live are first-class environments, not an afterthought. Promotion from staging to live is a governed operation; the platform owns the surface that moves change from one environment to the other. Environment separation applies to content, settings, themes, and layout — anything publishable has staging and live counterparts.

Ownership boundaries

Each operating surface owns a clear scope. SG-Dashboard owns account-tier operations; SG-Admin owns site-tier records and configuration; SG-Builder owns page-tier layout and presentation. Features land on the tier whose shape matches the feature's shape; cross-tier features split into the parts that belong on each tier.

Structured administration

Site state is administered through structured records — Pages, Posts, Products, Forms, Custom Objects, Locations, Events. Each record type has a defined schema, a creation flow, an inventory view, and a publishing model. Structured administration is the shape SG-Admin enforces across every module.

Operational role

Operationally, Shared Concepts acts as the common interpretive layer of the SGEN Reference library. It is the place readers should use when they need to understand how the platform thinks, how its surfaces are separated, and what recurring system rules remain true across multiple parts of the product.

In daily operator use, Shared Concepts is read once during onboarding and revisited when terminology lands ambiguously somewhere downstream. It is not a working surface — there is nothing to do here — but it is the surface that makes the working surfaces legible.

Dependencies and related surfaces

Shared Concepts supports all major Reference areas and should be read alongside the sections that apply those concepts in more concrete ways.

• Platform Overview — the system map.
• SG-Dashboard — applies Shared Concepts to account-tier multi-site control.
• SG-Admin — applies Shared Concepts to site-tier administration.
• SG-Builder — applies Shared Concepts to page-tier composition.
• Workflows — cross-product process flows that depend on the surface ownership model.
• Automation — background and scheduled behavior that depends on the operating models.
• Integrations — third-party connections that depend on the system relationships model.
• Migration and Import — handoff operations that depend on environment separation and structured administration.

Constraints and boundaries

This page defines shared concepts at the system level. It does not replace surface-specific references, implementation notes, task instructions, or release communication.

Use this page for:

• Conceptual and model-level reference only.
• Cross-platform vocabulary the rest of the docs assume.
• Onboarding context for the platform's structural shape.

Use the per-surface Reference pages for:

• Specific surface ownership and module detail.

Use Guides for:

• Procedures and task execution.

Use What's New or Changelog for:

• Shipped changes.

Public boundary

This page is intentionally public-safe. It does not expose private infrastructure detail, internal credentials, exact network topology, unpublished operational controls, or protected service identifiers.

Examples

Example 1 — A new operator reads Shared Concepts during onboarding

The new operator opens this page after Platform Overview, reads the Site Context vs Account Context section, and internalizes the boundary. When they next open SG-Dashboard and see one site card, the boundary explains why the site card opens into a separate URL pattern ({site}.com/sg-admin/). The vocabulary primes them for every other Reference page they will read.

Example 2 — A support operator triages a "where did my change go?" ticket

The customer reports that a setting they changed at one surface did not propagate to another. The support operator opens this page's Surface Responsibility section, identifies the canonical surface for that setting, and walks the customer through where the edit should have happened. The shared model on this page resolves the ticket without escalating to engineering.

Example 3 — An agency principal documents internal procedures against SGEN

The agency principal builds an internal SOP for their team's use of SGEN. They anchor the SOP on the vocabulary defined here — site context, account context, environment separation, ownership boundaries — so the SOP and the SGEN Reference library use the same words for the same things. The internal docs read alongside the SGEN docs without translation overhead.

Documentation guidance

Use this page as a stable Reference definition. The shape on this page should remain consistent across releases — concept additions land alongside the existing concept families rather than as a new top-level vocabulary section. When a concept appears on more than one Reference page, define it here and reference it from the per-surface pages rather than restating.

Vocabulary cross-reference

• Site context is the canonical phrase for the operating context inside {site-domain}.com/sg-admin/.... Body copy may shorten to "site-tier" where the prose flows.
• Account context is the canonical phrase for the operating context inside dashboard.sgen.com/.... Body copy may shorten to "account-tier" where the prose flows.
• Surface refers to a top-level operating environment (SG-Dashboard, SG-Builder).
• Pillar refers to a top-level grouping inside a surface (the admin's GENERAL, MODULES, STORE MANAGEMENT, CUSTOM OBJECTS, CONFIGURATION).
• Module refers to a single administrative or composition area inside a pillar (Pages, Blogs, Products, etc.).
• Tier refers to the scope of an operation (account-tier, site-tier, page-tier).

Related reading

• Platform Overview — system map across the three operating surfaces.
• SG-Dashboard Overview — account-tier surface.
• SG-Admin Overview — site-tier surface.
• SG-Builder Overview — page-tier surface.
• Architecture and Reliability — architectural framing for the platform that applies these concepts.
• SGEN Product Definitions — companion glossary covering per-product responsibility split.

Reading order across the section

Open Shared Concepts (this page) once during onboarding, after Platform Overview. Internalize the concept families (surface responsibility, operating models, system relationships, reference continuity) and the key concepts (site context vs account context, environment separation, ownership boundaries, structured administration). Return to this page when terminology lands ambiguously somewhere downstream.

The page is short by intent. The platform does not need many shared concepts — only the small set that recur across surfaces. Adding a new shared concept is a structural decision, not a documentation expansion: a concept earns a place here when it appears across two or more surfaces and would otherwise be redefined inconsistently in each.

Where to find it

In SGEN Admin, Shared Concepts surfaces as the cross-platform vocabulary that every module and surface assumes. There is no dedicated Shared Concepts screen — the concepts apply across SG-Dashboard (account context), SG-Admin (site context), and SG-Builder (page context). Read this Reference before opening any per-surface or per-module page to carry the right vocabulary into those areas.

Where Shared Concepts appears on the live docs site

The Shared Concepts section in docs.sgen.com is a single Reference page — this one. It does not expand into sub-pages. The vocabulary defined here is referenced from the per-surface Reference pages and from the Guides, keeping the documentation legible without fragmenting the conceptual layer across many small entries.

Maintenance discipline

When a new platform feature lands, do not add a new shared concept by default. First check whether the feature lands inside one of the existing concept families. Only add a new family entry when the feature genuinely defines a new cross-surface concept that would be redefined inconsistently elsewhere. The page stays valuable because it stays small.

The same maintenance discipline applies to renaming. A concept name on this page is the canonical name across the docs, the Guides, and any internal team SOPs that anchor on the platform vocabulary. Renames here propagate downstream. Renames at a per-surface page that diverge from the vocabulary on this page create drift the next reader has to resolve — and therefore should be reverted to align with this page rather than the other way around.

When this page is the right first read

This page is the right first read when an operator, a stakeholder, or a documentation author needs the cross-platform vocabulary that the rest of the SGEN Reference library uses. It is not the right first read when the question is about a specific surface (open the surface's Reference instead) or about a procedure (open Guides instead).

The pairing across the Reference library is intentional: Platform Overview gives the system map, Shared Concepts gives the vocabulary, and the per-surface Reference pages give the surface-level detail. Reading the three in order — Platform Overview, Shared Concepts, then SG-Dashboard / SG-Builder — gives a new reader the platform shape, the vocabulary, and the working surface coverage in roughly fifteen minutes.

Pairing with Architecture and Reliability

For readers who want the architectural reasoning behind the conceptual layer documented here — why the platform separates surfaces the way it does, why environment separation is structural rather than procedural, why ownership boundaries hold under pressure — pair Shared Concepts with the Architecture and Reliability section. The architectural pages explain the structural decisions; the concepts here explain the operational vocabulary that follows from those decisions.

The two pages read well together. Shared Concepts gives a working reader the words; Architecture and Reliability gives a structural reader the reasoning. Documentation authors writing internal SOPs against SGEN often cite both pages to ground their team's vocabulary and architectural understanding in one place.