Hey Gavin,
The general best practice would be to create the documentation for each module within it's Sources/ directory - so in this case:
Sources/MatrixModule/Documentation.doccSources/Numerical/Documentation.doccSources/VectorModule/Documentation.docc
And within each of them, add the curation file (that top-level markdown file that provides an overview of the module and organizes the types into some meaningful setup.
In the .spi.yml file, you'll want to list each of those as documentation targets, something like:
version: 1
builder:
configs:
- documentation_targets: [MatrixModule, Numerical, VectorModule]
That should get the relevant bits splashed up at SwiftPackageIndex for the hosting.
The capability for "I want all three of these combined into a single set of documentation" is still very much in the experimental phase, and generally the pattern that's expected/intended is that you'd pick one as "the top", and provide links and references to others (expected to be sort of "child nodes" if you will) from there. I'm not, however, sure if that experimental mode - the extra arguments and such - is set up to work with Swift Package Index and it's hosting.
You can read up on the expected use cases of that new mode at Use cases for combined documentation of multiple targets in Swift-DocC, with a more recent preview of what's available in those experimental features at A preview of DocC's support for combined documentation
/cc @ronnqvist (in case I really fouled up specifics in my brief explanation of the state of that evolving feature)