Pattern and Decision Lifecycle Alignment
Description
Pattern maturity and decision lifecycle are distinct but must be interpreted consistently.
- Pattern maturity reflects knowledge evolution (heuristic → pattern → stable)
- Decision status reflects governance lifecycle (proposed → accepted → rejected → deferred)
These dimensions must not be conflated.
Rules
- Must follow knowledge/global/rules/rule-decision-status-drives-stage
Mapping Guidance (Interpretation Only)
| Pattern Maturity | Decision Status | Effective Interpretation |
|---|---|---|
| exploring | none | candidate (pre-ADR) |
| exploring | proposed | validating (NEXT) |
| stable | accepted | active (DONE) |
| any | rejected | discarded |
Rationale
Separating knowledge evolution from governance validation prevents:
- premature promotion of patterns
- inconsistent AEM state
- ambiguity between "observed" vs "approved" architecture
Applies To
- patterns
- architecture_evolution_map
- architecture_intent_document
Example
A pattern with maturity "exploring" and decision.status "proposed" is interpreted as a candidate under validation, not an active part of the system. It appears in AEM as NEXT, not DONE, until governance approval is obtained.
Consequences
Benefits:
- consistent lifecycle interpretation across CAS
- reliable AEM stage assignment
- clearer governance traceability
Risks if not followed:
- patterns marked DONE without validation
- drift between ADR and AEM
- confusion in system state