Let’s take the smoke-test example:

w5-001-prior-policy-number-correction

Current new claim state:

{
  "runId": "RUN-W5-001",
  "customerId": "CUST-W5-001",
  "policyId": null,
  "vendorId": null,
  "extractedJson": {
    "claimNumber": "CLM-W5-001",
    "insuredName": "Dev Arora",
    "policyNumber": null,
    "incidentDate": "2026-05-28",
    "lossType": "own_damage"
  },
  "validationJson": {
    "isValid": false,
    "missingFields": ["policyNumber"],
    "conflicts": []
  },
  "missingFields": ["policyNumber"],
  "requiredEvidence": []
}

The expected behavior for this packet is: retrieve the prior policy-number correction memory, use it only as a verification/review hint, and do not overwrite fields, approve, or reject from memory.

Full Day 4 retrieval flow

1. Current claim enters memory retrieval

The retrieval call looks like this:

await retrieveRelevantMemories({
  claimState,
  writeHits: false,
  limit: 5,
});

For packet smoke tests, writeHits is false because RUN-W5-001 is a fixture ID, not a real database ExtractionRun.id.

For real DB runs, it would be:

await retrieveRelevantMemories({
  runId,
  writeHits: true,
  limit: 5,
});

2. Memory query is built

The first important thing is:

claim state → structured memory query

For this example, the built memory query becomes conceptually:

{
  runId: "RUN-W5-001",

  claimantId: "CUST-W5-001",
  policyId: null,
  vendorId: null,

  missingFields: ["policyNumber"],
  requiredEvidence: [],

  fieldPaths: [
    "policyNumber",
    "missingFields"
  ],

  tags: [
    "missing_field:policy_number",
    "policy_number_missing",
    "loss_type:own_damage"
  ],

  lossType: "own_damage",
  damageType: null,

  canWriteHits: false
}

This query exists because memory retrieval should not search old claims directly. It should search with stable workflow signals.