An application audit event should identify who or what acted, the action, affected object, tenant, request context, time, result, and safe change evidence, with a versioned schema that keeps those fields consistent.
Begin with a consequential action
An audit event should begin with a product action that a customer, operator, or support person may need to reconstruct. Examples include changing a role, exporting data, deleting a project, updating billing details, or running an automated operation. A generic log message such as settings changed leaves the reader unable to identify the actor, object, or effect.
The event catalog gives each action a stable name and defines when it is emitted. WorkOS models audit events around an action, actor, targets, context, and metadata, which provides a useful starting point. The catalog should also name the owning service and the product outcome that shows whether the action succeeded, failed, or was only requested.
Separate identity, target, context, and result
Actor fields distinguish a human user, service account, support operator, scheduled job, or agent. Target fields identify the object and its type. Tenant fields preserve organization or workspace boundaries. Request context can include a safe request identifier, source application, session reference, and coarse network information when the buyer has approved its collection and retention.
Change evidence should be selective. Before-and-after values can help explain a dispute, but secrets, credentials, tokens, and unnecessary personal data should never enter the log. For sensitive fields, the event can record which property changed, who authorized it, and the resulting object version without storing the value itself.
Version the event as part of the product contract
The event needs an occurrence time, ingestion time, unique identifier, schema version, and result. A correlation identifier can connect the user request, background work, and downstream events. The schema should reject missing required fields at the instrumentation boundary so a partial event does not silently become the permanent record.
Reality Contact, LLC can design and implement the event schema for buyer-approved actions. The buyer decides which actions matter, which fields may be retained, who may query them, and what the product presents to customers. The implementation is an operational record and does not itself establish compliance or legal proof.
Where the service stops
Reality Contact, LLC implements the buyer-approved event system, but does not choose legal retention, certify any framework, conduct a forensic investigation, decide customer access policy, or release production changes without buyer approval. The buyer approves the action catalog and policies, deploys the logging path, and verifies that the agreed action set produces complete, isolated, retrievable events. This is software instrumentation and technical testing, and it does not replace legal, privacy, security, compliance, forensic, or professional advice. The buyer owns event meaning, customer notices, access policy, retention and redaction decisions, credentials, production release, and framework interpretation.
Sources: WorkOS audit log documentation; OWASP Logging Cheat Sheet.