# PFES-ENG-014 — Firmware Capabilities

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

## Purpose

Describe meaningful functions provided by firmware independently of their internal implementation.

## Engineering Problem

Firmware contains many instructions but exposes a smaller set of engineering capabilities: media support, authentication, vendor commands, diagnostics, update behavior, and platform-specific functions.

## Historical Engineering Evolution

Project work increasingly moved from locating code to asking which capabilities exist, what they depend on, and whether they can be reproduced or transferred.

## Engineering Discoveries

- Capabilities emerge from interacting subsystems.
- Capabilities are engineered, then transferred.

## Architectural Decisions

- Validate capabilities behaviorally.
- Model dependencies explicitly.
- Keep capability donor firmware and capability recipient firmware terminology precise.

## Knowledge Produced

- Capability inventories
- Dependency models
- Compatibility requirements

## Knowledge Consumed

- Behavior
- Services
- Resources
- Validation

## Current Engineering State

Current primary capability donor firmware is GDR-8050L. Current research studies capability recipient firmware among compatible HLDS MN103S families.

## Engineering Lessons

- Capability is a more stable abstraction than function address.
- A capability may be native, cross-flash-provided, or transplanted.

## Negative Knowledge

Project Frankenstein no longer assumes:

- A capability maps to one function.
- Similar model names imply equal capabilities.

## Current Implementations

- Stage 6 profiles
- Recipient comparison
- Emulator and hardware tests

## Future Implementations

- Capability schemas
- Automated dependency closure
- Additional donor firmware families

## Open Questions

To be expanded during engineering review.

## Why This Chapter Exists

Capabilities connect engineering understanding to practical outcomes.
