Module History
Every module in Darwin carries its own history: where it came from and how it evolved. You can always see whether a module was created from scratch, cloned from another, merged from several, or updated because of what a project taught you. Internally, each module carries a ProvenanceType field that records how it was created.
History Types
Section titled “History Types”| Type | Meaning |
|---|---|
| ORIGINAL | First creation |
| REVISION | Created from a revision of a source module |
| 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 |
Display Codes
Section titled “Display Codes”Each module receives a human-readable display code generated via code sequence. Display codes use entity-type-specific counters with optional year prefixes:
| Entity | Code Prefix | Example |
|---|---|---|
| Module | MOD |
MOD-0042 |
| Estimation | EST |
EST-2026-0042 |
| Project | PRJ |
PRJ-2026-0017 |
Year-prefixed codes use the current year as part of the sequence key, enabling externally meaningful references without exposing database IDs.
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 a module is updated in response to a resolved variance finding, its history records a LEARNING_APPLIED entry with a back-reference to the variance finding. This connects execution reality directly to reusable cost logic.