Platform Values

SGEN is built on a set of explicit architectural decisions. Each decision chose one approach over a viable alternative. The choices are visible in the product — they shape how the admin works, how modules load, how publishing behaves, and how multi-site operations are organized.

This page documents those decisions: what was chosen, what was not chosen, and why. Understanding the values makes the platform's behavior predictable and reduces the friction of "why does it work this way?"

What is this for?

Platform values are the principles that governed structural decisions during SGEN's design. They are not marketing claims. They are architectural commitments with observable consequences in the product.

Read this page when a product behavior seems unusual and you want to understand the reasoning behind it. Read this page when you are building on top of SGEN and need to understand which behaviors are by design rather than by accident. Read this page when you are explaining SGEN to a stakeholder, a new team member, or an agency client and need to describe why the platform works the way it does.

Scope

This page covers:

• The five primary architectural values baked into SGEN.
• What each value chose and what it rejected.
• The observable consequences of each choice in the product.
• Where these values interact with each other.

This page does not cover:

• How to perform tasks — those live in Guides.
• Per-feature implementation detail — those live in per-module Reference pages.
• Business pricing or licensing decisions — those live on sgen.com.
• Future planned decisions — the values documented here are shipped and observable today.

Vocabulary

Value 1 — Multi-Site Over Silos

What SGEN chose: one account governs a portfolio of sites through a shared account layer. What SGEN did not choose: separate installs per site, separate credentials per site, no account-level visibility across the portfolio.

Before SGEN, managing multiple client sites meant logging into each one independently. There was no aggregate view of what was running, no centralized billing, no unified team management. Each site was a silo.

SGEN chose multi-site as a structural property, not an add-on. SG-Dashboard governs the portfolio. Every site the account holds appears there. Provisioning, billing, reporting, and team invitations operate at the account level — once, not per site.

The observable consequences in the product:

• SG-Dashboard exists at dashboard.sgen.com — a separate surface from any individual site admin.
• Creating a new site is a SG-Dashboard operation, not a per-site operation.
• Billing changes affect the account's portfolio, not a single site's configuration.
• Account-level users have access across the portfolio; site-level users are scoped to one site.

Why multi-site first matters: A 20-site agency portfolio on SGEN has 1 billing relationship, 1 team roster, 1 update cadence. The same 20 sites on a plugin-stack model have 20 billing relationships, 20 sets of credentials, and 20 independent update schedules. The multi-site structure compresses management overhead by an order of magnitude at scale.

Value 2 — Native Modules Over Plugins

What SGEN chose: capabilities ship inside the platform as first-class modules. What SGEN did not choose: a marketplace of third-party plugins that extend a thin core.

The plugin model has a known failure mode: Plugin Tower. A functional site requires 15, 20, 30 plugins. Each plugin has its own update schedule, its own compatibility constraints, and its own failure mode. An update to one plugin breaks another. A security patch to the CMS core requires every plugin to update before the site is safe. The result is update anxiety — operators deferring updates because the cost of an update failure is too high.

SGEN chose to ship capabilities — ecommerce, forms, events, bookings, members — as native modules inside the platform. A module ships, updates, and is maintained as part of the platform release cycle. It does not have its own update schedule. It does not have its own compatibility matrix against every other module. It does not create a dependency chain that breaks when one link fails.

The observable consequences in the product:

• Ecommerce, Forms, Events, and other capabilities live inside the admin — no separate install.
• Module updates ship with platform updates — there is no "update your plugins" step.
• Module behavior is covered by the platform's regression testing, not by a third-party vendor.
• Operators choose which modules to activate on a site — they are not installed independently.

What this means for operators: Zero plugin roulette. Zero update anxiety. The platform ships with what it ships with. When a new capability is needed, the question is whether SGEN's native module covers it — not which of twenty plugins to trust.

Value 3 — Opinionated Defaults Over Infinite Config

What SGEN chose: the platform ships with defaults that are correct for most operators. What SGEN did not choose: a blank-slate configuration where every setting must be touched before the site works.

Infinite configuration sounds like flexibility. In practice, it means operators spend hours in settings screens before writing a single line of content. Every setting that must be configured to make the site minimally functional is a configuration tax.

SGEN ships opinionated defaults. A new site is ready to publish content without touching any configuration screen. Defaults are chosen to be correct for the majority of use cases: sensible SEO defaults, reasonable image compression, useful redirect behavior, logical permission models. Operators configure when their use case diverges from the default — not as a prerequisite to using the platform.

The observable consequences in the product:

• A new site has a working SEO setup out of the box — meta defaults, sitemap, robots.txt.
• Image compression and format conversion have defaults that work for most publishing workflows.
• Redirect behavior on slug changes is on by default — old URLs do not become broken links when a slug changes.
• Permission roles ship with meaningful defaults — an Editor can create and edit but not publish; an Admin can do everything.

The constraint this creates: Opinionated defaults mean SGEN does not expose every configuration option. Some things the platform does cannot be turned off. Operators who need a behavior the default makes unavailable must use a workaround (Custom Codes, Custom CSS) or identify whether the option exists in settings. The trade-off is deliberate: depth of configuration is capped to maintain the correctness of the defaults.

Value 4 — Edit-in-Place Over Draft Branches

What SGEN chose: operators work on the live record directly, with publishing as the gate. What SGEN did not choose: a hidden draft-copy system where every edit creates a diverging branch that must be merged.

Draft-branch systems sound safe. In practice, they create confusion: which version is the current one, which version is scheduled, and which draft was never published and is now stale. The result is content operations that require version management expertise before publishing a blog post.

SGEN chose edit-in-place. A record (a page, a post, a product) exists in one state at a time. When an operator edits it, they are editing the record. When they publish, the record goes live. Staging environments provide the branch isolation that content teams need for previewing changes before they hit the live site — without creating hidden draft objects inside the live site's record system.

The observable consequences in the product:

• The admin shows one version of each record — the current state.
• Staging provides the preview-and-approve workflow for teams that need it.
• There is no "drafts folder" inside the record list — draft state is a publishing status on the record, not a separate copy.
• Publishing state (draft, scheduled, published, archived) is a field on the record, not a versioning construct.

When staging is the right tool: Operators who need to preview significant changes before they go live use the staging environment. The staging-to-live promotion moves content from the staging context to the live context. This is the structured branch model SGEN supports — environment-level, not record-level.

Value 5 — Governed Operations Over Ad-Hoc Access

What SGEN chose: platform operations go through structured, auditable flows. What SGEN did not choose: raw database access, direct file editing, or unconstrained shell-level operations.

Ad-hoc access is fast. It is also the source of most "I didn't mean to do that" incidents in CMS operations. A direct database edit bypasses validation. A raw file edit bypasses the publishing model. Neither is logged, audited, or reversible through the CMS itself.

SGEN governs operations through structured surfaces. Content changes happen through the admin. Configuration changes happen through settings screens. The platform validates inputs, logs changes, and applies the publishing model to every record that touches the live site.

The observable consequences in the product:

• All changes to site records go through the admin — there is no exposed file system for content operations.
• Publishing requires an explicit publish action — no content goes live by accident.
• The admin enforces field constraints — an invalid slug, an oversized upload, an unresolvable redirect — before saving.
• Audit logging is part of the platform, not a plugin.

What operators cannot do by design: Operators cannot write directly to the database through any SGEN admin screen. Operators cannot edit template files through the admin — theme customization goes through the Theme Editor or SG-Builder. These constraints are intentional governance, not missing features.

How the Values Interact

The five values are not independent. They reinforce each other.

Multi-site over silos requires governed operations — an account-level governance layer only works if operations inside each site are structured enough to be safe across all sites simultaneously.

Native modules over plugins requires opinionated defaults — if every module required configuration before it was usable, the native-module model would still impose a configuration tax.

Opinionated defaults require governed operations — defaults are only trustworthy if the platform validates that inputs stay within the expected range.

Edit-in-place over draft branches works because governed operations enforce publishing as the gate — operators can edit directly because publishing is explicit, validated, and reversible via staging.

Examples

Example 1 — Explaining why there is no plugin marketplace

A new operator asks why they cannot add a plugin to SGEN the way they added plugins to their previous CMS. The answer is Value 2. SGEN chose native modules because the plugin model creates update anxiety and compatibility failures at scale. The capability they need is either already a native module in SGEN or is on the module roadmap. If neither, Custom Codes provides a targeted injection point for third-party scripts that do not need to be full CMS modules.

Example 2 — Understanding why there is no drafts folder

An operator used to a different CMS expects to find a "drafts" folder in the Pages list. SGEN does not have one. The answer is Value 4. Draft state is a publishing status on the page record (draft). The page appears in the Pages list with a draft badge. It is not a hidden copy. The operator publishes the draft by opening it and clicking Publish — no merge step, no version history to resolve.

Example 3 — Diagnosing a "why can't I do this" moment

An operator wants to edit a theme file directly from the admin. The admin does not provide a raw file editor. The answer is Value 5. Theme file editing bypasses the theme validation model. The correct path is the Theme Editor (for theme-level settings) or SG-Builder (for page-level visual adjustments). The constraint is not a missing feature — it is a deliberate governance boundary.

Edge cases

When the opinionated defaults are wrong for a use case. Not all defaults are correct for all operators. An operator who needs a non-standard publishing model, an unusual SEO configuration, or a custom permission structure can configure those areas. The defaults are a starting point, not a cage. The Reference page for each feature documents what is configurable and what is fixed.

When multi-site creates complexity for a single-site operator. A single-site operator on SG-Dashboard still has an account layer even though their portfolio has one site. The account layer is lightweight in the single-site case — the portfolio screen shows one site card. The governance overhead is minimal. The value of the structure appears when the portfolio grows.

When native modules do not cover a capability the operator needs. Custom Codes covers injection of third-party scripts that do not need to be native modules. Integrations covers connections to external services (payment processors, email platforms, CRM systems) that SGEN governs through structured connectors. The gap between "needs a native module" and "can be solved with Custom Codes or Integrations" is narrow in practice. When the gap is real, the operator's request enters the module roadmap.

Where to find it

This page is part of the Shared Concepts Reference section at docs.sgen.com. Navigate to Reference → Shared Concepts → Platform Values.

The five values are not a configuration screen. They are architectural decisions that explain why the admin works the way it does. Individual consequences of these values appear throughout the per-module Reference pages as notes on default behavior and configuration scope.

Related features

• 4-Pillar Diagram — how the four-pillar structure reflects Value 1 (multi-site) and Value 2 (native modules).
• Governance Overview — the release governance model that reflects Value 5 (governed operations).
• Shared Concepts Overview — the cross-platform vocabulary that these values underpin.
• SGEN Naming Conventions — the naming discipline that reflects Value 3 (opinionated defaults apply to language as well as configuration).