# PFES-ENG-005 — Firmware Identity

**Status:** Active  
**Knowledge Cycle Stages:** Identify

## Purpose

Establish the engineering identity of a firmware artifact.

## Engineering Problem

Model strings and version labels are insufficient. OEM variants, packaging sources, compile dates, hashes, hardware targets, and genealogy all contribute to identity.

## Historical Engineering Evolution

Identity began as model and revision. The corpus showed that the same revision can exist in different distributions and that related revisions can share deep lineage.

## Engineering Discoveries

- Hashes identify known artifacts but do not fully define engineering identity.
- Observed identity must remain separate from inferred identity.

## Architectural Decisions

- Preserve original identifiers.
- Add discovered identifiers rather than replacing originals.
- Link hashes to a canonical identity library when available.

## Knowledge Produced

- Identity records
- Compatibility identifiers
- Lookup keys
- Firmware relationships

## Knowledge Consumed

- Embedded strings
- Hashes
- Provenance
- Hardware observations

## Current Engineering State

Identity may include model, revision, OEM, build date, embedded inquiry strings, compilation information, cryptographic hashes, provenance, controller architecture, and genealogy.

## Engineering Lessons

- Identity accumulates as understanding improves.
- A hash library enables rapid recognition only for known payloads.

## Negative Knowledge

Project Frankenstein no longer assumes:

- Version strings uniquely identify payloads.
- Packaging identity equals firmware identity.

## Current Implementations

- Analyzer identity extraction
- Corpus naming conventions
- Manual hardware correlation

## Future Implementations

- Canonical hash-indexed identity library
- Automatic relationship discovery

## Open Questions

To be expanded during engineering review.

## Why This Chapter Exists

All cross-family analysis depends on knowing exactly which artifact is being discussed.
