Audit log

The audit trail answers one question for a compliance reviewer: who did what, when, and to which record. Piprio records that trail at two levels. Administrators see the history of platform actions taken inside their organization. Reviewers and the records they touch carry a separate, decision-by-decision history of how every label was reached. Both are queryable, both export to a flat file a reviewer can hand to an auditor, and both are kept for the life of the organization.

What gets logged

Three categories of activity are recorded.

Administrative actions are the changes an owner or administrator makes to the configuration of the organization: connectors created or removed, schemas changed, roles reassigned, billing and security settings altered. Each record names the action, the resource it touched, the person who performed it, the time, and the originating network address. Where an action changed a value, the record keeps both the prior value and the new one, so a reviewer can see the before and after without reconstructing it.

Label decisions are recorded as an event stream against each label set. Every meaningful moment in a label's life leaves an entry: an AI proposal, a submission for review, an acceptance, a rejection, a validation warning. The stream distinguishes machine-generated values from human ones, so AI output stays separable from reviewer judgment at every step. This stream is the basis for the per-decision audit data described below, and it is the record an auditor reads to confirm that a labeled dataset reflects human review rather than unchecked model output.

User-management actions are recorded separately: invitations, role grants, removals, and similar changes to who belongs to the organization. Each entry names the actor, the affected user, the time, and the originating address.

The label-decision history is meant to be append-only. New events are added, and existing events are not rewritten or removed in the ordinary course of work. That is the integrity property a buyer cares about, and the section on integrity verification below states exactly what enforces it and where the boundary sits.

Querying the log

An owner can pull the administrative-action history for the organization directly. The history filters by the kind of action, by the person who performed it, and by a date range, and returns the most recent matching records first. This is the surface a security reviewer uses to answer "who changed the export settings last quarter" or "show every action this administrator took." Access is restricted to the owner role.

The label-decision history is read in the context of the records it describes. A reviewer opening a label set sees its event stream in order, and the per-decision audit data below rolls those streams up across many records for reporting and export.

Exporting

The decision-level audit trail exports as a flat file an auditor can open in a spreadsheet, scoped to a date range and optionally to a single labeling specification. Each row covers one accepted label set and carries the document it describes, the connector it came from, the labeling specification and its version, the reviewer who accepted it with name and email, and the times it was submitted and accepted.

The same row reports how the decision was reached. It shows whether the values began as an AI proposal, the acceptance rate of those proposals against the values the reviewer kept unchanged, how many fields the label set covers, and how many validation warnings fired during review, including any that were never acknowledged. Each row also reports whether the document had already been included in a prior export, so an auditor can tell first-time deliveries from re-exports. The file streams as it is generated, so a wide date range does not have to be assembled in memory before the download starts.

The administrative-action history is available to the owner as a queryable record rather than a bulk download.

Integrity verification

The integrity guarantee is append-only history, not cryptographic tamper-evidence. Piprio does not hash-chain or sign audit records, and a buyer evaluating the platform against a control that requires cryptographic proof of tamper-evidence should treat that as absent today.

What the platform does provide is a recorded history that the ordinary application code only adds to. Audit records are written inside the same transaction as the change they describe, so a configuration change and its audit entry either both land or both roll back. There is no path in which a change ships without its record. A structural test runs on every build to keep that boundary intact: it rejects any change that would let a record be written and committed outside the controlled request boundary. The administrative-action history goes further on one point that a SOC 2 or GDPR Article 30 reviewer asks about directly. If the person who took an action is later removed from the platform, the action stays in the log and the record preserves a snapshot of that person's identity, so deleting an account cannot quietly erase the account's history.

Two boundaries on the append-only property are worth stating plainly, because a procurement reviewer will find them. First, a validation warning on a label can be acknowledged, which updates that one event in place to mark it handled. That is the single case where an existing decision event is modified rather than appended to. Second, a right-to-erasure request for a specific person removes that person's entries from the user-management history, as data-protection law requires. The administrative-action log handles the same case by keeping the entry and preserving the identity snapshot rather than deleting it. Neither boundary is enforced by the database engine itself. Append-only is a property of the application, held in place by code review and the structural test, not by database triggers or revoked write privileges.

Retention

Audit records are kept for the life of the organization. There is no rolling retention window and no scheduled job that ages out or deletes audit history. Administrative actions, label-decision events, and user-management entries all persist until the organization itself is removed or a specific right-to-erasure request removes a named person's entries.

This is a deliberate split from the rest of the platform's storage. Export bundles are convenience files the customer can regenerate, so they are cleaned up automatically after a week. Invoices carry a statutory seven-year retention. The audit trail sits in neither bucket: it is kept indefinitely so that a compliance review years after the fact still has the full history to read.