The Evidence hub: sealed files, links, connectors and freshness

Evidence (under Do the work) is the cross-portfolio view of every record you hold as proof. Each row is one file, link or generated document, with its SHA-256 fingerprint, the obligations it satisfies across every framework, the system or organisation it belongs to, who filed it and when, and whether it is sealed.

Reading the hub

Four counts run along the top — Evidence files, Sealed, Pending seal and Lapsing ≤ 30 days — and the filters below them (All · Sealed · Pending · Lapsing) narrow the table to match. The columns are File · Satisfies · Scope · Uploaded · Status. The Satisfies chips name the requirements the record is linked to, coloured by framework; open a row's links to see every obligation it proves and reuse it elsewhere.

Three actions sit in the header:

• Upload evidence — a file (PDF, DOCX, XLSX, PNG or JPG, up to 10 MB) or a link the auditor can open, with a title, attached to an obligation (narrowed by system) or filed as an organisation-level record when it proves something across the whole workspace. Verified links are re-checked on a schedule.
• Generate document — produce a document from a template, composed from the obligation data you have already entered; it is filed here as generated evidence.
• Export manifest — the list of every record with its fingerprint, for an auditor to check nothing changed.

Fingerprints and seals

Every record is hashed with SHA-256 on arrival. Re-uploading the same document is recognised as the same evidence rather than a duplicate, and one data-governance policy can satisfy obligations on a dozen systems — the hub shows that read-across. A record is sealed once verified; a generated document is sealed with the hash of the exact bytes produced. The same fingerprint travels into the audit bundle's integrity manifest and onto the public verify page. Everything that renders a hash uses one primitive, middle-truncated on screen and copied in full.

Links point at a version

A link between evidence and an obligation records which version it was made against. Where a generated document has since been regenerated, the link reports superseded rather than quietly resolving to the newer text — and the version that was linked stays retrievable in the Issued archive on Documents. Links the composition engine made are marked derived and cannot be removed by hand, because deleting one would make a coverage figure lie; links a person declared are theirs to remove.

OAuth connectors — bring evidence in automatically

Rather than upload by hand, connect the tools your proof already lives in. The Connectors panel offers Google Drive, SharePoint / OneDrive, GitHub and Jira as read-only OAuth connections. A connector can be connected only where this deployment has its OAuth app configured, and connecting is an admin action. Once connected, Sync pulls the most recent items in as Connected evidence, deduplicated so a re-sync does not pile up copies; Disconnect at any time. See OAuth evidence connectors: Drive, SharePoint, GitHub, Jira.

Freshness, expiry and renewal

Proof goes stale — a certificate lapses, a signed policy ages out, a dated screenshot stops reflecting reality. Veritome tracks this:

• Give a record an expiry date or a review cadence. Records with no expiry are evergreen.
• Each record carries a freshness state — fresh, expiring (inside the 30-day window) or expired — shown as a badge once it needs attention.
• A daily job reminds owners and admins as evidence approaches or passes expiry and drops expired proof out of coverage until it is renewed. It does not change the obligation's status — the control is flagged at risk, not failed.
• Renew a record to re-verify it and roll its clock forward one cadence.

The Dashboard's Expiring ≤ 30 days tile is this count. Coverage, links and freshness together are what let you walk into an audit knowing which controls are proven, which are stale, and which are still bare.