How SGEN Docs is organized

SGEN Docs uses a few different page types. Each one answers a different question. Knowing which type you're reading saves you time.

This page covers the content classes (guides vs reference vs changelog vs status), the reading order, and the audience boundary (what's public versus what authenticated internal viewers see). Read this once and the rest of the docs make sense.

Field	Value
Audience	public
Area	welcome
Updated	2026-05-14
In this guide
---
What is this for?
Good use cases
When NOT to use this
Reading time
How this connects to other features
Before you start
The content classes
Reading order
How search works across docs
How to give feedback when a doc is wrong

What is this for?

This page explains the documentation system itself. Not the platform — the docs.

You read this page when you want to know:

• Whether to look in Guides, Reference, Changelog, Roadmap, Status, or What's New for a given question.
• The order to read docs as a new SGEN user.
• Why some pages have additional content visible only after authentication.
• How to interpret pages marked stub, pending, or unverified.

Good use cases

• You're new to SGEN Docs and want to know how to navigate.
• You found a page but the information you need feels missing — the answer may live in a different content class.
• You're trying to find a release note and don't know whether to check Changelog, What's New, or Status.
• You're authenticated as an internal user and want to understand what additional content you can see.
• You're trying to figure out whether a page describes current behavior or planned behavior.

When NOT to use this

• For the platform definition — that's What is SGEN.
• For the operational rationale — that's Why SGEN Exists.
• For the full IA map — that's Documentation Map.
• For specific feature documentation — open the relevant section landing.
• For pricing or marketing positioning — that's sgen.com.
• For the developer SDK reference — that's /docs/reference/ (under construction).
• For internal SGEN team operations — those live in private internal docs.

Reading time

This page takes about 5 minutes end to end. The downstream reads:

• Documentation Map — 10 minutes (skim and bookmark).
• Section landings — 3 to 5 minutes each.
• Feature pages — variable, typically 5 to 15 minutes.
• Reference pages — short and structured, usually 2 to 5 minutes per record.

Most operators read this page once on first visit and don't return. The IA stays in your head after you've used it for a week.

How this connects to other features

This page is part of the orientation set.

• Welcome — entry point.
• What is SGEN — platform definition.
• Why SGEN Exists — operational rationale.
• Documentation Map — full IA.

Read this one fourth. Once you know how the docs are organized, the map makes immediate sense.

Before you start

One thing to keep in mind.

The content classes described below are stable. Page-level content evolves with the platform — what's documented here is the system, not the current page count. If a count changes (more changelog entries, more guides), the system below still applies.

The content classes

SGEN Docs uses six content classes. Each answers a different question.

Guides

Human-readable documentation that explains how to use the platform.

• Includes section landings (e.g. SG-Core overview, SG-Dashboard overview) and feature pages (Users, Site Manager, Stage & Live).
• Written in the docs voice: direct, lived-in, technically grounded.
• Uses the brand-voice canonical for consistency.
• Lives under /docs/start-here/, /docs/platform/, /docs/operations/, /docs/architecture/.

Worked example: "How do I invite a teammate to one of my sites?" — this question belongs in Guides. Open SG-Core → Users. The page explains the Members and Invitations flow step by step.

Reference

Structured per-feature reference — exact field names, options, behavior boundaries.

• Used when you need to know precisely what something does.
• Shorter than guides. More structured. Less narrative.
• Lives under /docs/reference/.
• Currently under construction — most reference pages exist as scaffolds awaiting deeper content.

Worked example: "What are the allowed values for the Site Status field, and what does each one do?" — this is a Reference question. The Reference page enumerates each value with its boundary behavior. The Guide tells you when to change it; Reference tells you exactly what each option does.

Changelog

Released changes only. What changed, when it changed, which surface was affected.

• Append-only. Each entry has a date and a summary.
• Public entries visible to all. Internal entries visible after authentication.
• Lives at /docs/changes/changelog.
• Filter by area, class (added/improved/fixed/removed), or date.

Worked example: "Did anything change with the Backups feature in the last two weeks?" — open Changelog, filter by SG-Dashboard / Backups. You'll see every shipped change with date and one-paragraph summary.

What's New

Editorial highlights from launches, notable improvements, and headline updates.

• Hand-curated. Not every changelog entry appears here.
• Format: featured post with summary, primary CTA, and tags.
• Lives at /docs/whats-new/.

Worked example: "I haven't logged in for three months. What's worth knowing?" — open What's New. Editorial highlights tell you the headline-worthy launches, in narrative form. For the full list of changes, branch into Changelog from there.

Roadmap

Planned and in-progress work that's been approved for publication.

• Forward-looking. State labels (planned, active, shipped) make commitment level explicit.
• Not every internal initiative appears — only what's approved for public visibility.
• Lives at /docs/changes/roadmap.

Worked example: "Is per-page content history coming?" — Roadmap is the right place. If it's planned, it'll be listed with a state label. If it isn't on Roadmap, the team hasn't committed to it publicly yet.

Status

Current operational condition of the platform and service surfaces.

• Live. Current incidents, degradations, maintenance windows, recent resolutions.
• Used for "is something broken right now."
• Lives at /docs/changes/status.

Worked example: "My site feels slow this morning. Is something wrong on the platform?" — open Status. Active incidents, recent resolutions, and maintenance windows all live there. If Status shows nothing, the issue is more likely scoped to your site or your audience's network.

How to choose

Use the right class for the question.

• "How do I do X?" → Guides
• "What does field Y mean exactly?" → Reference
• "What changed in the last release?" → Changelog
• "Is there something cool I should know about?" → What's New
• "What's coming next?" → Roadmap
• "Is the platform up right now?" → Status

Reading order

For a new SGEN user, the recommended path:

1. Read Welcome to SGEN Docs.

Five-minute orientation.

2. Read What is SGEN.

Platform definition.

3. Read Why SGEN Exists.

Operational rationale.

4. Read this page.

Content classes and reading model.

5. Read Documentation Map.

Full IA.

6. Open the section landing for your task.

Don't go directly to a feature page. Read the section landing first.

7. Use Reference only when you need exact detail.

Reference is heavier reading. Save it for when you need it.

How search works across docs

Search returns matches from all six content classes by default — Guides, Reference, Changelog, What's New, Roadmap, and Status surfaces are all indexed.

A few useful patterns:

• Search by feature name first. "Site Manager" finds the SG-Dashboard feature page; "site-manager" without the space also resolves correctly.
• Search by surface name when you're not sure. "SG-Modules forms" narrows to forms documentation under the Modules group.
• Filter by class. When the result list is mixed, filter chips at the top of the search page narrow to one class. Useful when you want only Changelog entries for a feature.
• Use exact phrases for error strings. When you've hit a specific behavior or error, copy the exact UI string into search. Reference pages and troubleshooting sections often quote those strings verbatim.

Search does NOT cover marketing pages on sgen.com. For pricing or marketing positioning, search the marketing site directly.

When search misses

Search lags fresh content by a short index window. If you know a page exists but search doesn't surface it, try:

• The section landing for the feature's surface.
• The Documentation Map for the full IA.
• A direct URL guess — most pages follow /docs///.

If the page genuinely isn't indexed and you needed it, that's a docs bug worth flagging.

How to give feedback when a doc is wrong

Every page has a feedback affordance. Use it when:

• A step doesn't match what you see in the UI.
• A claim looks outdated since the platform shipped a change.
• A linked page returns 404 or stub content.
• A code example or shortcode doesn't behave as documented.
• The page is missing a section you'd expect (e.g. no troubleshooting on a feature with known failure modes).
• A page contradicts another page on the same topic.

Feedback routes to the docs team. Substantive corrections roll into the next docs release. Critical errors (broken security guidance, wrong default in a destructive action) ship as same-day patches. Minor copy fixes accumulate into a weekly sweep.

If a doc bug is blocking your work right now, also open a support ticket — the doc fix follows, but the support team can unblock you immediately.

Audience and visibility

SGEN Docs has a public-default audience. Most pages are visible to anyone visiting docs.sgen.com.

Some pages have additional content that surfaces only when you're authenticated as an internal SGEN user. That content typically includes:

• Deeper operational notes.
• Internal links to private records or runbooks.
• Implementation detail not appropriate for public exposure.

If you're a customer reading the docs, you see the public surface. That's the canonical content. Internal expansions are extras, not gates — the public version answers the public question completely.

Why some content is internal-only

Internal-only content typically falls into three categories:

• Implementation specifics. Vendor names, infrastructure choices, internal API names. These stay engineering-only because customers don't benefit from them and competitors don't need them.
• In-flight operational state. Active troubleshooting threads, escalation contacts, incident-response procedures. These need access controls because they change quickly and reference internal teams.
• Pre-release content. Documentation for features that are shipped to a subset of customers but not yet generally available. Surfacing it broadly would create confusion.

The principle: customer-facing content describes behavior; internal content references implementation. The two layers don't conflict — they cover different questions.

What you can always rely on

• Every public page is canonical for the question it answers in customer-readable language.
• Public pages don't omit critical safety information for the sake of internal-only access.
• The IA shape is the same whether you're authenticated or not. Authentication adds depth on certain pages; it doesn't restructure the navigation.

Pages marked stub, pending, or unverified

You'll occasionally see pages with markers like:

• status: stub-pending-content — placeholder. The surface exists in the platform but the doc hasn't been written yet.
• pending — the doc is in draft.
• unverified — claim hasn't been validated against engineering.
• REQUIRES ENGINEERING VALIDATION — flagged in the body. Treat as not-yet-truth.

Use the relevant section landing or Reference for the most current information when a stub blocks you. Or open a support ticket.

Steps

To get oriented in the documentation system, follow this order.

1. Read this page (you're here).

You now know the six content classes.

2. Open Documentation Map.

See the full IA so you know where every class lives.

3. Bookmark the streams you'll use most.

Most users return frequently to Changelog, Status, and the section landing for their main work surface.

4. Use Search across all classes.

Search returns results from Guides, Reference, Changelog, What's New, and Roadmap. Narrow by class if needed.

5. When in doubt, open the section landing first.

Don't deep-link to feature pages without context. The landing is the orientation.

What success looks like

You're using SGEN Docs well when:

• You can match a question to the right content class without thinking.
• You know whether a behavior should be in a Guide, a Reference page, or a Changelog entry.
• You stop conflating "what's new" with "what changed" — they're separate streams.
• You don't ping support for things the Status page would answer.
• You catch yourself reading the section landing before the feature page.

What to do if it does not work

• You can't find what content class a question belongs to. Use the IA recap above ("How to choose"). When still unclear, open Documentation Map.
• A page contradicts another page. Reference is most precise; Guides are most readable; Changelog and Status are most current. When they conflict, the most recent stream usually wins. Open a support ticket if it persists.
• A stub blocks you. Try the section landing. Open a support ticket if you need the missing content.
• You expected docs in one location but found them elsewhere. The IA realigned 2026-04-30. Old /guides/ and /docs/start/ URLs are superseded — use the canonical paths.

How pages get updated

The doc release cadence runs alongside the platform release cadence:

• Same-day — critical safety corrections (wrong default in a destructive action, broken security guidance, factual error in a destructive procedure).
• Weekly — substantive copy improvements, missing cross-links, expanded examples, new screenshots.
• Per-release — new feature documentation written from QA-tested feature cards. Lands when the feature lands publicly.
• Quarterly — IA reviews. Section restructuring, group renames, IA realignments. Old URLs are mapped to new ones.

You don't need to know the cadence to use the docs. The detail is here for operators who notice the rhythm.

How to know if a page is current

Each page carries a last_updated date in its metadata. If a page hasn't been touched in many months and references a feature that has clearly evolved, treat it as suspect — especially for destructive actions. Cross-check against the Changelog for shipped changes since the doc was last touched.

If a page is genuinely outdated, the page-level feedback affordance routes the report to the docs team for refresh.

How the docs and the platform stay in sync

A new feature flows from engineering through to documentation through a defined path:

• Engineering ships the feature through the platform release pipeline.
• QA tests the feature and produces a feature card with shipped behavior recorded.
• Docs writers draft from the QA-tested feature card so the doc reflects shipped reality, not the original spec.
• Voice canonical applies so the new doc reads in the same voice as the rest of the surface.
• Doc lands in a release that paste-publishes to docs.sgen.com.

The discipline matters because shipped features sometimes drift from their original spec. Drafting from QA evidence rather than the spec keeps the doc honest.

Related reading

• Welcome to SGEN Docs — Entry point.
• What is SGEN — Platform definition.
• Why SGEN Exists — Operational rationale.
• Documentation Map — Full IA.
• Changes → Changelog — Released history.
• Changes → Roadmap — Planned work.
• Changes → Status — Current operational condition.
• What's New — Editorial highlights.
• Reference (under construction) — Per-feature structured reference.
• Architecture — Platform-position pages for design rationale.

Related reading

Topic
Documentation Map
Welcome to SGEN Docs
SGEN in 90 seconds
Welcome to SGEN Docs
What is SGEN
Why SGEN Exists