====== 8.5 Generated Documentation ====== [[fxdemo:05-part:start | Go To Top ]] [[fxdemo:05-part:08-generated-artifacts:start | Return to Generated Artifacts ]] Generated documentation can help the team keep [[dido:99_annexes:annex-b-terms-and-definitions:r:repository|Repository]] documentation aligned with source definitions. The team may generate documentation from [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] files, topic catalogs, [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] catalogs, script metadata, [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] schemas, tests, or acceptance [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]]. Generated documentation should identify its source and generation process. Readers should be able to tell whether they are reading authored guidance, generated reference material, or generated Evidence. The team should use generated documentation for reference material, not for unsupported architectural assertions. For example, generated topic documentation can list topic names, carried structures, and [[dido:99_annexes:annex-b-terms-and-definitions:q:qos|QoS]] settings, but architectural meaning should still trace back to the architecture documents, topic definitions, or catalog entries. Generated documentation should not replace handbook sections that explain team conventions. The handbook defines the rules. Generated documentation reports what the current Repository contains. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.