The main goal of HyperDoc is to support the creation of explainable and explorable convivial software systems from composable units. See here for a more detailed discussion of goals and values.
One source of inspiration is Bret Victor's "Explorable Explanations" (read in particular the "Postscript from 2024" at the end). HyperDoc wants to enable explorable explanations, but emphasizes the context of peer-to-peer communication, as in scientific research or among collaborators, over the context of expert-to-non-expert communication. This leads to a focus on conviviality that is absent from Bret Victor's work.
Another source of inspiration is literate programming. Its goal is to make software source code more readable for humans, by embedding it into a narrative. In my opinion, experience has shown that this doesn't work very well except for small software. One reason is that understanding complex software system requires exploration rather than passive reading. Another reason is the linear structure of a narrative, which is not adapted to complex software, and often in conflict with the formal requirements of a programming language. This is why literate programming tools usually have to re-structure the code before compilation. HyperDoc shows you the code exactly as the compiler sees it.
A third source of inspiration are notebook interfaces, which are similar to literate programming but embed a computation rather than a program into the narrative. This makes it possible to include computed results as well. Notebook interfaces are an evolution of the read–eval–print loop, and thus primarily a tool for performing explorative computations. They have recently been advocated as a medium for publishing explorable computations as well, but fail in this role by their restriction to a single linear narrative and computation. Notebooks are not composable. HyperDocs are.
HyperDoc uses hypertext, i.e. sets of interlinked pages, to represent explorable software systems. There are code pages, which are valid source code files according to the rules of the underlying programming language, and text pages, which are narratives. Moreover, both code and text pages can contain links to arbitrary data objects, and thus in particular results of example code. Code and results can also be transcluded into text pages. More generally, all links in HyperDoc refer to plain data objects. This means that you can implement your own HyperDoc page types, or even your own HyperDoc-like documentation system, and cross-link seamlessly.
An additional advantage resulting from an architecture based on plain data objects is the possibility to use different tools for exploring HyperDocs. Right now, you are using an in-browser object inspector that presents objects in lineups of panes. But other object inspectors using HTML-based views are imaginable. For example an inspector presenting objects in boxes placed on an infinite canvas, which users can arrange as they see fit.
Examples are another key ingredient of HyperDoc, although their implementation remains basic for now. Examples produce inspectable results, which permit explorers to better understand the software system. But examples can also contain assertions, taking the role of traditional unit tests. A testing framework that automatically runs all examples in a HyperDoc remains to be implemented. See this paper on example-driven development to learn more about this approach.