One public shell
The major marketing and reference pages share one structured content model and one rendering shell.
How the public pages, documentation routes, editable content store, and live publishing flow work together as one coherent product system.
The RafayGen product is easiest to understand when you stop thinking of it as a website with a few extra routes and start thinking of it as one operating system with multiple public and protected surfaces.
That shift matters because the public pages, the docs library, the AI workspace, the admin routes, and the content store all influence one another. If you treat them as isolated projects, the product becomes inconsistent quickly. If you treat them as one system, the structure starts doing useful work for you.
The major marketing and reference pages share one structured content model and one rendering shell.
Public page content is persisted in the site database, which means the live experience has a stable editable source of truth.
Source content changes are synchronized into the live store through explicit publishing steps instead of hidden manual edits.
A product becomes easier to change when the team shares the same mental model of where truth lives. In RafayGen, that truth is not limited to the visible page. It includes the structured content model, the routes that render it, the database that persists it, and the verification habits that confirm the live result.
If one contributor believes the homepage is source-driven while another assumes the database is authoritative, changes will drift. The operating model exists to prevent that kind of confusion before it starts.
The public site includes marketing pages, documentation pages, and other outward-facing routes designed to explain the product and guide the next action. These routes matter because they are often the first place a future user or collaborator meets the system.
Those routes should sound like they belong to the same product. They should also be structured so they can be edited, expanded, and verified without turning every change into a scavenger hunt.
The AI workspace, admin routes, and other protected flows are not secondary. They are the operating interior of the product. Public pages create expectation. Working surfaces fulfill that expectation.
That means product language, state handling, and route behavior should line up across the public and protected sides. When they do not, the system loses trust even if each surface looks fine in isolation.
Public pages are backed by a structured content model that can be synchronized into the live database. This is the key to keeping copy, layout blocks, and long-form sections editable without hardcoding every phrase directly into route components.
A healthy content store gives the team three benefits:
a repeatable place to update page structure
a safe fallback model when incomplete data is encountered
a clean path for publishing full page payloads into the live environment
Documentation is not a separate marketing exercise. It teaches the system. That makes it part of the product operating model, especially for a stack that includes AI routes, protected update flows, and live content publishing.
When docs are written from the same model that powers the product, onboarding gets faster and support load drops. When docs are written from memory, they become historical fiction.
Any meaningful product change should protect the relationship between these layers:
the structured source model
the route that renders it
the persistence layer that stores live page state
the documentation that explains how the change should be understood
the verification step that confirms the live route still matches intent
If even one of those layers is skipped repeatedly, the product may continue shipping while becoming harder to trust.
Before you make a change, ask a simple question: does this edit preserve coherence across public explanation, live behavior, and future handoff?
If the answer is no, the change needs a stronger operating model, not just a faster merge.
Next steps
Next step
Publishing WorkflowMove from the system map into the exact path that turns source updates into live page changes.
Next step
Team OnboardingSee how new contributors should learn the system without relying on informal context.
Next step
Back to DocsReturn to the docs library to choose another article or route reference.