Reputation history stored for trend analysis

Reputation monitoring that overwrites the current value on each update cannot answer the question every deliverability incident requires: was reputation already trending down before the campaign that triggered the alert, or did it spike suddenly? Trend analysis distinguishes a gradual erosion (a list quality problem) from an acute spike (a bad campaign or an infrastructure misconfiguration). Without historical rows, you cannot correlate reputation changes with specific sends, detect seasonal patterns, or demonstrate to an ESP's abuse team that a reputation problem is resolved. The operational blind spot shows up worst in post-incident review.

Add a time-series model alongside (not replacing) the current-value model. Use a composite unique key on (domain, date) so daily runs are idempotent:

// In prisma/schema.prisma
model DomainReputationHistory {
  id            String   @id @default(uuid())
  domain        String
  date          DateTime @db.Date
  spamRate      Float?
  inboxRate     Float?
  dkimPassRate  Float?
  createdAt     DateTime @default(now())

  @@unique([domain, date])
  @@index([domain, date])
}

// Daily cron — upsert so reruns are safe
await db.domainReputationHistory.upsert({
  where: { domain_date: { domain, date: startOfDay(new Date()) } },
  update:  { spamRate, inboxRate, dkimPassRate },
  create:  { domain, date: startOfDay(new Date()), spamRate, inboxRate, dkimPassRate }
})

Query this table with a 30-day or 90-day window to render trend charts and detect sustained degradation. Keep the single-row DomainReputation model for current-state lookups that need low latency.