Skip to main content

How QAudit works

QAudit records what Quadient and Serensia products do on behalf of your organisation — and it does so in a way that you can verify independently. Once an event is written it cannot be changed or deleted; QAudit uses a hash chain to make any attempt to do so detectable. Events are retained for at least ten years, so the record is there when you need it.

Products send events to QAudit as they work. Each event is an immutable record of something that happened — a document processed, a flow completed, a signature applied. QAudit receives each event, signs it, links it into a hash chain, and stores it. That is the core guarantee:

  • Completeness — every event accepted by the gateway is stored, unaltered, in the order it arrived. Events that do not meet the expected format or schema are rejected with an error — nothing is silently dropped.
  • Non-repudiation — the platform's signature on each event means neither the emitter nor the platform can later deny that the event was received at a specific time with a specific payload.
  • Independence — verification is based on standard Ed25519 cryptography and a public key distributed at onboarding. Events can be verified without going through QAudit; no trust in the platform's runtime is required to check the signatures. QAudit provides a Verification SDK for those who want a ready-made implementation; those who prefer not to rely on it can reimplement verification from the cryptographic specification documented in this guide.

On top of that foundation, QAudit offers a set of features that transform the raw event stream for different needs: KPIs aggregate events into the metrics that reflect contractual or regulatory commitments; evidence packs package a KPI and its source events into a self-sufficient, portable, verifiable archive for auditors or regulators; reports and the dashboard make the data browsable and exportable.

The rest of this page walks through the four moving parts: emitters, the Audit Gateway, the event store, and the applications.

Emitters​

An emitter is a Quadient or Serensia product that sends events to QAudit — for example, when a document is processed, a flow is completed, or a signature is applied. The emitter sends each event over a mutually-authenticated encrypted connection (mTLS), so the Audit Gateway knows exactly which product the event came from.

Emitters send events and decide what the payload contains, but they do not control how events are stored, signed, or chained. Once an event leaves the emitter and reaches the Gateway, the emitter's role is complete.

The Audit Gateway​

The Gateway is the single entry point for all events. It does four things for each event it receives:

  1. Validates the event envelope — is the tenant known? Is the payload well-formed?
  2. Canonicalises the payload to a deterministic byte sequence (RFC 8785 JCS), so the same content always produces the same bytes regardless of how the emitter serialised it.
  3. Signs the event with an Ed25519 key held securely in the platform's key management system. The signature covers the canonical payload, the receipt timestamp, and the event's position in the chain.
  4. Persists the event atomically — the event is written to the store and the chain is updated in a single transaction. The emitter receives an acknowledgement only after both steps are durable.

The acknowledgement the Gateway sends back includes the signature, the receipt timestamp, and the chain position — allowing emitters to verify the integrity of their own submission.

The event store​

Every accepted event is stored in an append-only database hosted inside a French sovereign cloud (SecNumCloud). Events are never modified or deleted during their active retention period; the store only grows forward.

Each event is stored with:

  • its canonical payload — the deterministic bytes the signature was computed over;
  • its signature — the platform's Ed25519 signature, verifiable against the public key distributed at onboarding;
  • its chain position — a hash that links this event to the previous one on the same tenant's chain.

Together these three make every event independently verifiable: the bytes are unaltered, the platform signed them, and no events have been inserted or removed since signing.

The applications​

Two applications expose the stored data:

  • Dashboard — a web application for browsing event history, inspecting KPI trends, and downloading evidence packs.
  • Reports — scheduled and triggered reports, delivered by email. Each report is itself a signed PDF, with a reference to the underlying evidence pack.

The dashboard and the Reports engine read the event store directly; they do not recompute or alter the stored events. What the dashboard displays is what was stored; what an evidence pack contains is what was signed.

For the mechanics behind how events are linked to one another, see The event chain. For the signature details, see Signing and integrity.