# PFES-ENG-015 — Firmware Evolution and Genealogy

**Status:** Active  
**Knowledge Cycle Stages:** Understand

## Purpose

Describe relationships among revisions, OEM variants, families, architectures, services, and inherited capabilities.

## Engineering Problem

Engineering each revision independently wastes work and hides the history needed for compatibility analysis.

## Historical Engineering Evolution

Cross-family analyzer results revealed shared services, topology, packaging, and capability evolution across HLDS optical drives.

## Engineering Discoveries

- Engineering knowledge often transfers across related revisions.
- Version numbers alone do not describe lineage.

## Architectural Decisions

- Separate observed genealogy from inferred genealogy.
- Propagate findings only where evidence justifies it.

## Knowledge Produced

- Family trees
- Inherited service maps
- Capability evolution
- Compatibility clues

## Knowledge Consumed

- Identity
- Topology
- Services
- Provenance

## Current Engineering State

Current work focuses on HLDS families, especially MN103S-based drives from roughly the 2003–2013 era, while recognizing that not all drives in that period or brand share the same controller.

## Engineering Lessons

- Genealogy reduces repeated reverse engineering.
- Controller identity is necessary but not sufficient for compatibility.

## Negative Knowledge

Project Frankenstein no longer assumes:

- Shared CPU implies direct cross-flash compatibility.
- Model chronology alone proves lineage.

## Current Implementations

- Cross-revision comparisons
- Analyzer inventories
- Hardware board evidence

## Future Implementations

- Automated genealogy
- Capability inheritance maps
- Cross-vendor optical-drive studies

## Open Questions

To be expanded during engineering review.

## Why This Chapter Exists

Genealogy explains where knowledge can transfer and where it cannot.
