Evidence Semantics & Taxonomy
Formal classification of evidence types, confidence implications, and how the platform handles the absence of evidence.
This section is intended for: Technical Team, Auditor, Management, End User. Unauthorised access is restricted.
1. Purpose
Compliance evidence is not binary. Different types of evidence carry different levels of confidence, and the absence of evidence is itself a signal that must be formally handled. This document defines how Govula classifies and interprets evidence.
2. Evidence Types
Govula recognises the following evidence types, each with distinct characteristics and typical applications.
| Type | Description | Typical Use |
|---|---|---|
| document | Uploaded files, policies, procedures | Policy attestation, procedure documentation |
| link | URLs to external systems or resources | Third-party attestation, external references |
| screenshot | Visual captures of system state | Configuration verification, UI evidence |
| api | Programmatic evidence from integrations | Automated compliance checks, signal ingestion |
3. Evidence Sources
The origin of evidence determines its baseline trust level and how it should be interpreted during assessments.
| Source | Description | Trust Implications |
|---|---|---|
| system | Generated by Govula or integrated systems | Highest confidence — automated, repeatable |
| human | Uploaded or attested by a person | Moderate confidence — requires freshness tracking |
| third_party | From external integrations or vendors | Variable confidence — depends on source reliability |
4. Trust Levels
Each piece of evidence is assigned a trust level that reflects its quality, currency, and verification status.
Low Confidence
Evidence exists but has known quality issues (stale, unverified, or incomplete).
Moderate Confidence
Evidence is present and reasonably current but not independently verified.
High Confidence
Evidence is current, verified, and from a reliable source.
Independently Verified
Evidence has been independently verified and confirmed by an authorised reviewer.
5. Evidence Freshness
Evidence has a validUntil date. Evidence past its validity date is marked STALE.
- Stale evidence is NOT deleted — it remains in the record but reduces the Evidence Quality Index (EQI)
- Reports generated with stale evidence include explicit freshness warnings
6. Handling Absence of Evidence
The absence of evidence for a control is NOT treated as “not applicable.”
- Missing evidence results in a MISSING status for the control
- Controls with missing evidence are flagged in all reports
- SoA assessments explicitly report on evidence coverage gaps
- The platform does not assume compliance in the absence of evidence
7. Evidence in Reports
All audit-grade documents include evidence classification information.
- Reports must declare their evidence sources, data point counts, and assessment basis as part of the canonical document structure
- Evidence lineage is preserved — each report references the specific evidence versions used
Core Principle
The absence of evidence is never interpreted as compliance. Missing evidence is explicitly surfaced in all assessments and reports.