8.1 Purpose of Generated Artifacts [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 8.1 Purpose of Generated Artifacts ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:08-generated-artifacts:start | Return to Generated Artifacts ]]

Generated [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] give the Phase 0 [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] a repeatable path from source definitions to implementation files. The team uses generation to reduce manual duplication, maintain consistency, and preserve [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceability]] between [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]] definitions, [[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] types, language bindings, [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] fragments, documentation, and runtime support files.

Generated Artifacts should support repeatability. A developer should be able to start from the controlled [[dido:99_annexes:annex-b-terms-and-definitions:r:repository|Repository]] inputs, run the approved generation command or script, and produce the same expected outputs.

Generated Artifacts should also support review. Reviewers should be able to identify what generated the Artifact, which source definition it came from, where the generation process wrote it, whether Git tracks it, and whether developers may edit it.

The team should use generated Artifacts to project governed definitions into implementation form. The team should not use generated Artifacts as a substitute for architectural source definitions, IDL source files, topic catalogues, node catalogues, or reviewed Configuration.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>