# PFES-003 — Source Authority

## Evidence Authority

When sources conflict, use the following default order:

1. repeatable physical-hardware observation;
2. exact firmware bytes and verified execution behavior;
3. reverse engineering tied to addresses, bytes, or command transcripts;
4. emulator behavior validated against physical hardware;
5. analyzer findings;
6. source code and generated implementation artifacts;
7. engineering decisions and interpretations;
8. historical summaries, HTML references, and unsupported claims.

Authority is contextual. A source must actually address the claim being made.

## PFES Snapshot Authority

Until Git is established:

1. the latest complete PFES snapshot generated and delivered by the project
   steward is the canonical PFES baseline;
2. an extracted copy is a working or reference copy;
3. a working copy becomes authoritative only when deliberate changes are
   incorporated into a newer complete PFES snapshot;
4. summary-only and delta-only archives do not replace the complete baseline;
5. every newer snapshot must be based on the immediately preceding canonical
   snapshot unless an explicit reconstruction or correction is documented.

## Current-State Authority

For current operational status:

1. `PFES_CURRENT_STATE.json`;
2. `HANDOFF.md`;
3. `NEXT_WORK_PLAN.md`;
4. Appendix D and Appendix F;
5. migration reports and changelog for history.

When current-state documents disagree, correct them in one consolidation pass
rather than choosing silently.

## Historical Sources

Historical reports and HTML files are clues, not automatic truth. Migrate
claims individually with provenance and a claim status.
