Module History
A module’s history explains how it was created and changed: from scratch, as a copy, by merging modules, or after reviewing a project’s results.
History Types
Section titled “History Types”| Type | Meaning |
|---|---|
| ORIGINAL | First creation |
| CLONED | Copied from a source module |
| MERGED | Created by merging multiple source modules |
| AI_SUGGESTED | Created by an AI-assisted workflow |
| LEARNING_APPLIED | Module change made in response to a resolved variance finding |
Records labeled REVISION belong to estimate history, not module history. Learning applied records a change to an existing module and stays outside the ancestry tree showing which modules it was copied or merged from.
Display Codes
Section titled “Display Codes”Use these display codes to identify a module, estimate, or project when discussing work with your team:
| Entity | Code Prefix | Example |
|---|---|---|
| Module | MOD |
MOD-0042 |
| Estimation | EST |
EST-2026-0042 |
| Project | PRJ |
PRJ-2026-0017 |
Some codes include the year. Include the full code when referring to a record so your team can find the right one.
Why It Matters
Section titled “Why It Matters”If modules are the expression of Cost DNA, teams need to understand whether a module is original, cloned from another module, or merged from multiple sources. This history preserves trust, traceability, learning over time, and accountability for module evolution.
Learning Applied
Section titled “Learning Applied”When your team records a module update as the outcome of a variance finding, its history links the change to that finding. The person responsible must make and review the recipe change; resolving the finding does not edit it for them. See Record a Cost and Review a Variance.