Mike Hales and colleagues have been considering how to add structure to a large and lasting project that would benefit from being within a federation but should be presented as a narrative whole, even though it continues to be evolved.
Here we explore some requirements for pages organised (hierarchically?) under categories.
These pages describe several use-cases for additional structure. Neither is disallowed by wiki but neither is supported by any dedicated feature of wiki even as simple as for-purpose plugin. The closest we've come is the Graph plugin that represents local structure that can be assembled by drag-and-drop and further composed into large graphs.
# Hierarchy
Dave Winer and I met for several days with Allen Wirfs-Brock as our host. Allen had noticed the similarities in how we favored simple servers with most editing and rendering done in the client. we found that we agreed on most points except the structure of the page. We agreed that we would both read each other's json transport format and retain enough information that authored material could flow back and forth without loss.
It was important that he remember and even assign new IDs to paragraphs. It was important that I remember the outline structure of his pages and make changes in this context. In a coding session on our last day together I created a spike of an Outline plugin:
# Structure
We've added PageFold specifically to provide machine consistency to pages to be read by programs. They are used this way occasionally but more often just as an alternative format for headings. Data has found a more accommodating environment Assets folders where contents is usually assumed to be too large to fork with the pages that host them.
The Categories in Wiki pages go on to describe structure within and between pages in a pattern language and laments that recent patters imitate the look but not so much the deep analysis represented in this structure.
For example, the Pattern Language of Programming authors were quick to adopt Alexander's form which they treated as survey questions to be answered one after another. The result remained superficial and repetitive. I discouraged this style in the first wiki and have followed that tradition here.
Mike Caulfield set out the guide writing assignments in a structure guided by a template. Read the fine print in each Factory plugin to understand what he intended of authors.
Michael Mehaffy's npl.wiki was authored with a four level hierarchy where the leafs were sufficiently similar to Alexander's form to fit in as an extension. The lack of direct support for this led us to make some decisions that make forking and viewing this content problematic once one is away from the one site. The second level pattern structure was read out of stylistic conventions regarding ellipsis, a practice we should continue.
See Street Patterns 
# Related
Whenever we dig deep into any subject we often recall pages that relate in direct or obscure ways. We list some here without comment.
The authors propose that the cause of a number of unexpected difficulties in human-computer interaction lies in users’ unwillingness or inability to make structure, content, or procedures explicit.
We describe how one might organize hypertext content to print linear documents that make most of the hypertext content accessible. We follow conventions and terminology used in the Dayton Experiment and follow on DIG Handbooks.
We author a skeleton wiki site following the IMRAD conventions (Introduction, Methods, Results, and Discussion) to test the compatibility of the two organizations as they exist today.
We contribute to the discussion of the algorithmic structure of natural environments and provide statistical and computational arguments for the intuitive claim that living systems would not be able to survive in completely unpredictable environments