Versioning Architecture Mermaid

graph LR
 V1[Version 1] -->|Edit| V2[Version 2]
 V2 -->|Edit| V3[Version 3]
 V3 -->|Edit| VN[Version N]
 V2 --> EDIT1[Edit Record]
 V3 --> EDIT2[Edit Record]
 VN --> EDITN[Edit Record]
 EDIT1 -->|Stores| BEFORE[Before State]
 EDIT1 -->|Stores| AFTER[After State]
 EDIT1 -->|Stores| WHO[Who + Why]
 REVERT[Revert to V2] -.->|Creates| VN1[New Version = V2]
 style VN fill:#99ff99
 style REVERT fill:#ffff99

Explanation

Linear Versioning Only:

• Each edit creates a new version (V1 → V2 → V3 → ... → VN)
• No branching, no parallel versions
• Simple sequential numbering
  Edit Records:
• Every version change stored in EDIT table
• Contains: before_state (JSON), after_state (JSON), user_id, reason, timestamp
• Full audit trail preserved forever
  Revert Mechanism:
• "Revert to V2" doesn't delete V3-VN
• Instead, creates new version VN+1 with V2's content
• History never deleted, only moved forward
  What Gets Versioned:
• Claims: assertion text, domain, status, scores
• Evidence: excerpt, relevance, support type
• Scenarios: description, assumptions, confidence
  Not Versioned (current state only):
• Source track records (continuously updated)
• Quality metrics (time-series data)
• User reputation (accumulated score)
  Access:
• Current version: Default view
• Version history: Click "History" tab
• Diff between versions: Compare any two versions
• Revert: Select version → "Revert to this version" → Creates new version
  Storage:
• Current state: In entity table (CLAIM, EVIDENCE, SCENARIO)
• Historical states: In EDIT table (before_state, after_state JSON)
• Hot storage: Last 3 months of edits
• Cold storage: Older edits archived to S3