Module Development Guidance
Awaiting source text
This section exists in the source handbook as a heading with six empty sub-headings beneath it. None has any text. Nothing has been written here in its place.
The six are: What makes a module a module, Minimum required elements of a module, How to create a module using available tools and models, Input and output schema expectations, Interoperability and dependency principles, and Guidance for extending the DSP with additional modules.
Why this section matters
This is the section that would let an organisation add to the DSP rather than only use it. Given that the handbook presents modules as usable standalone and the framework as extensible, its absence is a real gap rather than a cosmetic one.
What is known so far
Three pieces of the answer exist elsewhere in the handbook and can be read now.
What makes a module a module
Definition of a module gives the three requirements: a module is a set of interconnected tools, models or methods with specific objectives, specific inputs and outputs, and clearly defined information flows across the DSP.
Input and output schema expectations
There is no generic schema in the source. There are, however, concrete output schemas for each of the technical processes, which show the form the generic one would have to take. See Input & Output.
Interoperability and dependency principles
Every documented module carries its own Dependencies on other modules and processes section, and those sections together describe the interoperability pattern in practice:
| Module | Its dependencies |
|---|---|
| Asset Registry | Supports all six others, and receives information back from each |
| Asset Performance | Two-way with four modules |
| Resilience | Seven relationships, including one explicit non-dependency |
| Risk Assessment | Eight upstream dependencies |
A useful worked pattern to follow is the Asset Registry and Asset Performance pair. One generates information and does not store it; the other stores it and does not generate it. The boundary between them is stated in both directions, which is exactly what a new module would need to do.
What this page should cover
A specification a third party could build against: the minimum elements a module must have, the schema its inputs and outputs must satisfy, the dependency declarations it must make, and the process for proposing an addition to the DSP.