# Evidence, Trust, and Verification

## Legacy provenance backfill

`/memory-evidence migrate-legacy --json` previews deterministic structured evidence for resolvable legacy file/daily references. Missing references remain findings and secret-bearing sources are blocked. Apply requires `--apply --fingerprint <reviewed-sha256>`, creates byte-preserving backups and an audit report, retains original inline references, adds structured IDs, and never raises memory confidence.

PI treats memory candidates as claims that need to be evaluated before becoming durable beliefs. This evaluation happens through a structured evidence record and a deterministic verifier.

---

## Evidence records

Every candidate entering the inbox is backed by at least one evidence record stored in `memory/evidence.jsonl`. Evidence records carry:

- `trust_class`: the authority of the source
- `durability_signal`: how long this evidence justifies the claim
- `polarity`: whether the evidence supports, contradicts, or qualifies the claim
- `source_summary`: a short description of what the evidence says
- `source_excerpt`: a bounded excerpt (max 1000 characters) from the source
- `redaction_status`: `none`, `redacted`, or `deleted`

Evidence IDs are content-addressed: the same source excerpt from the same profile and session always produces the same ID. This prevents duplicate evidence from accumulating.

---

## Trust classes

Trust class determines how authoritative the source is and whether the candidate can auto-apply.

| Trust class | Weight | Can auto-apply? |
|---|---:|---|
| `direct_user_instruction` | 1.0 | Yes, if durable and verified |
| `user_correction` | 1.0 | Yes, if durable and verified |
| `repeated_user_preference` | 0.9 | Yes, with corroboration |
| `accepted_code_review_outcome` | 0.8 | Review preferred |
| `existing_project_convention` | 0.65 | Review preferred |
| `passing_tool_or_test_outcome` | 0.55 | Review only |
| `agent_inference` | 0.35 | Review only |
| `single_session_observation` | 0.3 | Review only |
| `repository_text` | 0.25 | Review only |
| `generated_content` | 0.2 | Review only |
| `third_party_documentation` | 0.2 | Never auto-applies |

`repository_text`, `generated_content`, and `third_party_documentation` are marked as high poisoning risk and cannot auto-apply under any governance mode. They always require human review.

---

## Durability signals

Durability signals indicate how long the claim is expected to remain valid.

| Signal | Meaning |
|---|---|
| `temporary` | Short-lived; cannot auto-promote to durable L2 |
| `task` | Relevant only to a specific task |
| `session` | Relevant only to the current session |
| `project` | Relevant for the lifetime of this project |
| `repository` | Relevant at the repository level |
| `user_global` | User-wide preference across all projects |
| `long_term` | Intended as a long-term durable belief |
| `unknown` | Not classified; routes to review |

Candidates with `temporary`, `task`, or `session` durability cannot auto-promote to durable L2 memory without explicit human conversion.

---

## Promotion eligibility

A candidate's promotion eligibility is derived from its trust class, durability signal, and proposed layer.

| Eligibility | Meaning |
|---|---|
| `auto_candidate` | Meets trust and durability thresholds; eligible for auto-apply in eligible governance mode |
| `review_only` | Must go through human review |
| `never` | Never promotes |
| `l1_review_only` | L1 proposal; always requires explicit ratification |

---

## Poisoning risk

Poisoning risk is inferred from the trust class and durability:

| Poisoning risk | Triggers |
|---|---|
| `high` | `repository_text`, `generated_content`, `third_party_documentation` |
| `medium` | `agent_inference`, `single_session_observation`; or non-durable durability |
| `low` | High-trust sources with durable signals |

High poisoning risk candidates are never auto-applied and are never default-selected in the patch review.

---

## The deterministic verifier

Before a candidate enters the patch pipeline, the verifier runs a series of deterministic checks:

1. **Source support**: does the evidence actually back the claim? Token overlap between the candidate statement and evidence summaries must meet a threshold.

2. **Trust boundary**: is the trust class eligible for the proposed scope and layer?

3. **Durability support**: is the durability signal compatible with durable L2 promotion?

4. **Poisoning risk**: is the evidence from a low-trust or generated source?

5. **Conflict check**: does this candidate have a match kind that requires review? (`potential_conflict`, `supersedes_existing`, `ambiguous`)

6. **Redacted or deleted evidence**: is any linked evidence record redacted or deleted? If so, it cannot support durable promotion.

7. **Tombstone check**: does this candidate target a memory ID that has been tombstoned? If so, it is rejected.

Verification outcomes:

| Status | Meaning |
|---|---|
| `legacy_unverified` | No trust metadata; compatibility mode treats as auto-eligible |
| `verified` | All checks pass; eligible for auto-apply depending on governance mode |
| `review_required` | One or more checks flag the candidate; must go through human review |
| `rejected` | Candidate is blocked from promotion (tombstone re-creation, redacted evidence, etc.) |

---

## Candidate matching

Before verification, each candidate is matched against existing active records using normalized memory keys. Match kinds:

| Match kind | Meaning | Auto-apply? |
|---|---|---|
| `new` | No existing record with this key | Yes, if verification passes |
| `duplicate` | Nearly identical statement; same key | Yes, if verification passes |
| `strengthens_existing` | Similar statement; same key | Yes, if verification passes |
| `updates_existing` | Update cue; same key | Yes, if verification passes |
| `potential_conflict` | Contradiction cue; same key | No; routes to review |
| `supersedes_existing` | Explicit supersession; same key | No; routes to review |
| `ambiguous` | Multiple active records share the key | No; routes to review |

Conflict, supersession, and ambiguous matches create open inquiry records to track the unresolved question.
