Audit Log

Audit Log starts with the question the organization must answer, then defines the small set of events worth retaining. Its recommended workflow records an event, actor, and time, stores the record, reviews it periodically, and produces evidence. Logging depth follows the evidence question rather than capturing everything indiscriminately.

The default is a short recommendation. The skill answers advice directly, reviews a supplied process when asked, and builds artifacts only on request. It gathers missing facts about purpose, internal or external reviewers, event types, history depth, readers, tamper-evidence needs, retention, current completeness, and desired register or reporting output. It asks one useful question at a time and does not invent unknown answers.

Use it for an audit log, change-history tracker, activity-log database, or compliance-trail design. It fits Scale stage in the Protect layer. A request can be:

When a client questioned an approval we had nothing to show.

The module generates empty templates. It does not automatically capture events, provide reminders or synchronization, calculate payroll or tax, or establish legal compliance. A template is not a security control by itself; qualified legal, tax, and HR review remains necessary for real decisions.

The base eleven-field list comprises Log Entry, Date and Time, User, Module, Record, Action, Field Changed, Old Value, New Value, Reason, and Log ID. Date and Time uses SQL TIMESTAMP, JSON date-time, and a Notion date including time. Other descriptive values are text, with the identifier preserved on import. There are no select or relation fields in the base list.

Requested CSV, SQL DDL, JSON Schema, and Notion mapping derive from that shared list. Display names remain consistent across CSV and JSON, while normalized SQL names are documented. Excel-compatible CSV uses UTF-8 with a byte order mark and needs datetime formatting after import. A workbook requires a specific request. Templates stay empty; requested examples must be synthetic.

The additional review checklist examines event identity, actor, timestamp, target, action, result, and correlation reference separately. Keep original event text alongside normalized fields, record timezone and clock source, and mark missing values Unknown. Stable correlation IDs group related events without collapsing distinct actions into a summary row.

Review exports should first apply the requested time window, then check completeness, deterministic order, and authorized-system scope. Redaction retains a reversible reference to the original record and does not rewrite the underlying event. Retention, deletion, clock drift, failed writes, duplicates, and sequence gaps remain visible findings rather than filled-in values.

A fixed action vocabulary can include create, read, update, delete, export, approve, reject, login, permission-change, and retention-delete. Resource type and identifier stay separate from labels. Bulk-job review records the job ID, item count, start and finish, partial failures, and final status; one bulk event does not prove every item succeeded. Preserve observed order, mark grouped views as derived, and retain their query definitions. Missing events require a known expected boundary and source system before being treated as findings.

Notion output goes to notion-manual-import for mapping, import, and verification. Manual output needs no connection. Live writes require verified access, a target, authorization, and successful tool evidence.

Sensitive material should be minimized, generated templates kept empty, and privacy or disciplinary decisions referred to qualified reviewers.