3.6 Baseline Change Control

Go To Top

Return to Phase 0 Baseline

The team should treat the Phase 0 Baseline as controlled, not frozen. The Baseline may change as the team learns, but changes should occur deliberately and visibly.

A Baseline change may affect Repository structure, required tools, generated Artifacts, Node patterns, DDS/IDL definitions, topic names, scripts, containers, logging conventions, Exception Handling, Acceptance Criteria, or demonstration scope. When a change affects shared implementation practice, the team should update the handbook or the relevant Repository documentation.

Developers should not make Baseline changes as incidental side effects of local coding work. A change that alters shared conventions should receive review before the team treats it as part of the Baseline. The review should consider Traceability, Reproducibility, Compatibility, documentation, and impact on other team members.

The team should record open decisions and unresolved risks in the Risks and Open Decisions section. Once the team resolves an issue, it should update the relevant handbook section and, where appropriate, tag or otherwise identify the updated Baseline in Git.

Baseline control gives the Phase 0 work its credibility. The team can improve the implementation as it learns. Still, it should always know which Version of the Repository, tools, scripts, generated Artifacts, Nodes, and Acceptance Criteria defines the current Phase 0 Baseline.