2.6 Relationship to Generated Code and Runtime Artefacts [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.
====== 2.6 Relationship to Generated Code and Runtime Artefacts ======

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

[[fxdemo:05-part:02-relationship-to-the-architecture-documents:start | Return to Relationship to the Architecture Documents ]]

Generated code and runtime [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] project the architecture into implementation form. They do not become the architecture itself. The team should treat [[dido:99_annexes:annex-b-terms-and-definitions:i:idl|IDL]]-derived files, generated language bindings, [[dido:99_annexes:annex-b-terms-and-definitions:c:container_image|Container Images]], logs, [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] files, and runtime outputs as Artifacts produced from [[dido:99_annexes:annex-b-terms-and-definitions:g:governed|Governed]] source material and repeatable processes.

This handbook defines how the team separates generated Artifacts from handwritten source files. Generation processes should produce reproducible, identifiable, and [[dido:99_annexes:annex-b-terms-and-definitions:t:traceability|Traceable]] Artifacts. They should not overwrite handwritten source files. Runtime Artifacts, such as logs and container outputs, should provide [[dido:99_annexes:annex-b-terms-and-definitions:e:evidence|Evidence]] of execution. They should not define architectural meaning.

This distinction protects the architectural discipline. The Phase 0 [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] should show that the team can generate, build, run, observe, and review implementation Artifacts without allowing generated code or runtime convenience to become the source of architectural truth.

----

<WRAP centeralign>

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

</WRAP>