It is modular
Generally speaking, the goal of the document is to communicate the game design to all the parties involved in game development. But it's very unlikely that the whole design is going to be covered by a single document. Some parts of the game might need to be designed as soon as possible, while others might wait for a later stage or even need to be designed after some of the features have been implemented.
A development team can reach over 200 people in AAA productions and many people will have a very specific role. Imagine if a programmer in charge of developing the multiplayer network was forced to read a 1,000-page document to understand what they needs. They will get information about levels, characters, storyline, or the balancing of the combat system… all stuff they doesn't need to understand to actually jump on what they needs to know.
Ideally, there would be a chapter just for him called Multiplayer. Even better, there would be an entirely separate document called Multiplayer. If this, let's say, 50-page document contains all the information the programmer needs, with fewer possible dependencies on other features or documents, we can call it a GDD in itself or a module.
A game document should always be modular.
What does modular mean? Let's get more technical and look at how modularity is defined for software development by Wikipedia:
Just like modular software, a modular GDD should be composed of different modules as independent and interchangeable as possible. Remember that video games are software and as such they can (and should) make good use of software development techniques at every level, not only for coding. Unlike software, though, it's very unlikely that a video game is going to be made of parts fully independent of each other. Removing one part of the game, or changing its design, will have an impact on the others, and without one part, the entire game might fall apart and not work as intended any more. However, that is exactly why you need to keep the GDD organized in modules. If something needed to change, you'd need the confidence of knowing which part to rework and exactly how and where it is referenced elsewhere in your documentation.
Here's a very simple example: you have designed a combat system in an action game. Following the practice of modularity, you have created a separate document called Combat System, just for that feature, where all the details are meticulously designed. In other modules of the GDD, every time you have to reference a particular mechanic in the combat system, you simply point at the specific document on that topic. Let's say at some point during production, something in the combat system must change drastically. If your references to the combat system document are very few and always in a form like see combat system document for details, all you'd have to do is make the required changes in that module only, and all the references will remain relevant.
As we discussed, GDD is by definition a live document, so it will need constant updates and changes, and sometimes entire parts may be cut out or added. Modularity ensures that taking out or changing a module doesn't mean going back and updating the entire documentation. Most importantly, it guarantees that a change in one feature doesn't impact the rest of the game, or if it does it gives control over where the dependencies are. Modularity ensures another important concept inherited from software development: reusability. A modular GDD is reusable because every single module can be used for different projects (if conveniently adapted). Writing a modular GDD means for you, the game designer, creating a library of designs for a variety of game features and mechanics that is easy to consult, examine, and improve throughout your entire career.