Audit Trail — verifiable proof

01A trail of proof, not a diagnostic log #sec_8812bfdf

An application log helps an operator understand a technical incident. An audit trail must enable a client or auditor to establish who did what, on which scope, with what result and why. REVIEWIT treats these two needs as two distinct domains.

Audit Trail constitutes the common core for all surfaces: authentication, API, administration, campaigns, certifications, RITA and platform processing. Actions share a stable catalog instead of lists coded differently in each application.

An action's code is its durable key; its label is a translatable resource. Correcting a formulation therefore does not rewrite history, and searches remain reliable from one version to another.

02Two capture paths, depending on what happened #sec_1dcb577c

A successful act and a refused attempt do not obey the same atomicity.

For a successful act, the audit event is written in the same transaction as the business change, thanks to an outbox. If the transaction fails, neither the act nor its trace of success persists. It becomes impossible to observe a durable change without the corresponding audit entry.

For an attempt, a refusal or a failure, the trace follows an autonomous path. The act has precisely not succeeded, but its attempt may be important for security. A replay guarantees that it is not silently abandoned.

The failure policy is declared by action category. A critical security operation may be refused if its trace cannot be guaranteed. For other acts, the business continues and an alert signals the degradation. An audit failure is therefore neither always blocking nor always ignored: its effect is explicitly decided.

03The useful content, and only it #sec_8dce8c36

An event answers the essential questions: identity of the actor, effective role, possible borrowed actor, UTC time, action code, result, subscription, workspace, campaign, target, modification, reason, channel and correlation.

Parameters describe the intention; modifications describe what actually changed. The identity and label of the target are frozen so that the event remains readable after a person leaves or a resource is renamed.

Minimization remains a rule of proof: the trail records the act, not a general copy of the data. Sensitive values are masked or qualified. A consultation of personal data, an export or the reading of a proof can itself become an audit event.

Visibility follows the scope. The subscription administrator and the auditor see the subscription according to their mandate; the workspace administrator sees only what concerns his workspace. The Auditor role remains read-only: consulting the proof must not allow piloting the observed system.

04A chain whose alteration is visible #sec_5a62e85f

Each event has a sequence, the fingerprint of the previous event and its own fingerprint calculated on a canonical form. Removing, reordering or modifying an entry breaks the chain.

Periodic seals sign the chain head. They elevate the guarantee beyond simple chaining by separating the ability to write the database from that of signing its state. An external anchor can further strengthen this guarantee against complete compromise of the operator.

The verification report never claims more than it demonstrates. It specifies the beginning of the guaranteed period, the last controlled seal, the number of more recent events covered by chaining alone and the possible presence of purge milestones.

The signature of an export answers another question: it attests that the document corresponds to the produced extraction. It does not replace the trail seal. An export therefore indicates to which head and which seal it anchors.

05Search, export, verify and retain #sec_f798b47c

Audit Trail offers four complementary readings:

• search by actor, action, period, scope, target, result or correlation;
• render a chain understandable by a non-technical auditor;
• export incrementally or feed BEACON;
• verify continuity, fingerprints and seals in a reproducible report.

Archiving and purging are not the same. Archiving moves event bodies to cold storage while leaving the verifiable chain and repatriable content. Purging destroys the content and retains only the milestones necessary to prove that a legitimate deletion, and not a falsification, has occurred.

The audit foundation — security actions, authorizations, secrets, tenants, RITA governance and the module's own operations — is protected and cannot be disabled. Current readings can be sampled when they are very numerous; sensitive consultations and critical acts are never sampled.

06In summary #sec_95815aed

Audit Trail transforms REVIEWIT activity into an ordered, minimal and verifiable narrative. It links the trace to the success of the act, retains failed attempts, makes any alteration detectable and clearly exposes the level of guarantee actually achieved.