How to Read Reference Docs
Reference pages are the lookup layer of the SGEN documentation library. They answer two questions: what is this feature, and what does it own. They do not walk through tasks. Tasks live in Guides.
Understanding which shape to open — Reference or Guides — saves time. This page explains the distinction, the navigation patterns inside the Reference layer, and the cross-reference conventions that connect pages together.
What is this for?
The Reference layer covers the full surface of the SGEN platform — every module, every field, every setting — as a stable lookup source. Each Reference page defines a feature's scope, its inputs and outputs, its relationship to adjacent features, and the edge cases that affect behavior. The layer does not teach tasks. It defines territory.
Read a Reference page when you need to know what a feature is before deciding how to use it. Read a Reference page when you need a precise definition of a field or a setting. Read a Reference page when you are writing documentation, building a workflow, or scoping an integration and need the authoritative description of what SGEN owns.
Reference pages are intentionally stable. They update when the platform changes. They do not change with new tutorials or task-specific additions.
Scope
This page covers:
- The structural difference between Reference pages and Guides.
- When to open each type.
- How Reference pages are organized and navigated.
- How cross-references inside the Reference layer work.
- The conventions used consistently across every Reference page in the library.
This page does not cover:
- Step-by-step task instructions — those live in Guides.
- Release-specific behavior changes — those live in What's New or Changelog.
- Internal engineering documentation — that is separate from the customer-facing library.
Reference vs Guides
The SGEN documentation library has two primary page types. Each answers a different question.
| Page type | Question it answers | Starts with | Updates when |
|---|---|---|---|
| Reference | What is this, and what does it own? | A definition or a scope statement | The platform changes |
| Guides | How do I complete this task? | A goal statement | A procedure changes |
A Reference page for the Blog module defines what the Blog module manages, what its fields are, how publishing works, and how it relates to Custom Codes and SEO settings. A Guide for the Blog module walks through creating a post, scheduling it, and verifying it appeared on the live site.
The same module has both. The Reference page is the map. The Guide is the route.
Open Reference first when you are orienting. Open Guides when you are doing.
Anatomy of a Reference Page
Every Reference page in the SGEN library follows the same section order. Learning the sections once lets you navigate any Reference page without re-reading the structure.
| Section | What it contains |
|---|---|
| Lead paragraph | One or two sentences placing the feature inside the platform. The definition. |
| What is this for? | The purpose of the feature and the purpose of this page. |
| Scope | What the feature covers. What it does not cover. |
| Examples | Concrete use cases with realistic data showing the feature in context. |
| Fields / Parameters / Vocabulary | The lookup surface — field names, accepted values, defaults, constraints. |
| Where to find it | Navigation path to the feature inside the admin. |
| Related features | Adjacent features with a sentence on the relationship. |
The Fields section is the lookup core. When you need a precise field name, an accepted value range, or a default, go directly to Fields.
Navigation Patterns
The SGEN Reference library is organized by surface and area. The top-level groupings map to the four pillars: SG-Core, SG-Modules, SG-Dashboard, SG-Builder. Within each pillar, areas group related modules. Each module has its own Reference page.
To navigate:
- Identify the pillar the feature belongs to — see 4-Pillar Diagram.
- Open the pillar's Reference landing page.
- Follow the area grouping to the module.
- Open the module's Reference page.
- Navigate to the section you need using the in-page heading anchors.
For cross-pillar features — features that touch more than one pillar — start at the pillar that owns the primary behavior. The Reference page for that primary feature will list the related pages in its Related Features section.
Sidebar nav on docs.sgen.com shows the full Reference hierarchy. Use it to scan the available Reference pages by pillar without reading each one.
Search on docs.sgen.com queries page titles and body text across all Reference pages. Search is fastest when you know a field name or a specific term. Browse the sidebar when you need to discover what Reference pages exist for an area.
Cross-Reference Conventions
Reference pages link to each other when a concept in one page depends on a concept defined elsewhere. The link is always to the canonical source. The page receiving the link does not redefine the concept — it refers to where the definition lives.
Three cross-reference types appear in the SGEN Reference library:
Inline links appear inside body text when the referenced page defines a term used in the current paragraph. Format: term. Follow the link when you need the full definition. Skip it when you recognize the term already.
Related Features section appears at the bottom of every Reference page. It lists adjacent features with a one-sentence description of the relationship. Use it to discover what else to read when a feature does not operate in isolation.
See also appears as a compact list inside sections that depend heavily on another area. It points at other Reference pages, Guide pages, or Shared Concepts entries. It does not replace reading those pages — it signals that they are relevant.
Examples
Example 1 — Orienting to a new module
An operator joins an agency team already using SGEN. They need to understand how Custom Codes works before they edit any snippet. They open the Custom Codes Reference page, read the lead paragraph and Scope section, then read the Fields section to learn what each field accepts. They do not open the Guide until they are ready to create their first snippet. The Reference page gives them the vocabulary and the mental model in under five minutes.
Example 2 — Finding a precise field name
A developer building an internal content SOP needs the exact name of the field that controls a blog post's publish state. They open the Blog Reference page, navigate to the Fields section, and find publish_status with its accepted values (draft, scheduled, published, archived). They copy the field name directly into the SOP. No guessing, no trial and error.
Example 3 — Navigating cross-pillar behavior
An operator notices that a Custom Code snippet they added to SG-Core's head section is not rendering as expected after a theme change in SG-Builder. They open the Custom Codes Reference page, read the Related Features section, find the link to the SG-Builder Themes Reference, follow it, and locate the section on theme override behavior. The cross-reference surfaces the answer without requiring a support ticket.
Edge cases
Reference page vs a Guide with the same name. Some areas have both a Reference page and a Guide. The Reference page is the definition. The Guide is the procedure. If both exist for the same area, open Reference first, then Guide. The Guide links back to the Reference in its Related Features section.
Shared Concepts entries vs per-module Reference pages. Shared Concepts defines cross-platform vocabulary — terms that appear across more than one surface. Per-module Reference pages define module-specific fields and behavior. If you are looking for a term definition that appears across multiple modules, start in Shared Concepts. If you are looking for a field specific to one module, go directly to that module's Reference page.
An area with no Reference page yet. Not every area in SGEN has a complete Reference page at launch. When a Reference page does not exist, the nearest parent area's landing page may have a brief scope table covering the missing area. The What's New section announces when new Reference pages ship.
A Reference page that contradicts the admin interface. The admin is the authoritative source of current behavior. When a Reference page and the admin disagree, the admin wins. File a feedback note from the docs page — the discrepancy is a documentation bug, not a platform bug.
Fields
The conventions used in Reference page Fields sections are consistent across the library.
| Convention | Meaning |
|---|---|
monospace field name | The exact field identifier |
default: value | The value SGEN uses when the operator has not set the field |
required | The field must have a value before the record saves |
optional | The field accepts an empty value |
accepts: [a, b, c] | The field only accepts the listed values |
max: N | The maximum character count or numeric value accepted |
read-only | The field is set by the platform and cannot be edited directly |
Reference pages use tables for field listings rather than prose. Tables let you scan to the row you need without reading every entry.
Where to find it
The Reference section of docs.sgen.com is accessible from the sidebar under Reference. Each pillar group in the sidebar expands to show its areas. Each area expands to show its module Reference pages.
Shared Concepts Reference pages, including this one, appear at the top of the Reference sidebar under Shared Concepts.
Related features
- Shared Concepts Overview — the cross-platform vocabulary that every Reference page assumes.
- SGEN Naming Conventions — the capitalization and slug rules used consistently in Reference page titles and field names.
- 4-Pillar Diagram — the pillar structure that organizes the Reference library's navigation hierarchy.
- Governance Overview — how Reference pages version with the platform, when they update, and the deprecation timelines.