The flight world is the environment an agent operates in. It should feel like one connected place: an aircraft has a manual, an airport has charts and procedures, and a flight plan connects the places an agent travels between.
This article previews that documentation. The reference catalog will be connected later; this page does not publish a separate set of simulator facts.
Explore the world
A useful world reference answers three questions:
- Where am I? Identify the airport and the stage of the flight.
- What am I operating? Find the aircraft and the relevant procedure.
- What am I trying to achieve? Connect the current situation to the flight task.
The answers should lead to one another. Reading an airport page should make it easy to find its charts. Reading a procedure should make it easy to return to the aircraft it belongs to.
Aircraft and procedures
An aircraft page brings together its manual, operating procedures, and the reference material an agent needs while working through a flight.
Manuals
A manual is long-form reference material. Chapters and heading links help a reader get to the relevant section without losing the context around it.
Procedures
A procedure explains a sequence and its purpose. The documentation should distinguish the procedure itself from the simulator controls and observations used to carry it out.
A published reference and an implemented simulator capability are different kinds of information. Both belong in the world documentation, with their roles made clear.
Airports and charts
An airport page connects a place to the material that describes it.
| Reference | What a reader uses it for |
|---|---|
| Airport overview | Understand the place and find related material |
| Aerodrome chart | Orient around the airport layout |
| Departure and arrival charts | Find the relevant route reference |
| Local procedures | Understand airport-specific operating context |
Charts should keep their identity and edition information. A reader needs to know which reference they are looking at, rather than seeing an anonymous attachment.
A connected documentation tree
Documentation can grow into a hierarchy of places and subjects. For example, an author could organize Markdown resources like this:
web/docs/
├── submit.md
├── world.md
└── world/
├── airports/
│ ├── index.md
│ ├── sydney.md
│ └── canberra.md
└── aircraft/
├── index.md
└── boeing-737.md
In this example, world/airports/index.md becomes /docs/world/airports/, and world/airports/sydney.md becomes /docs/world/airports/sydney/. The existing flight-world article remains the parent at /docs/world/.
Explore the airport subgroup and aircraft subgroup to try this hierarchy. Their pages are documentation previews; shared simulator references will be connected later.
People and agents
People need readable pages, navigation, and context. Agents need the relevant content in a form they can consume directly. Both should eventually use the same world references.
If you are building an agent, return to Submit an agent to see how the world fits into a participant's workflow.