Constituting the certification file
01In a nutshell #sec_146977ef
A certification file is not an export of everything: it is a selection of cited pieces, each verifiable without REVIEWIT, assembled in an archive whose imprint serves as a signature.
02The role to take #sec_3d14af3d
The screens of this process require the Auditor role, declared by the role menu at the top of the console. As an Auditor, the console opens on the Audit posture and everything is read-only: Active role: Auditor — read-only, with the authorization and its term. Switch back to Administrator to launch a campaign; remain Auditor to constitute.
An external auditor receives this same role, limited in time, and sees exactly what you see here — and nothing from the Internal report tracking shelf.
03Audit posture: what does this workspace allow to oppose? #sec_ea084a9b
This is the entry page, and its first sentence is a summary: N sealed attestation(s) cover N decided item(s). The scope includes N resources; the rest is read below, cause by cause. Then: Stopped at … Each count carries its scope. Nothing is smoothed, nothing is noted.
What is opposable — attested and sealed — an unattested decision does not appear there. Sealed attestations on the total, covered items, attested period, and the level of guarantee: SEALED · N1, ANCHORED TO THE OUTSIDE · N2, or CHAINING ONLY — and, if applicable, INTEGRITY COMPROMISED.
The state of the trail, in four facts, recalculated instantly on the entire chain of the subscription: the chaining (continuous — no break, no missing rank, or detected break), the purged segment (shorter, unaltered trail — the seals of the period are preserved), the generation (open or closed trail), the synthetic data (present: this restitution does NOT constitute proof of production). And the SIEM diffusion: where the trail goes, if it goes.
What is not opposable, by cause. A table, each cause has its count and its formulation; never an indistinct total. Review without seal, campaign under conservation, purged segment — the causes overlap, and no total is displayed, because there is no honest one.
The latest proofs: the five latest closures, with the strongest probative state reached by the campaign — Recorded, Anchored, Sealed. On each, Attach to the audit file.
04Constituting the file #sec_27acaf38
Constitute the file, in the Restitution & analysis menu. Browse the corpus of the workspace and attach what your file must cite. The file is preserved between two sessions.
The list contains all campaigns, filterable by status (Closed, In progress), by probative state (Sealed, Not sealed), sortable. Each line indicates how many requests have been decided and its probative state. Attach those that the auditor must read.
Attaching is not opening: consultation remains free. And removing from the file does not erase anything: the piece will no longer be cited in the exported archive. Nothing is deleted: only the citation disappears.
The In progress file block follows the selection. Empty, it says so and refers to the two sources: Attach a campaign from “The latest proofs”, or a verdict from “Verify a proof”.
05Verifying a proof, and citing it #sec_0f0f4672
Verifying a proof takes a verification package — complete, punctual or closing — and returns an instantly recalculated verdict, control by control. Nothing is read in REVIEWIT: the verifier only knows what you give him.
Three inputs, two of which are optional but decisive:
- The package (.json), as downloaded or provided by a third party.
- The public keychain of the authority. *Without it, the seal remains a declaration and the
verdict will say so.*
- The root key imprint, that of your security annex. *Without it, the signature
of the keychain is checked, but nothing establishes that this root is yours.*
The verdict lists N controls, in the order of execution of the verifier — nothing is folded: seal VERIFIED or NOT VERIFIED, keychain ANCHORED or OTHER ROOT, recalculated imprint. Each verification leaves a trace in the audit trail — one does not verify without a trace.
Attaching to the file preserves the verdict as it has just been rendered — it will not be recalculated at export. An auditor who has verified a piece can thus cite their own verification.
06Verifying a signed document #sec_d24613b4
For a PDF — a report edition, an attestation projection — Verifying a signed document recalculates integrity, signatory, PAdES level, and eIDAS qualification by the reference validator of the European Union. The document is not preserved; only the verification trace is. The verdict is the same as Acrobat or the EU online validator.
07Export #sec_f8988355
Compiling the file produces the archive. The screen summarizes: N campaign(s), N attestation(s) cited · file fingerprint: followed by the fingerprint.
The archive contains the canonical file (.json) and its readable summary (.xlsx). The summary is used for browsing; in case of discrepancy, the file is the authoritative source. It includes the verifiable packages of the cited pieces, and when a piece of evidence is missing, the manifest indicates which ones and why.
Submit the archive and its fingerprint. An auditor who has the published keychain and the Verify offline evidence page no longer needs you.
08The file of a resource #sec_d9d50443
From the posture, open a resource: its certification file lists all the decisions made on this resource, across all campaigns — decision, date, decider, justification, Campaign closure · rank N. A resource never covered by a review states this and names the campaign that can include it.
09To remember #sec_fb81c9bb
The posture states what is opposable and why the rest is not. The file cites, does not export everything. Each piece is verified individually, and each verification leaves a trace. This is what distinguishes a file from a bundle.