====== 8.4 Python-Generated Support Artifacts ====== [[fxdemo:05-part:start | Go To Top ]] [[fxdemo:05-part:08-generated-artifacts:start | Return to Generated Artifacts ]] Python may generate support [[dido:99_annexes:annex-b-terms-and-definitions:a:artifact|Artifacts]] for Phase 0 to improve repeatability or reduce manual errors. These Artifacts may include derived [[dido:99_annexes:annex-b-terms-and-definitions:c:configuration|Configuration]] files, validation reports, topic catalogue extracts, [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Node]] catalogue extracts, documentation fragments, fixture data, or test inputs. The team should treat Python-generated support Artifacts as derived outputs. The Python script, input files, and generation command should define how to recreate them. Developers should not hand-edit Python-generated outputs unless the team intentionally converts the output into a governed handwritten Artifact. Python-generated support Artifacts should reside in approved generated directories or in clearly documented output locations. The generation process should avoid overwriting handwritten files, local developer files, or reviewed [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] Configuration. Python support generation should remain a developer-automation mechanism. It should not hide architectural decisions inside scripts. If a Python script encodes a naming convention, topic mapping, Node list, Configuration rule, or validation rule, the team should document that rule in the handbook, catalogue, or relevant source definition. ---- © 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.