Evidence by design

Evidence is part of the architecture

Evidence should not be assembled only before an audit or after an incident. Identify evidence while designing each material decision and control. This reveals whether the control is observable, attributable, and reviewable.

Claims, controls, and evidence

Keep three concepts separate:

• A claim states something believed about the system, such as “only approved model versions can run in production.”
• A control enforces or checks the required state, such as admission policy that accepts only signed, allowlisted digests.
• Evidence supports evaluation of the claim and control, such as the signed manifest, policy version, admission decision, deployment digest, and test result.

Evidence alone does not make a control effective, and a control without usable evidence may be difficult to assure.

Evidence qualities

Useful evidence is:

• Attributable: connected to a system, component, actor, and event.
• Versioned: identifies relevant model, artifact, prompt, policy, configuration, and release versions.
• Time-bound: records when an action, state, or evaluation occurred.
• Integrity-protected: inappropriate alteration is prevented or detectable.
• Complete enough: contains the context required to interpret the event.
• Retrievable: can be found within the operational or assurance timeframe.
• Minimized: avoids collecting unnecessary prompts, documents, secrets, or personal data.
• Retained appropriately: follows defined retention, access, deletion, and legal requirements.

Evidence across the lifecycle

Design evidence includes system definitions, diagrams, threat models, architecture decisions, control mappings, and accepted exceptions.

Supply-chain evidence includes source records, licenses, SBOMs, scans, signatures, checksums, approval decisions, and promotion manifests.

Evaluation evidence includes datasets, scenario definitions, metrics, thresholds, failures, reviewer decisions, and approved limitations.

Deployment evidence includes configuration, policy, secret references, artifact digests, change approval, environment identity, and release results.

Operational evidence includes authorized access, policy decisions, blocked actions, retrieval citations, tool executions, health, incidents, and recovery tests.

Retirement evidence includes disabled endpoints, revoked access, data disposition, artifact retention, and ownership closure.

Create an evidence map

Use one entry for each material claim:

Claim or control objective:
System and lifecycle stage:
Evidence artifact or event:
Producer and owner:
Version identifiers:
Storage and access boundary:
Integrity mechanism:
Retention and deletion:
Review trigger and reviewer:
Privacy or sensitivity limitation:

Privacy-safe evidence

Do not treat raw prompts and documents as the default evidence source. Prefer structured events describing the policy decision, content classification, model and policy version, result category, citation identifiers, and outcome. Store sensitive content only when justified, authorized, protected, and time-limited.

Customer-hosted Academy labs should generate evidence locally. No prompt, document, or lab telemetry should be silently exported to SovAIHub.

Verification questions

• Can evidence identify exactly what version ran?
• Does a blocked action create evidence as reliably as an allowed action?
• Can privileged administrators alter both the system and its evidence without detection?
• Are timestamps and identities trustworthy enough for the claim?
• Can reviewers reproduce the evaluation or deployment decision?
• Is the evidence understandable without the original implementer present?

These questions turn evidence from a logging afterthought into an assurance design.