# PFES-ENG-026 — Media Preservation

**Status:** Active  
**Knowledge Cycle Stages:** Preserve

## Purpose

Retain engineering-quality media packages and the context required to use them in future research.

## Engineering Problem

A disc image without provenance, sidecars, authentication resources, and validation history may be insufficient for later engineering.

## Historical Engineering Evolution

Preservation evolved from retaining ISOs to retaining complete engineering packages.

## Engineering Discoveries

- Metadata may equal the primary image in engineering value.
- Preservation should support questions not yet asked.

## Architectural Decisions

- Preserve source media when practical.
- Preserve package integrity and provenance.
- Do not confuse archival use with engineering completeness.

## Knowledge Produced

- Long-term media packages
- Integrity records
- Historical context

## Knowledge Consumed

- Acquisition
- Representation
- Validation
- Artifact management

## Current Engineering State

Current packages may include image, `.xdvd.json` / `.media.json`, AD/PFI/DMI, logs, hashes, validation records, and provenance.

## Engineering Lessons

- Engineering artifacts are preserved because they are instruments, not collectibles.

## Negative Knowledge

Project Frankenstein no longer assumes:

- A single image file is sufficient forever.
- Validation metadata can be reconstructed later.

## Current Implementations

- Structured dump directories
- Sidecar workflows
- Results archives

## Future Implementations

- Formal media package standard
- Integrity auditing

## Open Questions

To be expanded during engineering review.

## Why This Chapter Exists

Future firmware and emulator work depends on trustworthy historical media inputs.

## Synthetic Reconstruction Disclosure

A reconstructed image may be structurally useful before every region can be physically captured. Such an image must state exactly which ranges are synthetic.

The current XGD1 workflow records:

- `filler_policy: zero_fill_until_drive_can_read_filler`
- `filler_verified_from_disc: false`
- `pending_hardware_capture: true`
- each synthetic range with source `synthetic_zero_fill`

This prevents a structurally useful image from being misrepresented as a complete physical capture. Redump hash mismatch is expected until filler, protection, and security-sector content is exact.

## CCI Preservation Boundary

CCI is expected to be a distribution and runtime representation rather than the sole archival master.

Because the proposed workflow includes a scrubbing pass before compression, preservation records should retain:

- the original reference-image identity and hashes;
- the scrubbed-image identity and hashes;
- the CCI-container identity and hashes;
- the exact Repackinator build and settings;
- the verified decompression result;
- a statement identifying which source regions were altered by scrubbing.

Until the format and scrub policy are fully verified, CCI files should be retained alongside—not instead of—their source image and validation records.

