Evidence Naming & Folder Convention
Use stable names so a later chapter or capstone can cite earlier proof without guessing what a file means.
Suggested repository structure
evidence/
├── chapter-01/
│ ├── README.md
│ ├── CH01-A-data-asset-inventory.md
│ ├── CH01-B-value-risk-assessment.md
│ ├── CH01-C-lifecycle-management-map.md
│ ├── CH01-D-requirements-before-technology.md
│ ├── CH01-E-charter-scope-roadmap.md
│ ├── CH01-F-knowledge-area-map-debrief.md
│ └── CH01-G-acquisition-change-fact-revision.md
├── chapter-02/
├── ...
├── capstones/
└── portfolio/
Naming rules
- Begin chapter evidence with
CH##-<letter>when the lab defines a stable evidence ID. - Use short descriptive lowercase file names after the ID.
- Keep SQL/Python source in
/lab; evidence may link to the exact source file/commit rather than duplicating code. - Use
DEC-###for material governance/architecture/business decisions when a stable decision record is useful. - Preserve stable defect IDs such as
DQ-001,SEC-001,MDM-001, etc. - Keep large screenshots, Google-native artifacts, and formatted PDFs in Drive when that is the better format; link them from the GitHub evidence README.
Every evidence folder needs a README
The README should state:
- chapter/lab/sequence;
- business problem;
- controlling DMBOK source;
- evidence files/links;
- key decision or finding;
- independent rebuild result;
- real mistakes/repair items;
- tracker link/status.
The goal is that future-you can understand the evidence package without reopening the entire lab guide.