If we can't tell a member who looked at their record, we don't deserve to hold the record.

Why an audit log

A union local that uses our platform is asking us to hold one of the more politically and economically sensitive facts about each of its members: are you, right now, in good standing. Members deserve to know who has consulted that fact, when, and why.

We log because:

• Members can ask. A member with concerns about retaliation or surveillance can ask the union — or us, through the union — for the verification history of their own card. They will get a clean record, not a "let me check with IT."
• Disputes need evidence. When a contractor claims a worker's card said "inactive" on Tuesday at 14:32, the audit log either confirms or refutes that. Most disputes evaporate when the log is on the table.
• Operators must be accountable. Including us. The audit log catches our own mistakes and our own misuse the same way it catches anyone else's.

What we log

Three categories of event are recorded.

Reads

Every time the digital card or the verifier is opened for a particular member ID:

• Timestamp (UTC, millisecond precision)
• Member ID (the UUID on the URL)
• Surface (card or verify)
• Result returned (active, inactive, suspended, or not_found)
• Coarse network indicator: city/region inferred from IP. Raw IPs are kept for thirty (30) days only and not exposed in the customer-facing log.
• User agent string

Writes

Every change to a member record:

• Timestamp
• Actor (the union admin's identifier; the operator's identifier when we make a change on the customer's instruction)
• Member ID affected
• Field changed, with previous value and new value
• Reason text the actor entered (free-form, optional but encouraged)

Administrative actions

• Sign-ins and sign-outs of customer administrators
• Invite, remove, or change-role of an admin
• Bulk roster imports and exports
• Audit-log exports themselves (yes — we log the log access)

The shape of an entry

For the developers and curious admins, here's what one entry looks like in our schema:

{
  "id":          "log_01HKQ…",         // ulid, sortable, unique
  "ts":          "2026-05-09T18:22:11.412Z",
  "kind":        "read",                // read · write · admin
  "surface":     "verify",               // card · verify · admin · system
  "actor_kind":  "anonymous",            // anonymous · admin · operator
  "actor_id":    null,                   // null when anonymous
  "subject_id":  "550bc413-53db-…",      // member UUID
  "result":      "active",
  "geo":         "Toronto, ON · CA",
  "ua":          "Mozilla/5.0 …",
  "prev_hash":   "sha256:…",             // hash of previous row
  "row_hash":    "sha256:…"              // hash of this row's canonical form
}

prev_hash and row_hash form an unbroken chain. Any tampering with a past row breaks every later row.

What we do not log

• Free-text data about members beyond what is in their record. The audit log is structured. We do not write narrative notes about members anywhere.
• Raw IP addresses in the customer-visible log. They exist in technical logs for thirty days for abuse response and are then deleted.
• The contents of administrator emails or anything outside the platform.
• Behavioural profiles. We do not derive interests, employer affiliations, geography histories, or any other inferred attribute from the log. We have no business doing that.

Tamper evidence

The audit log is append-only at the database level — no UPDATE or DELETE grant exists for any role, including the operator's. Every entry includes a hash of the previous entry, forming a chain. The chain head is checkpointed daily into write-once cloud storage; the day's checkpoint is signed and stored separately from the database.

If a row is altered or deleted in defiance of the schema, the chain breaks and any subsequent verification of the day's checkpoint will fail. The integrity of past audit logs does not depend on trusting the current operator.

Who sees the log

• Customer administrators see the full log scoped to their union. They can filter, search, and export at any time.
• Members can request the read history of their own record from their union. Customers can fulfill the request directly from the admin console; they can also delegate it to us by writing to privacy@theunionhub.com.
• The operator has read-only access for security, support, and incident response, and cannot delete entries.
• Third parties — including verifiers who hit the public verify URL — have no access to the log itself.

Exports & APIs

From the admin console, customers can export the log as CSV or NDJSON, filtered by date range, surface, member, or actor. Exports include the row and previous-row hashes so an external party can verify the chain offline.

An authenticated REST endpoint is available for customers building their own dashboards. Rate limits and pagination are documented in the developer guide; ask support@theunionhub.com for access.

Retention & deletion

Audit log entries are retained for seven (7) years from creation, aligning with Ontario labour-relations record-keeping practice. After seven years, entries are moved to write-once cold storage and eventually destroyed in line with the customer's instructions.

If a customer terminates service, the schedule in the DPA applies: a complete export within thirty days, deletion from production within sixty, deletion from backups within ninety.

vs. system logs

This page describes the audit log: the record of who did what to which member's data. It is distinct from system logs — the technical web-server, database, and network logs the operator keeps for thirty days for security and abuse response.

The two have different retention, different access, and different audiences. The audit log is for members and customers; system logs are for the operator. Neither is sold, shared, or used for purposes other than running the platform.