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.
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.
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.
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.
| Class | What it answers | Where it lives |
|---|---|---|
| Guides | How to use a feature, end to end | /docs/start-here/, /docs/platform/, /docs/operations/ |
| Reference | Exact field names, allowed values, behavior boundaries | /docs/reference/ |
| Changelog | What changed, when, which surface | /docs/changes/changelog |
| What's New | Editorial highlights from launches | /docs/whats-new/ |
| Roadmap | Planned and in-progress work (approved for publication) | /docs/changes/roadmap |
| Status | Live operational state — incidents, maintenance | /docs/changes/status |
→ Guides
→ Reference
→ Changelog
→ What's New
→ Roadmap
→ 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:
How search works across docs
Search returns matches from all six content classes by default.
"Site Manager" finds the SG-Dashboard feature page.
"SG-Modules forms" narrows to forms docs under the Modules group.
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.
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.
Corrections that don't block current work are addressed in the next docs release.
Broken safety guidance or a wrong default in a destructive action is patched the same day.
Typos and small wording corrections go through the weekly sweep.
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.
Customer-facing. Operator language. Architectural posture only — no internal topology, no per-customer infra.
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.
| Marker | Meaning |
|---|---|
status: stub-pending-content | Placeholder — the platform surface exists but the doc hasn't been written yet |
pending | Doc is in draft |
unverified | Claim hasn't been validated against engineering |
REQUIRES ENGINEERING VALIDATION | Flagged 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.
| Cadence | Scope |
|---|---|
| Same-day | Critical safety corrections — wrong default in a destructive action, broken security guidance |
| Weekly | Substantive copy improvements, missing cross-links, expanded examples, new screenshots |
| Per-release | New feature documentation, drafted from QA-tested feature cards |
| Quarterly | IA 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.
