Skip to content

Evidence

Evidence is the proof layer of Modulos. It can be a policy, screenshot, export, log sample, contract, or test output that supports a control claim.

What this is

Evidence turns “we did it” into “we can prove it”.

In Modulos, evidence is designed for two things:

  • precision: evidence should support a specific claim, not a vague control as a whole
  • reuse: one evidence item can support multiple controls without losing context

For the full flow, see Governance Operating Model.

Where in Modulos

  • Project → Evidence to manage the evidence library, upload files, and find what is missing
  • Control detail → components to attach evidence directly to the claim it supports

Who can do what

Permissions

  • Most project members can view evidence linked to controls they can access.
  • Editors typically upload evidence and attach it to control components.
  • Project Owners can manage evidence at the project level and resolve permission blockers.
  • Evidence is treated as an audit artifact and becomes locked once it supports executed controls.
Evidence manager showing the evidence library, filters, and an evidence detail view with associations and download actions.
The Evidence library helps you manage proof artifacts and trace where they are used across controls. UI shown in light mode.
  1. 1
    Filters and search
    Find evidence by name and type to reuse artifacts intentionally.
  2. 2
    New evidence
    Upload a new evidence item into the project library.
  3. 3
    Evidence detail
    Open an item to review metadata, associations, and the description.
  4. 4
    Associations
    See which controls (and claims) this artifact supports.
  5. 5
    Download
    Exports typically bundle key controls plus their referenced evidence files.

How it works

Evidence is a file-like object with metadata

Evidence is stored as a file-like object with metadata (name, description, URI, file type, size, and optional checksums). Evidence items live in a project-level library so they can be reused across controls.

Evidence attaches to components, not controls

Evidence links to control components (sub-claims), not directly to a control. This makes audits easier:

  • reviewers can see which evidence supports which claim
  • evidence reuse stays meaningful because the context is explicit

The diagram below shows evidence linking to components (claims), including reuse across multiple controls.

Locking preserves audit integrity

Evidence is editable while it supports work that is still in progress. Once evidence supports executed controls, it becomes locked.

This prevents silent “after-the-fact” changes to audit artifacts.

The diagram below shows how evidence typically transitions from editable to locked when it supports executed controls.

How to use it

1

Start from a control claim

Identify the component (claim) that needs proof

2

Upload evidence

Add the file to the project evidence library with a clear name and description

3

Attach to the component

Link the evidence to the specific component it supports

4

Reuse deliberately

Reuse evidence across controls only when the claim is truly the same

5

Preserve integrity

Expect evidence to lock once it supports executed controls

Important considerations

  • Evidence should be specific. “Policy.pdf” is not helpful; “Access control policy v3.2 (approved 2026-01-15)” is.
  • Prefer primary artifacts (logs, configs, contracts, test outputs) over screenshots of primary artifacts.
  • If you rely on screenshots, annotate them and keep them tied to a specific claim and date.