Definitions
Terms used in this paper
These definitions establish how the paper uses its core terms before the argument begins.
- Telemetry
- Machine-generated observations produced by security, infrastructure, identity, endpoint, cloud, network, or management systems.
- Provenance
- The traceable origin and processing history of an evidence item.
- Remediation receipt
- A linked record of before state, authorized action, resulting observation, and verification.
- Decision-ready evidence
- Evidence whose required sources, age, conflict state, and provenance satisfy the contract for the decision being made.
1. Security telemetry and audit evidence are not synonyms
Modern environments generate enormous volumes of endpoint, identity, network, cloud, vulnerability, and security-product telemetry. Most of it was created to operate or troubleshoot systems, not to support a later assurance claim. Turning those signals into evidence requires additional structure.
A useful evidence record should preserve what was observed, where it came from, when it was observed, which organization and asset it belongs to, how it was normalized, and whether later processing changed the representation. Without that lineage, a screenshot or dashboard export may look persuasive while remaining difficult to reproduce or challenge.
NIST continuous-monitoring guidance emphasizes ongoing visibility into assets, threats, vulnerabilities, and control effectiveness. Evidence architecture adds the question of whether a downstream reader can trace a conclusion back to the observations that justified it.
2. Provenance is the first control on evidence
Provenance answers where the evidence came from. An endpoint agent observation, identity-provider API response, vulnerability-scanner result, and human attestation are different evidence types. They should not be collapsed into an indistinguishable status before a decision-maker can inspect their origin.
Source identity also matters when systems disagree. If an endpoint reports disk encryption enabled while an inventory system reports the device as unmanaged, the correct response may be to preserve both observations and surface the conflict. A normalization layer should reconcile meaning where it can without destroying evidence of disagreement.
This is especially important in claims, audits, underwriting, and diligence, where the question may later become not merely what the dashboard showed but what information supported the statement at that time.
3. Freshness and completeness determine whether evidence is decision-ready
Evidence can be authentic and still be too old for the decision. A vulnerability scan from last quarter may be useful history but weak support for a statement about today's external exposure. Similarly, a complete endpoint view does not compensate for a missing identity source when the conclusion concerns privileged access.
Decision-ready evidence therefore needs an explicit contract: required sources, acceptable age, conflict rules, and behavior when information is missing. The system should be able to say 'insufficient evidence' instead of forcing every incomplete state into green, yellow, or red.
That restraint improves both human and machine reasoning. A model can distinguish uncertainty caused by the environment from uncertainty caused by missing observation. Those are different problems and call for different interventions.
- Source observation
Identify the source, organization, asset, time, and observed condition.
- Meaning preserved
Record normalization and retain the original context and disagreements.
- Quality checked
Assess freshness and completeness for the decision being made.
- Reviewable conclusion
Keep the claim traceable to the observations that support it.
If a required source is missing, stale, or conflicting, preserve that limitation instead of promoting the conclusion to certainty.
4. Remediation receipts connect evidence to action
Evidence becomes more powerful when it spans a change. The before state establishes the condition. The authorized action records what was attempted. The resulting observation determines whether the environment changed. Later re-observation helps establish whether the state persisted.
This pattern prevents a common closure error: treating a command response or ticket status as proof that the technical condition was corrected. The strongest receipt comes from observing the target environment after the action through an appropriate source.
For regulated and insured organizations, this also improves chronology. A later reviewer can see not only that a finding existed, but when it was known, what response was authorized, whether the response succeeded, and what evidence supported closure.
5. Evidence systems should preserve uncertainty rather than manufacture certainty
No evidence architecture removes all ambiguity. Sources fail, clocks drift, APIs change, assets disappear, and controls have meanings that exceed any single telemetry field. The design goal should be to preserve enough context that uncertainty remains visible and manageable.
This is why evidence quality deserves its own representation. A conclusion based on complete, fresh, mutually consistent sources is different from the same apparent conclusion based on partial and stale inputs. Downstream users should be able to tell the difference.
The result is less flashy than a universal score, but more useful: a durable chain from observation to decision to action to verified outcome.
Evidence base
Sources and notes
External foundations are kept distinct from VitalSec implementation notes so readers can see what supports the argument independently and what documents the platform implementation.
External foundations and sources
VitalSec implementation notes
These links document how the argument is implemented or described inside VitalSec. They are not offered as independent validation of the paper's thesis.
