Keep a history of the security decisions that matter
Wildo turns sign-in activity, access decisions, administrative changes and recorded disclosures into structured evidence. Each event can be searched and connected to the actor, subject and request that explain it.
That history belongs to the product, alongside its business records, rather than existing only as a developer’s log output.
Example — Keep the history that explains security decisions
A reviewer follows a permission change back to its actor and request, then inspects the access activity that followed it.
For engineers
Framework producers call AuditLogsBackendService. The central writer assigns a stable eventId, resolves category and severity, adds available request context and persists the event through the audit repository. The same event identity is used by optional provider sinks.
The selected record construction in _createAuditLog shows the shared envelope:
Selected source from audit-logs.backend.service.ts:
const auditLogData = {
...auditEvent,
eventId,
...(correlationId ? { correlationId } : {}),
...(frontendServiceName ? { frontendServiceName } : {}),
...(clientInstanceId ? { clientInstanceId } : {}),
eventData: auditEvent.eventData as Record<string, any>,
eventCategory: classification.category,
severity: classification.severity,
createdAt: new Date(),
updatedAt: new Date()
};
Core events already have typed payloads, classifications and emitting callers. For application behavior, prefer the resource operation’s inherited event when it describes the change; add a purpose-built event when a distinct business fact needs its own payload and meaning.
Keep the subject distinct from the writer
An internal audit write is performed by the framework, but the row retains the person and organization the event concerns. The originating execution context supplies correlation and delivery authority; the temporary repository-write context must not replace the event’s subject.
Choose the additional destinations
The primary audit resource supplies immutable product operations: read and search are present, update and delete are absent. Customer security exports and an optional tamper-evident provider add separate destinations around that primary store.
Post-commit evidence failure does not turn a completed business change into a failed response. Audit failures have their own diagnostics and counters so operators can distinguish an evidence-pipeline problem from the operation that already succeeded. Infrastructure access to the database is a separate control; use the verified sink where independent integrity checks are needed.