Skip to main content

Audit and Timeline Storage

Audience​

Developers, QA and support engineers, data reviewers, implementation partners, solution architects, privacy reviewers and security reviewers.

Reference Content​

Summary​

Audit/history is context-local: Recruitment and Employee have audit/timeline records, compatibility exit has its own audit log, Asset has audit/timeline records, and Notification stores delivery audit evidence.

Evidence map​

Confirmed behavior​

Recruitment completion writes audit and timeline entries with the aggregate changes and outbox intent in one local save. Employee similarly stores local lifecycle evidence. Compatibility exit controller paths add action-specific exit history. Asset and Notification evidence remain in their respective contexts.

Limits of evidence​

  • No shared event identifier or database relationship unifies all audit stores.
  • Immutability, legal hold, cryptographic integrity and archival were not found.
  • Application logs are not a substitute for these persisted records, and persisted records are not proof of downstream completion.
  • Personal data may appear in metadata or descriptions; redaction policy requires confirmation.

Operational use​

Support investigations must correlate by permitted business context and time while respecting tenant and privacy boundaries. Direct cross-database joining is not a documented support mechanism.

Requires confirmation​

Unless explicitly confirmed above, production migration governance, rollback, reconciliation, retention, privacy, performance, concurrency and operational ownership require confirmation.

Source References​

  • microservices/src/recruitment-service/Infrastructure/RecruitmentDbContext.cs
  • microservices/src/employee-service/Infrastructure/EmployeeDbContext.cs
  • Models/ExitRequestAuditLog.cs

See Also​

Keywords​

  • Onboarding database
  • Offboarding database
  • Lifecycle persistence

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-20
  • Review cycle: Quarterly