7.1 General Naming Principles

Go To Top

Return to Naming and File Conventions

The team should name Artifacts so that their purpose is clear without requiring private knowledge from the original author. A name should help a developer or reviewer understand what the Artifact represents, where it belongs, and how it relates to the Phase 0 Baseline.

Names should support the following principles:

1. Use meaningful names rather than abbreviations known only to one developer.
2. Prefer stable architectural or implementation concepts over temporary local labels.
3. Use consistent spelling, capitalisation, separators, and suffixes.
4. Avoid names that depend on a developer’s machine, username, local path, or personal workflow.
5. Distinguish source definitions from generated Artifacts.
6. Distinguish Control Plane Artifacts from Data Plane Artifacts.
7. Distinguish reusable support code from Node-specific code.
8. Distinguish Baseline Configuration from local developer overrides.

The team should avoid clever names, informal jokes, and unexplained shorthand in Repository Artifacts. Names should make the implementation easier to review, reproduce, and explain.