Learn structure first
A contributor who understands the route and content shape makes fewer accidental mistakes.
A practical first-week path for new contributors who need to understand the product shape, make safe changes, and verify live results.
Good onboarding should reduce dependence on folklore. A new contributor should not have to decode the system by asking five people which layer owns what.
The point of onboarding here is simple: understand the product shape, understand where truth lives, understand how changes move, and understand how to verify the live result before calling the work done.
A contributor who understands the route and content shape makes fewer accidental mistakes.
The first updates should reinforce the operating model rather than encourage blind edits.
A contributor is not fully onboarded until they can confirm a live result against intention.
Start by learning the product at the level of shape, not implementation detail. Which public routes exist? Which protected routes matter most? Where does live page content come from? Which docs explain the update path?
This gives the contributor a frame. Without it, even a simple copy change feels riskier than it is.
The next step is to understand how public page content is structured. Modern pages are not only hero sections and bullet lists. They may contain multiple long-form block types, article links, CTA objects, code samples, and FAQ data.
This is useful because it teaches the contributor to think in terms of page systems rather than isolated strings.
A contributor should visit the key public routes and the important protected routes directly. That includes the homepage, service pages, docs library, at least one docs article, the AI workspace, and any admin or publishing routes relevant to their role.
Seeing the routes live reinforces the relationship between source structure and visible behavior.
The first real change should be small enough to verify easily but structured enough to reinforce the model. A weak first task is one that teaches the contributor to patch around the system. A strong first task teaches the contributor to work with the system.
Examples of strong first tasks include:
updating a structured page block
improving a linked docs article
validating a publish and documenting the verification steps
By the end of the first week, a contributor should be able to explain how a public page change moves from source to live, what needs to be checked after publish, and how the docs relate to the working product.
That explanation is important. If someone can explain the model cleanly, they are much more likely to work cleanly inside it.
There are a few patterns that slow onboarding down dramatically:
teaching route trivia before system shape
treating docs as optional reading instead of part of the product
normalizing manual one-off edits before teaching the canonical workflow
ending onboarding before the contributor has verified a live result
Onboarding is not complete when access is granted. It is complete when the contributor can preserve coherence across source structure, live behavior, documentation, and release verification.
Next steps
Next step
Read the System MapGo back to the operating model if you want the architectural frame behind the onboarding sequence.
Next step
Study the Publish PathReinforce onboarding by learning the explicit workflow for safe public content changes.
Next step
Back to DocsReturn to the docs library and move through the rest of the reference set.