# PFES-TR-006 — Analyzer Pipeline and Evidence Contract

**PFES revision:** 0.13.0  
**Status:** Canonical current analyzer contract

## Purpose

The HLDS analyzer is a staged evidence system. Each stage narrows uncertainty
without silently acquiring authority that belongs to a later stage or to
hardware validation.

## Stage Chain

`Stage1 → Stage2 → Stage3 → Stage4 → Stage5A → Stage5B → report/profile synthesis`

The machine-readable contracts are in
`Migration/Analyzer_Knowledge/ANALYZER_STAGE_CONTRACTS.json`.

## Authority Boundaries

- Extraction proves that bytes were recovered from a named source.
- Normalization proves a declared container or role interpretation.
- Routing records a decision and its evidence; it is not decryption proof.
- Transform recovery proves a specific representation relationship only when
  round-trip or matched-reference validation succeeds.
- Disassembly proves decoding at a declared VMA, not function semantics.
- Stage5B emits candidate evidence, not a verified device profile.
- Scores and rankings are planning aids, never hardware validation.

## Indirect Command Resolution

A command handler may be reached through a literal compare, byte table,
handler-pointer table, computed branch, predecoded command variable, shared
state machine, or cross-family equivalent path. The analyzer must preserve
these as distinct evidence classes. A missing literal `cmp 0xAD` cannot be
reported as absence of READ DVD STRUCTURE.

## Expensive-Run Discipline

A full Stage5B run exceeds 100 minutes on the primary machine. Before a full
rerun:

1. compile changed scripts;
2. validate schemas and report helpers locally;
3. run a small indexed/model smoke test;
4. inspect version and output-path logging;
5. rerun the full analyzer only when the evidence-producing semantics changed;
6. archive the result set.

Formatting-only or ranking-table changes do not justify a Stage5B rerun.

## Provenance-Distinct Retention

Byte hashes, source instances, model/revision identity, extraction method,
container role, transform path, hardware acquisition method, and patch state
are all part of the artifact identity. GCC-4244N B103 utility-derived and
HITMEM-derived records remain separate. GDR-8164B 0L06 stock and E7-patched
records remain separate.

## Source Lineage

The source snapshots inside this PFES revision are directly supplied audit
snapshots. They compile under Python 3.13, but later live-workspace producer
lineages exist for Stage3, Stage4 and Stage5B. Stable canonical filenames are
the interface; the producer string and source hash identify the implementation.
