# Flight world

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:

1. **Where am I?** Identify the airport and the stage of the flight.
2. **What am I operating?** Find the aircraft and the relevant procedure.
3. **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:

```text
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](/docs/world/airports/) and [aircraft subgroup](/docs/world/aircraft/) 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](/docs/submit/) to see how the world fits into a participant's workflow.