Manage the document vault

What the vault stores

The vault holds the files behind your declarations: test reports, certificates, declarations of conformity, supplier statements. Uploading stores the file, its SHA-256 hash and its metadata (type, issuer, issue and expiry dates, access level).

Storage is either the local volume or an S3-compatible bucket depending on deployment, and the difference is invisible in the console.

Extraction saves typing

On upload the platform reads text-like content and suggests fields and dates, storing what it found in the document record. The vault table shows how many fields were extracted and the validity window it inferred.

Suggestions are suggestions: review them against the file before you rely on them. If a document cannot be read, the record says so instead of guessing.

Expiry and supersession

Documents carry expiry dates, and the vault counts what expires in the next 30 days so a certificate does not lapse unnoticed.

Replacing a document links it to the one it supersedes, which produces a version chain you can show an auditor: what was relied on, and what replaced it.

Verifying a file

The verify action recomputes the file hash and compares it to the stored one. Use it whenever a file has travelled by email or been re-saved, because a changed byte is a changed document.

Encryption at rest and share links

When the operator has set a storage encryption key, every file - documents, supplier uploads, data-entry sources - is encrypted with AES-256-GCM before it reaches object storage or disk, and decrypted only when an authorized request reads it. A document's SHA-256 is always that of the original file, so evidence pinned to a hash keeps verifying.

Share link issues a download link signed by the platform: anyone holding it can download the file until it expires (24 hours from the console), and it stops working as soon as the file is replaced or deleted.

Verifiable credentials on evidence

A certification body or supplier may issue its certificate as a verifiable credential. Paste it on the document (a VC-JWT, or JSON with an eddsa-jcs-2022 Data Integrity proof) and the platform checks the signature against the issuer's DID (did:web, did:key or did:jwk), the validity dates and the issuer's revocation list, and whether the credential names this file's SHA-256. If the issuer's did:web domain belongs to a supplier whose domain you have verified, the credential is shown as coming from a verified issuer. Check again at any time: revocation lists change.

Public and restricted files

A document marked public is served on the public passport - but only for an active passport, and only through the public endpoints. Keep certificates with personal data or commercial terms private.

Retention

Documents are evidence, so the platform does not sweep them: your retention settings cover operational telemetry such as scan events and webhook delivery attempts. Keep evidence at least as long as the obligation it supports requires.

How is received evidence accepted or rejected?

The vault distinguishes received, under review, accepted and rejected evidence. Owners and administrators record a reason and confirm issue/expiry dates against the original file; an unknown date can remain blank. The decision records the actor, time and revision in the audit trail. Conflicting decisions require reloading; a review cannot rewrite the file or its supplier upload receipt.

For rejected supplier evidence, Create linked correction request makes one follow-up request tied to the original receipt. Repeating the action returns the same follow-up. Open the supplier and send its new invitation separately. The original upload stays locked; ordinary rejected vault evidence uses the existing replacement upload instead.

How do I link evidence to a declared claim?

Open a passport and choose Evidence & audit package. Select an immutable passport version, an existing field with a declared value, and accepted, unexpired, non-superseded evidence. Enter the supporting quote and optional page/note. The server captures that version's value and the document hash; it does not take a value supplied by the browser.

Links stay historical if a file is deleted, rejected, expired or superseded, and show that health state. A new passport version needs its own links. Quotes are reviewer assertions, not automatically verified statements. Acceptance and links do not change the existing publication gate or automatically certify the passport.

How do claims and passport provenance work?

Open Claims & evidence graph to record a claim once - a subject, an attribute and a value, such as a material lot's recycled content - and attach accepted, current, unexpired documents with a quote and page. The claim is supported while at least one of them stays valid with an unchanged hash; support is recalculated on every read, so an expired, superseded or altered certificate never shows as valid.

Record which passport fields rely on the claim. The working revision must already state the claimed value; reliance traces a value, it never writes one. The evidence-expiry table ranks documents by how many passports would be left without support, and the action inbox flags claims losing support and passport fields that no longer state their claim. On a passport, Provenance shows for every field which version introduced it, which supplier response declared it, its evidence and claims with issuer and reviewer, and the rules that read it.

How does background PDF and image reading work?

PDF/image uploads, including supplier evidence, are queued after safe file storage. Plain text is read immediately; Office files can be stored but are not readable by this pipeline. In Documents, select the scan language and choose Read text. Check status refreshes queued, running, completed or failed results; viewers can check status but cannot request a new read.

The worker verifies the tenant-scoped file hash and reads at most 10 PDF pages, 50 MB and 100,000 characters, with a 45-second native-reading deadline. Partial and unreadable results are explicit: a completed job is not proof that all text was read. A failed queue/read never unlocks a supplier slot or deletes the uploaded file. Retry when the worker is available; requests are limited to 100 per organization per hour.

Reading preserves original-language text and updates only text-reading suggestions, not human review, confirmed validity dates or passport declarations. Wait for reading to finish before requesting AI extraction. Direct binary AI uploads must first be stored in Documents; pasted text remains available. Suggestions still require human review.

Screen-by-screen reference

These pages were checked in the organization console on 8 October 2026 using an isolated sample organization. Controls can differ by role, plan, record state and configured providers. Each page below explains its purpose, a practical workflow, the visible controls and what to verify afterward.

Passport evidence and audit package (/dpps/[id]/evidence)

Evidence links pin an accepted document's hash and a quote to a field value in a chosen immutable passport version.

Choose the exact saved version and declared field before attaching a file. The quote, optional page, and captured document hash explain why that version's value was considered supported at review time. Download the audit package for internal traceability, and create a fresh link if a later version changes the field.

A reviewer quote is an assertion. Linking evidence does not certify the value or change the publication gate.

Controls and options

• Choose Passport version and an existing Declared field; then choose accepted, current evidence.
• Enter the supporting quote and optional page or reviewer note, then Link evidence.
• View version opens the exact snapshot; Download internal audit package exports its internal JSON manifest and trace.
• Review link health if the document is later rejected, expired or superseded; create new links for later versions.

Field provenance (/dpps/[id]/provenance)

The field list traces saved values to versions, supplier responses, evidence, claims and the rules that read them.

Select the version being reviewed and filter for missing evidence or unsupported claims to focus the list. Open a field to see its saved source, linked supplier response or document, and the rules that consume it. Follow the evidence link to repair a traceability gap on that version; a source label by itself is not proof.

Missing provenance is a cue for review; a displayed source does not itself prove a fact.

Controls and options

• Select Version to inspect the state at that point in history.
• Show filters all fields, missing evidence or claims without valid support; Apply updates the view.
• Open a field row to inspect its recorded source, supporting links and health warnings.
• Link evidence returns to the version-specific evidence workflow.

Document vault (/documents)

The vault stores uploaded files, SHA-256 hashes, review decisions, expiry dates, extraction status and links to passports.

Upload a file with the correct type, access level, and optional passport link, then verify its hash and review status before using it as evidence. Text reading and AI extraction are separate aids: they may suggest content, but do not accept a document or change a declaration. Confirm dates and the original file during review, and re-check links if evidence later expires or is replaced.

Public access depends on both document access level and a published passport.

Controls and options

• Filter All documents or expired/due evidence; upload a file with title, type, access level, optional passport and replacement link.
• Download retrieves the file; Verify recomputes its hash; Read text and Check status handle extraction; Extract with AI proposes fields for human review.
• Owners and admins open Review evidence and confirm dates to accept, reject or keep a file under review with a reason.
• Share link issues a time-limited link only when signed object storage is configured; otherwise download the file securely.
• Attach a verifiable credential when the issuer provides one, then inspect signature, identity, expiry and revocation status.

Claims and evidence graph (/claims)

A claim records one subject, attribute and value so multiple passport fields can rely on the same evidence-backed assertion.

Create one claim for one subject, attribute, and value, then reuse that claim when several passport fields rely on the same assertion. Inspect the support indicator before relying on it; support can change when evidence expires, is rejected, or no longer matches its stored hash. A claim record alone does not populate a passport field.

Recording a claim does not write the claimed value into a passport.

Controls and options

• Record a claim with subject type, subject, attribute, value, optional unit and supplier.
• Search or filter the list to find a claim; open it to inspect support and use.
• The support column is recalculated from accepted, current, unexpired files with unchanged hashes.

Claim detail (/claims/[id])

The claim page shows its support state, evidence quotes and passport fields that rely on the claim.

Open the claim to see the exact quote and file behind its support. Before adding passport reliance, check that the working declaration already contains the same value; the link records provenance instead of copying data. If the claim is revised or withdrawn, inspect every relying passport and resolve mismatches explicitly.

A changed claim can leave existing passport reliance inconsistent until corrected.

Controls and options

• Attach supporting evidence by choosing an accepted document and entering its exact quote and optional page.
• Rely on this claim in a passport records a link only when the working field already equals the claim value.
• Open evidence review to inspect file status; Detach removes a link while preserving the claim record.
• Administrators can Change or withdraw this claim with a reason and revision check.