Documentation organized the way you'll actually use it.

Don't start here. The pages in this section explain how the components work, which is a different question from what changes for my organisation.

The shortest route is: an industry page close to your context, telling a complete scenario in non-technical language; then the solution page matching your type of problem; and only afterwards, if you need the detail, come back here.

Skipping that order means assessing a technology rather than assessing an answer to a problem, and those are two different exercises leading to different decisions.

The order that makes most sense is: interpreted backend first, because that's where you grasp what describing a domain means rather than writing it; then generated interfaces, the most visible consequence; then orchestration, which is where the interesting part sits for anyone assessing the use of AI.

The ecosystem tools — project management, microservices, configuration generation — make sense afterwards, because they answer needs that emerge once the base model is clear.

The deployment and architecture guides are useful for whoever has to answer IT's questions, which always arrive in the first ten minutes of any serious evaluation.

These pages describe what each component does and which capabilities it provides, not how to write a configuration line by line. That's deliberate: operational documentation changes with versions and is shared with those starting a project or joining the partner programme, alongside initial hands-on support.

The reason isn't to keep information closed, but that the fastest way to learn to work declaratively is to do it on a real case with someone beside you. Those who try to learn alone tend to apply traditional development habits and build configurations that work but don't stay maintainable.