How SGEN Docs is organized

SGEN Docs has six content classes: Guides (how-to), Reference (exact field detail), Changelog (released changes), What's New (editorial highlights), Roadmap (planned work), and Status (live platform state). Knowing which class to open for a given question is the whole skill. Most pages are public. Some pages show deeper operational content when you're authenticated as an internal user. Read this once and the docs make sense.

Six content classes

Each class answers a different question. "How do I do X?" is a Guide. "What does field Y mean exactly?" is Reference. "What changed?" is Changelog. Knowing the class gets you to the right page fast.

Public by default

Most pages are visible to anyone. Authenticated internal users see additional depth on certain pages — but public pages answer the public question completely. Authentication adds depth, not gates.

Read once, navigate always

This is a reference page. Read it once to orient, return to check the map when you're lost. The reading order and question-to-class selectors are the repeatable tools.

The content classes

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

ClassWhat it answersWhere it lives
GuidesHow to use a feature, end to end/docs/start-here/, /docs/platform/, /docs/operations/
ReferenceExact field names, allowed values, behavior boundaries/docs/reference/
ChangelogWhat changed, when, which surface/docs/changes/changelog
What's NewEditorial highlights from launches/docs/whats-new/
RoadmapPlanned and in-progress work (approved for publication)/docs/changes/roadmap
StatusLive operational state — incidents, maintenance/docs/changes/status
"How do I do X?"

Guides

"What does field Y mean exactly?"

Reference

"What changed in the last release?"

Changelog

"Is there something worth knowing about?"

What's New

"What's coming next?"

Roadmap

"Is the platform up right now?"

Status

Guides

Human-readable docs that explain how to use the platform — section landings, feature pages, walkthroughs.

Example: "How do I invite a teammate to one of my sites?" → SG-Core → Users, which explains the Members and Invitations flow step by step.

Reference

Structured per-feature reference — exact field names, options, behavior boundaries. Shorter than Guides. Reference is currently under construction; most pages in this section exist as scaffolds.

Example: "What are the allowed values for the Site Status field?" → Reference enumerates each value with its boundary behavior. Guides tell you when to change it; Reference tells you exactly what each option does.

Changelog

Released changes only. Append-only; each entry has a date and a summary. Filter by area, class (added / improved / fixed / removed), or date.

Example: "Did anything change with Backups in the last two weeks?" → Changelog, filter by SG-Dashboard / Backups.

What's New

Editorial highlights from launches — hand-curated, not exhaustive. Format: featured post with summary, primary CTA, and tags.

Example: "I haven't logged in for three months. What's worth knowing?" → What's New for headline-worthy launches; branch to Changelog for the complete list.

Roadmap

Planned and in-progress work approved for public visibility. State labels (planned, active, shipped) make commitment level explicit.

Example: "Is per-page content history coming?" → Roadmap. If it's listed, the team has committed to it publicly. If it isn't, they haven't.

Status

Live operational condition — current incidents, degradations, maintenance windows, recent resolutions.

Example: "My site feels slow this morning. Is something wrong?" → Status. Active incidents and maintenance windows live there. If Status shows nothing, the issue is likely scoped to your site.

Reading order

For a new SGEN user, the recommended path:

1
What is SGEN — platform definition.
2
Why SGEN exists — the rationale.
3
This page — content classes and reading model.
4
Documentation map — the full IA.
5
The section landing for your task — don't deep-link to a feature page without reading its section landing first.
6
Reference only when you need exact detail — heavier reading; save it for when it matters.

How search works across docs

Search returns matches from all six content classes by default.

Search by feature name first

"Site Manager" finds the SG-Dashboard feature page.

Search by surface name when uncertain

"SG-Modules forms" narrows to forms docs under the Modules group.

Filter by class

Use the filter chips at the top of the search page to narrow to one content class — helpful when you want only Changelog entries for a feature.

Use exact phrases for error strings

Reference pages and troubleshooting sections often quote UI strings verbatim.

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

When search misses: index lags fresh content by a short window. Try the section landing, the Documentation map, or a direct URL — most pages follow /docs/<group>/<surface>/<feature>. If a page genuinely isn't indexed, flag it via the page feedback affordance.

How to give feedback when a doc is wrong

Every page has a feedback affordance. Use it when a step doesn't match the UI, a claim looks outdated, a linked page returns 404, a code example misbehaves, or a page contradicts another on the same topic.

Substantive corrections
Next docs release

Corrections that don't block current work are addressed in the next docs release.

Critical errors
Same-day patch

Broken safety guidance or a wrong default in a destructive action is patched the same day.

Minor copy fixes
Weekly sweep

Typos and small wording corrections go through the weekly sweep.

Blocking issue
Open a support ticket

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

Audience and visibility

SGEN Docs is public by default. Most pages are visible to anyone visiting docs.sgen.com. Some pages show additional content when you're authenticated as an internal SGEN user: deeper operational notes, internal links to runbooks, and implementation detail not appropriate for public exposure. The public version answers the public question completely. Internal expansions are depth, not gates.

Public
docs.sgen.com

Customer-facing. Operator language. Architectural posture only — no internal topology, no per-customer infra.

Internal
Behind auth

Engineering documentation. Validated and approved per release. Implementation truth, controller details, runbooks.

Pages marked stub, pending, or unverified

You'll occasionally see pages with markers.

MarkerMeaning
status: stub-pending-contentPlaceholder — the platform surface exists but the doc hasn't been written yet
pendingDoc is in draft
unverifiedClaim hasn't been validated against engineering
REQUIRES ENGINEERING VALIDATIONFlagged in the body — treat as not-yet-truth

When a stub blocks you: try the relevant section landing or Reference. Or open a support ticket.

How pages get updated

The docs release cadence runs alongside the platform cadence.

CadenceScope
Same-dayCritical safety corrections — wrong default in a destructive action, broken security guidance
WeeklySubstantive copy improvements, missing cross-links, expanded examples, new screenshots
Per-releaseNew feature documentation, drafted from QA-tested feature cards
QuarterlyIA reviews — section restructuring, group renames, URL realignments (old URLs mapped to new)

How to know if a page is current: each page carries a last_updated date. If a page hasn't been touched in many months and the feature has clearly evolved, treat the page as suspect — especially for destructive actions. Cross-check the Changelog for shipped changes since the doc was last touched.

How docs and platform stay in sync: features flow from engineering → QA (feature card with shipped behavior) → docs writer (drafts from QA evidence, not the spec) → voice canonical → docs release. Drafting from QA evidence keeps the doc honest when shipped behavior drifts from the original spec.

What to do next