History/audit tracking
Why it matters
Without a history table or audit log, a booking system cannot answer the most basic support questions: "who cancelled my appointment?", "when was this booking confirmed?", or "was the reschedule requested by the customer or the provider?". ISO 25010:2011 maintainability requires that state changes are traceable. In regulated contexts (medical scheduling, legal appointments, financial services), audit trails are legally required. Even in unregulated systems, the inability to reconstruct booking history turns routine customer disputes into unresolvable conflicts and forces manual database forensics for every support ticket.
Severity rationale
Info because audit logging improves operational visibility and dispute resolution but does not directly cause data corruption or security exposure when absent.
Remediation
Create a BookingLog table and write a transition record on every status change. Add the model in prisma/schema.prisma and call the log function from your booking service.
// schema.prisma
model BookingLog {
id String @id @default(cuid())
bookingId String
fromStatus String
toStatus String
actorId String
createdAt DateTime @default(now())
}
// booking-service.ts — call on every transition
async function logTransition(bookingId: string, from: string, to: string, actorId: string) {
await db.bookingLog.create({
data: { bookingId, fromStatus: from, toStatus: to, actorId }
});
}
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Booking Flow & Lifecycle Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · security.accountability — Accountability — booking status transitions traced to actor and timestamp
Taxons
History
- 2026-04-18·v1.0.0·Initial import from booking-flow-lifecycle·automated