How the Audit Log Works

When you act on behalf of a client, every change is recorded with full attribution. This protects both sides of the engagement: clients can see exactly what you did and when, and you have a defensible record of work performed.

What gets logged

Every change to client data records:

  • Action — what was done (e.g. invite, submit-meter-reading, update-property, create-report).
  • Resource — the type and ID of the thing that changed (e.g. property bldg_abc, meter mtr_xyz).
  • Actor type — representative (a consultant), user (a regular org member), or api_key (an integration).
  • Actor identity — your user ID, email, and name.
  • On behalf of — the client organization the action was performed for.
  • When — server-side timestamp.
  • Where — IP address of the request.
  • Metadata — action-specific fields (e.g. the values changed, the parameters passed).

Reads are not logged at this granularity. Writes, configuration changes, and admin actions are.

What this means in practice

  • The client can see "performed by [your name] on behalf of [their org]" against every change.
  • If a client wonders why a property was edited last Tuesday, the log answers it without ambiguity.
  • If you want to demonstrate the work performed during an engagement, the log is the source of truth — exportable as part of the client's reports.
  • Mistakes are recoverable in conversation: the log makes the timeline obvious.

What is not logged

  • Login activity itself (separate auth log).
  • Failed actions blocked by your access level (those don't reach the data layer).
  • Read-only views you load.

Honest caveats during the beta

The audit log is implemented and writes on every server-side mutation. UI surfaces for the client to browse the log are still being built out as part of the beta sprint — the data is in the database and queryable today, but the polished "audit" tab is on the roadmap. If a client asks for an export, contact us during the beta and we'll generate one.

Next