Events
An audit event is the fundamental unit of data in QAudit. Every action that a Quadient or Serensia product records on behalf of an organisation arrives at QAudit as an event. This page explains what an event is and how events are named.
Anatomy of an event
Every event has two parts: an envelope and a payload.
The envelope carries the fields the platform needs to process the event regardless of its type:
| Field | Description |
|---|---|
event_id | A unique identifier for this event, assigned by the emitter. Used for deduplication. |
tenant_id | Which tenant this event belongs to. Mandatory on every event. |
event_name | The versioned name of the event type, e.g. pa.invoice.received.v1. |
date | The business date of the event, as reported by the emitter. |
receipt_ts | The Gateway's timestamp — when QAudit received and stored the event. |
signature | The platform's Ed25519 signature. See Signing and integrity. |
chain_link_hash | This event's position on the tenant's chain. See The event chain. |
The payload contains the event-type-specific content — invoice details, document identifiers, flow metadata, and so on. The payload is stored in canonical JSON form and is part of the signed bytes. Its exact shape depends on the event_name.
Event names and namespaces
Event names follow a dot-separated naming convention. The first segment is the namespace prefix, which identifies the system that owns the event type:
| Prefix | Owner | Examples |
|---|---|---|
pa.* | Serensia PA | pa.invoice.received.v1, pa.flow.completed.v1 |
sig.* | Serensia SIG | sig.invoice.converted.v1 |
qaudit.* | QAudit platform | qaudit.tenant.created, qaudit.tenant.signing-key.rotated |
All events are versioned. When a breaking change is needed — a field removed, a field's meaning changed — a new event type is created with an incremented version suffix (pa.invoice.received.v2). The old version continues to exist and is processed normally; there is no forced migration.
qaudit.* events are special: they record what the QAudit platform itself did — key rotations, configuration changes, tenant lifecycle events. They are internal to the platform and not visible in the organisation's dashboard. See Platform events for the full catalogue.
Deduplication
Each (tenant_id, event_id) pair is unique in the store. If an emitter sends the same event twice — which can happen during retries — the second submission is idempotent: QAudit returns the original signature and receipt timestamp without storing a duplicate.
If the same event_id arrives with a different payload, that is an error (EVENT_ID_REUSED_DIVERGING_PAYLOAD). This is recorded as a qaudit.ingestion.id-reuse-conflict event on the tenant's chain and the submission is rejected. Emitters must treat this as non-retryable.
Operation-audit events
In addition to business events from external products, the store contains operation-audit events — records of what the platform did and what users did inside QAudit itself. These are internal events, not visible to organisations.