SGEN 4-Pillar Diagram

SGEN is organized into four pillars. Each pillar owns a distinct tier of platform behavior. No two pillars own the same thing. Together they compose one governed operating platform for multi-site content management.

The four pillars are: SG-Core, SG-Modules, SG-Dashboard, and SG-Builder.

What is this for?

This page is the canonical structural map of the SGEN platform. It defines what each pillar owns, how pillars interact with each other, and where cross-pillar behavior is governed.

Read this page when you need to understand the structural shape of SGEN before working across multiple surfaces. Read this page when you are deciding which pillar a feature belongs to — for scoping work, writing documentation, or building integrations. Read this page when a feature's behavior spans two pillars and you need to know which pillar owns the governing authority.

Scope

This page covers:

• The definition and ownership territory of each of the four pillars.
• How the pillars compose into one operating platform.
• Cross-pillar interaction patterns.
• The operating model for cross-pillar features.
• What lives outside the four-pillar model.

This page does not cover:

• Per-module feature detail — those live in the module's own Reference page.
• Per-pillar procedural tasks — those live in Guides.
• Release changes to individual pillars — those live in What's New or Changelog.

Reference

The tables below are the canonical lookup for pillar ownership, cross-pillar interactions, and what lives outside the four-pillar model. Each pillar name, its tier, its ownership scope, and its primary surface are fixed and do not change between releases except when a new pillar is added (a structural change that ships with a major What's New announcement).

The Four Pillars

Each tier has a distinct operating scope. Account tier (SG-Dashboard) governs the portfolio of sites. Site tier (SG-Core, SG-Modules) governs the content and configuration of one site. Page tier (SG-Builder) governs the visual presentation of one page within one site.

The tiers are nested. SG-Dashboard contains the portfolio. SG-Core and SG-Modules operate inside a site within that portfolio. SG-Builder operates on a page within a site.

SG-Core

SG-Core is the foundational site-tier pillar. It owns the content records and the site-level configuration that every site in the SGEN platform requires.

SG-Core owns:

• Pages — the static page inventory and the page publishing model.
• Blog — posts, categories, tags, and the post scheduling model.
• Media — the file library, image optimization settings, and attachment handling.
• Custom Codes — head and body injection for third-party scripts and tracking snippets.
• Custom CSS — site-level CSS that applies across all pages.
• SEO — meta titles, descriptions, canonical rules, sitemap generation, robots control.
• Redirects — permanent and temporary redirect rules for URL management.
• Fonts — typeface configuration and font-loading behavior.
• Site Settings — name, timezone, locale, contact information.
• Users — site-level user accounts and role assignments.

SG-Core does not own layout or visual composition — that is SG-Builder. SG-Core does not own add-on functionality like ecommerce or forms — that is SG-Modules. SG-Core does not own account-tier operations like billing or multi-site reporting — that is SG-Dashboard.

SG-Modules

SG-Modules is the add-on capability layer at the site tier. Modules in this pillar extend site functionality beyond the content records owned by SG-Core. Each module is independently loadable — a site carries the modules its plan includes.

SG-Modules owns:

• Ecommerce — products, orders, coupons, payment integrations, storefront behavior.
• Forms — form builder, submission collection, field validation, notification routing.
• Events — event listings, RSVP management, and calendar display.
• Bookings — appointment scheduling, availability rules, and booking management.
• Members — gated access, membership levels, and member account management.
• Reviews — review collection, moderation, and display configuration.

SG-Modules does not own the content record model — that belongs to SG-Core. SG-Modules does not own the page layout that displays module content — that belongs to SG-Builder. When a module creates a record type (a product, a form submission, an event), the record is governed by that module's own schema, not by the SG-Core page schema.

Module availability by plan: Not every module is active on every site. The plan determines which modules are loaded. A module's Reference page documents which plan tiers include it.

SG-Dashboard

SG-Dashboard is the account-tier pillar. It governs the portfolio of sites the account holds, not the content inside any individual site.

SG-Dashboard owns:

• Site provisioning — creating new sites, configuring site domains, assigning plans.
• Multi-site portfolio — the portfolio view of all sites, their status, and plan details.
• Billing — subscription management, plan upgrades, payment method, invoices.
• Account reporting — aggregate analytics across the portfolio.
• Account users — account-level team members and their access roles.
• Support — account-level support ticket history and submission.

SG-Dashboard does not manage content inside a site — that is SG-Core. When an operator opens a site card in SG-Dashboard, control passes to that site's SG-Core admin context. The boundary between SG-Dashboard and SG-Core is structural: dashboard.sgen.com vs {site-domain}.com/sg-admin/.

SG-Builder

SG-Builder is the page-tier pillar. It governs the visual composition and layout of individual pages within a site.

SG-Builder owns:

• Page layout — the section and column structure of a page.
• Component editing — text, images, buttons, cards, galleries, and other visual components.
• Theme presentation — the visual application of a site's theme settings to a specific page.
• Breakpoint behavior — per-device layout rules (desktop, tablet, mobile).
• Visual overrides — per-page styling that supplements or overrides the site-level theme.

SG-Builder does not govern the page's existence, slug, or publication state — those belong to SG-Core Pages. SG-Builder does not own site-level theme settings (colors, typography defaults) — those belong to SG-Core Site Settings. The content record (the Page) is owned by SG-Core. The visual presentation of that content record is owned by SG-Builder. Both must be in agreement for a page to look right and function correctly.

Cross-Pillar Interactions

Cross-pillar interactions occur when a feature's behavior touches two pillars. The governing authority in a cross-pillar interaction is always the pillar that owns the primary behavior.

When two pillars operate on the same surface, neither overrides the other's ownership. They cooperate at their boundary. Documentation that describes a cross-pillar feature will always name both pillars and identify which one owns which behavior.

What Lives Outside the Four Pillars

The four pillars cover the platform's operating surface. A small set of capabilities sits above the pillar model:

• Infrastructure — server provisioning, CDN, backup, and uptime governance.

These are operated by SGEN and are not exposed as customer-configurable settings in any pillar.

• Integrations — third-party service connections that span multiple pillars.

An integration connects an external service to records in SG-Core or SG-Modules; the integration layer mediates between them.

• Workflows — multi-step automated processes that can trigger actions across SG-Core, SG-Modules, and SG-Dashboard.

The Workflow engine sits above the pillar model and orchestrates cross-pillar operations.

• Migration and Import — tools for importing content from external platforms.

Import targets are per-pillar (pages land in SG-Core, products land in SG-Modules) but the import operation is orchestrated centrally.

Examples

Example 1 — Scoping a build across pillars

An operator is building a membership site with gated blog content. They map the work to pillars before starting. Blog posts live in SG-Core. The members gating lives in SG-Modules (Members module). The visual layout of the gated blog page lives in SG-Builder. The site was provisioned in SG-Dashboard. Scoping the work by pillar first surfaces which admin screens to open and which team members are responsible for which area.

Example 2 — Diagnosing a cross-pillar issue

An operator updates a product's details in SG-Modules but the product display page still shows the old data. Using the pillar model, they identify that the product record (SG-Modules) and the display template (SG-Builder) are separate. The record updated correctly. The display template has a cached component. The fix is in SG-Builder, not SG-Modules. The pillar model makes the diagnosis without escalating to support.

Example 3 — Explaining the platform to a new team member

A new content editor joins an agency team using SGEN. The team lead opens this page and walks through the four pillars in five minutes. "You will work in SG-Core for writing and publishing content. SG-Builder is for layout, which the designers handle. SG-Dashboard is where billing lives — you don't need to touch it. SG-Modules is where ecommerce lives — that's the dev team's area." The pillar model organizes responsibilities without a long onboarding document.

Edge cases

A feature that appears in two pillars. Some features appear to belong in two pillars because they expose configuration at two levels. SEO is owned by SG-Core at the site level (site-wide meta defaults) and at the page level (per-page meta overrides). The governing rule: site-level defaults belong to SG-Core; page-level overrides belong to the SG-Builder page editor. When the two conflict, the page-level override wins for that specific page.

SG-Builder without SG-Core. SG-Builder cannot operate on a page that SG-Core has not provisioned. Every page must exist as a record in SG-Core before SG-Builder can edit it. This is structural — SG-Builder is a presentation layer, not a page-creation layer.

SG-Modules without a matching SG-Builder template. A module can create records without a visual template. Products in SG-Modules have default display templates that load without customization. A custom template in SG-Builder overlays the default but is not required. The record functions without the custom template and renders via the default presentation.

Where to find it

This page is part of the Shared Concepts Reference section at docs.sgen.com. Navigate to Reference → Shared Concepts → 4-Pillar Diagram.

In the admin, the four-pillar organization maps to the navigation areas:

• SG-Core content is in the admin's GENERAL and CONFIGURATION sidebar groups.
• SG-Modules content is in the admin's MODULES and STORE MANAGEMENT sidebar groups.
• SG-Dashboard is at dashboard.sgen.com — a separate URL from the site admin.
• SG-Builder opens from the admin's page list by clicking the visual editor button on any page.

Related features

• Shared Concepts Overview — the cross-platform vocabulary the pillar model assumes.
• SGEN Naming Conventions — the correct spelling and capitalization of all four pillar names.
• Platform Values — the reasoning behind organizing SGEN into four pillars rather than one monolithic admin or a plugin stack.
• Governance Overview — how changes to individual pillars are governed, versioned, and announced.
• How to Read Reference Docs — how the pillar structure maps to the Reference library's navigation hierarchy.