Evidence

Scope

Evidence only matters if teams can explain what it supports, whether it is current, and what should happen next when it changes. This guide keeps that operating guidance while excluding internal mechanics.

Overview

The Evidence system stores and tracks all compliance evidence artifacts for your programs. Evidence proves that your controls are working. Each evidence artifact is immutable, content-hashed, and tracked for freshness.

Uploading Evidence

File Upload

1. Choose an upload entry point: - Evidence > Upload Evidence for cross-program upload from the global workspace - Programs > [Program Name] > Evidence > Upload Evidence for a scoped program upload - Controls > [Control] > Evidence > Upload Evidence to open the global upload workflow with both the program and control already selected

2. Click Upload Evidence

3. In the upload modal: - If you started from Evidence, choose the target Program first. Program selection is required because every upload is recorded against a program even when it is not bound to a control. - Optionally pick a Control when the artefact belongs to one specific control - Optionally pick a Test after selecting a control when the artefact should participate in test-level auto-supersession - Leave the control blank for program-level evidence such as access review decision logs, broad attestations, or other artefacts that apply to the program as a whole - Drag and drop a file or click to browse - Enter a Title (required) - Add a Description (optional) - Select the Evidence Type (document, screenshot, manual upload, etc.) - Set Valid Until if the evidence has a known expiry date
4. Click Upload Evidence

Executables (.exe), scripts (.sh, .bat, .py, .js, .ps1), and web files (.html, .htm, .php) are blocked. Files with no extension are also rejected. For binary formats (PDF, PNG, etc.), the system verifies that the file content matches the claimed extension — a renamed executable will be rejected even if the extension is changed to .pdf.

Valid Until and Freshness Caps

Meridian enforces maximum valid_until windows when evidence is ingested so one artifact cannot keep a control fresh forever. Set Valid Until inside the cap for the selected evidence type:

Evidence type	Maximum Valid Until window
automated	90 days
api_response	90 days
log_export	90 days
screenshot	90 days
manual_upload	365 days
document	365 days

Use ISO 8601 datetimes with an explicit UTC offset, such as 2026-09-01T00:00:00Z or 2026-09-01T00:00:00+00:00. Meridian accepts datetimes without an offset and treats them as UTC. The cap is compared against the current UTC time.

What happens on upload

• The system computes a SHA-256 hash of your file for integrity verification
• The file is stored securely with a path tied to your account, program, and evidence ID
• The upload is recorded with your email as the collector (“manual:you@company.com”)

The evidence detail and timeline show a recognizable uploader or source with its authority context. They do not show the underlying collector token. If a historical uploader has since been removed, Meridian retains the recorded email and marks the actor as removed; contact a tenant administrator only if the source is unexpectedly unavailable.

• If you selected a control, the evidence is bound to that control through Meridian’s evidence-control binding table; that binding is what lists, freshness checks, dashboard counts, and evidence packages use
• If you leave control blank, Meridian stores the artefact as program-level evidence with no control binding
• An audit log entry is created

If you link the upload to a test, you must also select the control that owns that test. Meridian checks that the test belongs to the same control and values are rejected.

Evidence Packages

Evidence packages are tenant-scoped, point-in-time ZIP snapshots of an audit cycle’s evidence, manifest, hashes, and provenance. Generate packages from the audit cycle Evidence Package panel when you need an auditor-ready export or a share-token download package.

Viewing Evidence

Cross-Program Evidence Workspace

Navigate to Evidence in the sidebar to see every evidence artifact in the current account across every program. This is the default landing surface for audit prep and evidence curation.

Available filters:

• Search: Server-side substring match on title and file name (debounced)
• Program: Scope to a single program
• Type: Filter by evidence type (document, screenshot, api_response, etc.)
• Freshness: Show only fresh, stale, or expiring-soon evidence
• Show superseded: Toggle to include superseded evidence

Operators with Meridian.manage or Meridian.evidence.manage also see Upload Evidence in this workspace. The modal lets you choose a program first, then optionally scope the upload to a control and test, without leaving the cross-program evidence list.

Filter state is persisted in the URL so a refresh, share, or back-navigation restores the exact view. Each row shows the parent program name and control ref/title so you can navigate directly to the source without follow-up clicks.

Program Evidence View

Navigate to Programs > [Program Name] > Evidence to see all evidence for a single program.

Available filters:

• Control: Type-to-search control picker (SearchableSelect) for the current program

• Type: Filter by evidence type (document, screenshot, etc.)

• Freshness: Show only fresh, stale, or expiring-soon evidence
• Show superseded: Toggle to include superseded evidence

The Upload Evidence button is always available for operators with Meridian.manage or Meridian.evidence.manage. Use the control picker when you want to narrow the list or preselect a control for the upload modal.

Evidence Detail

Click any evidence item to see its full details:

• Title, description, and evidence type
• Collector (who uploaded it)
• Collected date and valid-until date
• Content hash (SHA-256) with copy button
• File information (name, size, content type)

or taller than the available viewport. Tab to the viewer, then use the arrow, Page Up, Page Down, Home, or End keys to inspect overflowing content without a pointer.

The detail page keeps artifact loading, control-binding loading, and lifecycle mutations as separate failure domains. A failed artifact load replaces the page with the specific error and a retry; it is not presented as a false “not found.” A binding-list failure leaves the artifact usable and provides a binding-specific integrity diagnostic instead of silently hiding the payload.

Lifecycle badges and binding types use controlled values. If a newer server returns an unknown value, the detail page preserves the original value in an explicit Unknown label so operators can diagnose contract drift. Operators with Meridian.manage or Meridian.evidence.manage can request recertification and supersede evidence; binding changes remain restricted to Meridian.manage. Failed binding creation keeps the selected control and binding type in the modal for correction and retry, and the modal cannot be dismissed while the mutation outcome is pending.

Understanding Freshness Indicators

Indicator	Meaning	Action
Green (Fresh)	Evidence is current	No action needed
Yellow (Expiring Soon)	Evidence expires within 7 days	Plan to collect new evidence
Red (Stale)	Evidence has expired	Collect new evidence for this control
Freshness Unknown	Older API data did not include an observation timestamp	Refresh the page; investigate the evidence record if it persists

Stale evidence is not invalid — it still counts for the period it covered. The indicator signals that you need to collect fresh evidence for ongoing compliance.

Freshness is evaluated at the control binding level. Evidence does not need a test run to become fresh, expiring soon, or stale; manual control-level uploads with a Valid Until date are monitored the same way connector evidence is. Connector-bound tests can be re-run automatically when a control goes stale. Manual-only evidence requires an operator to upload replacement evidence or supersede the old artifact.

When Valid Until is omitted, Meridian does not treat the artifact as fresh forever. It ages from collector_observed_at: fresh through day 23, expiring soon through day 30, then stale. The dashboard, list filters, detail page, and freshness badge all use this same rule. While an open recertification request exists, the UI shows Recertification requested as the governing state and does not simultaneously label the artifact Fresh.

Requesting Recertification

Use recertification when evidence needs owner confirmation or replacement but the old artifact must remain in the audit trail.

1. Open the evidence detail page.
2. Click Request Recertification, review the warning, and confirm. Nothing is created until you confirm.
3. Meridian creates an evidence-collection task tied to that artifact. If a request is already open, Meridian shows the existing task instead of creating a duplicate.

Invalid, inactive, nonexistent, or cross-tenant assignees are rejected before any task is created. Select a different active tenant user and submit again.

Evidence rows show one primary lifecycle badge:

Badge	Meaning
Current	Evidence is current and no recertification request is open
Expiring Soon	Evidence expires within seven days
Stale	Evidence is past valid_until
Recertification Requested	An open normalized request exists for the artifact
Superseded	A newer artifact replaced this one

To complete recertification, open Complete Recertification and either select an existing replacement or choose Upload replacement evidence. The upload flow is pre-scoped to the original program and primary control; after upload, the new artifact is selected automatically. Meridian rechecks the request version and replacement eligibility, then marks the old artifact superseded, records direct predecessor/replacement links, closes the task, records the replacement hash in task comments, and carries forward all control bindings. If the request was made in error, cancel it with a reason; cancellation does not alter the current authority.

AI Validation

AI validation evaluates evidence against the control it is bound to. If an evidence artifact has more than one control binding, validation without an explicit control uses the first binding; selecting a specific control only works when that control is actually bound to the artifact. Program-wide bulk validation follows the same binding relationship, so stale direct IDs from older evidence records do not make evidence appear in the wrong program.

Downloading Evidence

From the evidence detail page, click Download to retrieve the original file. The system verifies the content hash during download to detect any storage corruption. You’ll see:

• X-Content-Hash header with the SHA-256 hash
• X-Hash-Verified: true if the file integrity is confirmed

If a hash mismatch is detected, the download will fail with an error. Contact your administrator if this occurs.

Superseding Evidence

The test selector is scoped to the selected control and program. You cannot point evidence at a test from another control, another program, or another tenant.

For manual evidence not linked to a test, you can manually supersede it:

1. Open the evidence detail page
2. Click Mark Superseded
3. Confirm the action

Superseded evidence is hidden from list views by default. Check “Show superseded” to see the full history.

Superseded evidence is never deleted — it remains in the audit trail.

Evidence Types

Type	Use For
Manual Upload	General file uploads
Document	Policies, procedures, certificates
Screenshot	UI screenshots as evidence
Log Export	Exported log files
Automated	Evidence collected by connectors

Binding Evidence to Multiple Controls

Evidence can be bound to more than one control when a single artifact proves multiple obligations. This is common when evidence covers overlapping framework controls (e.g., a SOC 2 CC6.1 artifact that also satisfies an ISO 27001 A.9.1 control) or when one audit log covers several unrelated controls in the same program.

Single binding

Binding mutations are blocked once the evidence’s parent program or the target control’s parent program is archived. Archived programs are terminal and their evidence set, including control associations, is frozen.

Bulk binding

Bulk binding is not all-or-nothing. Each control in the list is attempted independently. Controls that succeed are committed. Controls that fail produce a per-item error in the response — other items are not rolled back.

Bulk binding uses the same archived-program freeze as single binding. If the evidence belongs to an archived program, or an individual control belongs to an archived program, that item returns an error and no binding row is created.

Check errors in the response. If non-zero, inspect the results array to identify which controls failed and why.

Partial failure recovery

Bulk binding is idempotent-retryable. Re-submitting the same request skips controls that already have a binding and retries only the ones that are not yet bound. You do not need to clean up succeeded items before retrying.

Steps to recover from a partial failure:

1. Read the results array in the bulk bind response to identify failed control IDs and their error reasons.
2. Resolve the root cause for each failed item (see common reasons below).
3. Re-submit the bulk bind request with the same control IDs (or just the failed subset). Already-bound controls are silently skipped; the others are attempted.

Common bulk-binding failure reasons

Error	Cause	Fix
Control '{id}' not found	Control ID does not exist or belongs to a different account	Verify the control ID and that it is in the same tenant
Evidence and control must belong to the same account	Cross-tenant binding attempted	Confirm both evidence and control are owned by the same account
Cannot modify evidence bindings in an archived program	The evidence or target control belongs to an archived program	Bind or unbind before archiving, or create a new active program for new evidence coverage
Evidence is stale	The evidence valid_until date has passed	Upload fresh evidence, then bind the new artifact
Evidence is superseded	A newer artifact replaced this one	Bind the replacement evidence artifact instead
Evidence has an open recertification request	A recertification task is in progress on this artifact	Complete or cancel the recertification task, then retry

Importing CSV as Structured Evidence

Use Import CSV on the evidence workspace for tabular exports. Select a UTF-8 .csv names should differ from source column names. Imports are limited to 50 MB and 10,000 rows. Missing columns, malformed mappings, invalid encoding, and empty files are rejected before an evidence record is created.

Evidence validation now reports a deterministic quality gate with concrete reasons. An AI advisory may suggest improvements when tenant AI is configured, but it does not change the gate and neither result asserts that the control is operating effectively.