DB Design updated with memory tables

Think of the 3 tables as a memory lifecycle:

WorkflowMemory  = the memory card
MemoryHit       = proof that a memory was retrieved for a future claim
MemoryUpdate    = proof that the memory changed after future outcomes

Your Week 5 plan defines exactly this: WorkflowMemory = what ClaimFlow remembers, MemoryHit = when memory was retrieved, and MemoryUpdate = how future outcomes changed that memory.

1. WorkflowMemory — what ClaimFlow remembers

This is the main table.

It stores one reusable memory card, like:

Reviewer corrected policyNumber for claimant CUST-002.
Safe use: ask reviewer to verify policy number.
Must not do: overwrite extractedJson or treat old correction as truth.

Your existing repo already has ReviewDecision.correctedJson, correctedValidationJson, reviewer notes, and reviewer name. That means Week 5 can turn a human review outcome into a memory card.

Why each field exists

Identity and type

id String @id @default(cuid())
kind WorkflowMemoryKind
status WorkflowMemoryStatus @default(ACTIVE)

Why needed:

• id: unique memory ID.
• kind: tells what type of memory this is.
• status: tells whether this memory should still be used.

Example kinds:

HUMAN_CORRECTION
PRIOR_REJECTION
CLAIMANT_PATTERN
VENDOR_PATTERN
RECURRING_ERROR_PATTERN