# PFES-ENG-040 — Artifact Management

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

## Purpose

Manage artifact identity, provenance, representations, retention, regeneration,
archival, verification, and deletion.

## Artifact identity

A Project Frankenstein artifact receives a stable `PFART-0000000` identifier.
The Artifact ID names the logical engineering object. SHA-256 identifies one
specific byte representation. A transformed TSOP image, decoded plaintext image,
and update-container payload may be related representations of one engineering
subject without being byte-identical.

Provenance-distinct instances remain separate catalog records even when hashes
match. Matching bytes never justify collapsing update-utility provenance,
hardware-dump provenance, patched-versus-stock identity, or ranking rows.

## Storage classes

- A0 — irreplaceable original evidence;
- A1 — canonical large artifacts and releases;
- A2 — expensive but reproducible evidence;
- A3 — cheap reproducible output;
- A4 — quarantine pending classification.

Deletion requires a retention decision, verified regeneration or replacement,
and no loss of unique provenance. Phase 0 enables no automatic physical
deduplication.

## Repository boundary

Git stores evolving source, text, schemas, tests, and selected small evidence.
Disc images, full analyzer trees, large result archives, and routine traces use
the external artifact store and catalog. Git LFS is selective, not the archive.

## Single-disk interim rule

The present server copy is not a backup. A0/A1 source originals must remain on
their source system or another device until a second verified physical copy
exists. Same-disk Git bundles protect against some logical errors only.

## Output integrity

Acquisition tools must validate expected size, every write, flush/commit/close,
final byte count, and post-close hashes. A full or unavailable destination must
fail with source/output context rather than produce an apparently successful
truncated artifact.
