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.

12345

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.

Evidence linking

One evidence file, attached to component-level claims, reused across two controls.

Evidence

model_validation.pdfUploaded 2025-12-15

Reusable

Control components

CTRL-001 group

Component A

Component B

Component C

CTRL-002 group

Component D

Component E

Controls

CTRL-001Model validation

CTRL-002Data quality

1 evidence · 3 linked components · 2 controlsAttach evidence to the smallest meaningful claim — the same file then satisfies parts of every control whose components it covers.

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.

Evidence locking

Evidence editability tracks the control's review state.

Step 1

Not executed

Editable

Evidence can be added and modified.

Step 2

Executed

Locked

Review approved, evidence is immutable.

Step 3

Reopened

Editable

Changes tracked for traceability.

Locking is about audit integrity, not policing — the dashed arc shows that reopening is allowed and recorded, not blocked.

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.

Related pages

Governance Operating Model

How evidence connects to controls and reviews

Controls

Control components are where evidence attaches

Reports & Exports

Generate point-in-time snapshots for audits