Factor VI
Evidence by Default
Every sensitive activity should produce evidence as a normal consequence of performing work.
Evidence is not created for auditors. It is a first-class architectural output of governed systems, allowing decisions to be explained, posture to be verified and governance to be trusted.
Problem
Governance cannot be verified without evidence.
Too many organisations generate evidence only when an audit approaches: screenshots are collected, spreadsheets completed and approvals reconstructed from emails or chat messages. These artefacts describe what people believe happened rather than what the system actually recorded.
Governed work should produce its own receipts. Every sensitive activity should automatically emit the evidence needed to explain what happened, who performed it, which governance applied and why the outcome was considered acceptable.
Characteristics
Evidence is produced automatically
Evidence is emitted as a normal consequence of performing governed work—not assembled later for an audit.
Evidence explains activities
Evidence should explain what happened, who performed it, when it occurred, which governance applied and why the outcome was permitted.
Evidence is attributable
Evidence should be machine-readable, attributable and tamper-evident so it can be independently verified.
Evidence is non-repudiable
Evidence should be sufficiently trustworthy that participants cannot credibly deny the activity occurred or dispute the governance under which it was performed. Digital signatures, trusted timestamps, provenance and tamper-evident logs all strengthen non-repudiation.
Digital signatures, software attestations, SLSA provenance, transparency logs and trusted timestamps are all mechanisms for strengthening non-repudiation.
Evidence is reusable
The same evidence should support operational dashboards, incident response, compliance reporting and formal audits without being recreated.
Positive examples
Mortgage approval receipt
Approval, decision, approver, policy version and customer identifiers are recorded automatically when the mortgage is approved.
Release provenance
Build provenance, SBOMs and signatures are produced automatically as part of creating a software release.
Payment authorisation log
Every payment records the governance decision, obligations satisfied and resulting transaction identifiers.
AI tool invocation
Each tool invocation records the requesting agent, governing decision, data accessed and resulting actions.
Negative examples
Screenshot Evidence
A compliance team assembles screenshots before an audit to demonstrate that controls are configured correctly. The screenshots cannot explain what actually happened or be regenerated from the governed system.
Spreadsheet Attestations
Control owners complete quarterly spreadsheets declaring systems to be compliant. The evidence is disconnected from the activities it claims to describe.
Chat-Based Approvals
Production releases are approved in a chat channel without generating a durable governance record. Future reviewers cannot determine exactly what was approved or under which governance.
Anti-patterns
Audit Theatre
Evidence is created for auditors instead of being produced by the governed system.
Evidence by Exception
Receipts are generated only for unusual events rather than every sensitive activity.
Unattributable Evidence
Logs and reports cannot be traced back to a specific activity, governance version or responsible identity.
Disposable Evidence
Operational telemetry, provenance and decision logs are discarded once the activity completes, preventing future verification.
Diagram
How do we prove compliance?
Evidence is emitted as the activity happens, then consumed later by auditors and tooling—not reconstructed afterwards.
Discussion
Every sensitive activity should produce two outputs: a business outcome and an evidence receipt.
The business outcome is why the activity was performed—a mortgage is approved, a payment is transferred, a software release is deployed. The evidence receipt explains how that outcome came about by recording the implementation version, governance version, decision, identity, timestamp and resulting outcome. Rather than embedding governance definitions themselves, the receipt references the versions that governed the activity, allowing the complete context to be reconstructed later.
Evidence should therefore be treated as a first-class architectural output rather than an administrative afterthought. It should be emitted automatically by the governed system as the activity occurs, not assembled later for compliance exercises or audits. If evidence has to be reconstructed from screenshots, spreadsheets or chat logs, the system has already failed this principle.
Applying this principle means:
- Treat every sensitive activity as producing an evidence receipt.
- Record immutable references to the Implementation Twin, Governance Twin, governing decision and the business context needed to explain the activity.
- Include sufficient information to establish attribution, integrity and non-repudiation.
- Allow multiple governance functions to consume the same evidence, including operations, security, verification and audit.
This pattern already appears in many successful governance technologies. SLSA provenance, in-toto attestations, software signatures, transparency logs, OpenTelemetry traces and audit logs all generate evidence as part of normal operation. The Governance Factors extend this idea beyond software supply chains to every governed sensitive activity.