An evidence object contains:
collected_at_utc = 2026-09-22T01:00:00Z
A few seconds later, the object is hashed with SHA256.
The hash verifies.
It is tempting to read this as evidence that the system was observed at 01:00 UTC.
But the timestamp may only tell us what the collector’s clock said.
If that clock was wrong, the timestamp can be wrong. If the object was created later with a backdated timestamp and then hashed, the hash can still verify.
Nothing is wrong with SHA256.
We are asking it to prove something it does not prove.
A timestamp records a time claim. It does not by itself prove when the evidence existed.
Hash integrity is not time assurance
The useful integrity boundary is:
hash verifies
=> stored bytes match recorded digest
It is not:
hash verifies
=> embedded timestamp is historically true
A valid hash can protect a false timestamp just as effectively as a correct one.
This matters because evidence packages often put these fields next to each other:
collected_at_utc
sealed_at_utc
sha256
That structure looks strong.
But collected_at_utc may still be an assertion from the same process that created the evidence.
Integrity and time assurance are different problems.
There is more than one time in the evidence chain
An evidence pipeline may contain several different time statements:
source event time
collection time
seal time
receipt time
trusted attestation time
They answer different questions.
A source event time says when the source claims something happened.
A collection time says when the collector claims it observed the source.
A seal time says when the evidence packager claims it created the digest.
Those values can still be useful. Their provenance just needs to remain visible.
For example:
collection_time:
value_utc: 2026-09-22T01:00:00Z
asserted_by: synthetic-readonly-collector
clock_source_ref: collector-host-system-clock
assurance: collector_asserted
The important part is not only the UTC value.
It is also:
assurance = collector_asserted
An independent receipt creates a different claim
Suppose the collector claims the evidence was collected at 01:00.
A separate receiver later records the same evidence digest at 01:03.
Under the assumptions of that receiving system, this can support:
this evidence digest existed no later than 01:03
It still does not prove:
the target was observed at exactly 01:00
Those are different claims.
The receipt strengthens time provenance because the evidence crossed a separate recording boundary. But it is still not the same as trusted timestamping.
The current CodeYourCompliance model therefore keeps three states separate:
collector_asserted
independent_receipt
trusted_timestamp
They should not become different labels for the same level of assurance.
Freshness also depends on the time claim
Consider a deterministic freshness rule:
evaluation_time - collected_at <= allowed_age
OPA can calculate this correctly every time.
But if collected_at came only from the collector clock, the result still depends on that asserted time.
So two questions remain separate:
Was the freshness calculation correct?
and:
How much assurance do we have in the collection time?
A deterministic policy result answers the first.
It does not automatically answer the second.
Replay must preserve the original time semantics
The same boundary applies later during evidence replay.
If the original assessment used collector-asserted time, replay should not silently upgrade that timestamp into independently verified time simply because the evidence hash still matches.
The historical chain may have been:
observation
-> collector-asserted time
-> evidence bytes
-> integrity seal
-> policy evaluation
If an independent receipt existed, that relationship should survive replay.
If trusted timestamping existed, its attestation should remain separately bound to the evidence digest.
Replay should preserve not only the evidence bytes and policy version, but also what was actually known about the evidence at the time.
This does not mean every pipeline needs a timestamp authority
The new Evidence Time Provenance Contract deliberately stops before that conclusion.
The accompanying synthetic examples compare only:
collector-asserted collection and seal times
the same modeled evidence digest with a separately recorded receipt time
They do not implement trusted timestamping.
They do not validate NTP synchronization, host clock correctness, receiver authentication, or RFC 3161 Time-Stamp Protocol timestamp tokens.
The boundary is narrower.
If the system only has a collector-asserted timestamp, record it as collector-asserted.
If another system creates a separate time boundary, preserve that relationship.
If trusted timestamping does not exist, do not imply that it does.
MAS TRM-inspired means engineering interpretation
This is not a claim that the MAS Technology Risk Management Guidelines prescribe this time-provenance structure or any particular timestamping mechanism.
The engineering interpretation is simpler.
If evidence supports a point-in-time technical claim, the pipeline should preserve not only the timestamp value but also where that time came from and what assurance it provides.
Otherwise:
2026-09-22T01:00:00Z
looks precise while hiding the more important question:
Who said it was 01:00?
Public reference artifacts
Origin and scope
CodeYourCompliance
Website: Compliance Evidence Automation | CodeYourCompliance
GitHub: https://github.com/codeyourcompliance
CodeYourCompliance explores compliance automation, replayable audit evidence, read-only evidence collection, policy-as-code, and evidence packages.
Attribution is requested for forks, references, adaptations and technical discussions.
MAS TRM-inspired means engineering interpretation. This project does not provide legal, regulatory, audit, certification or compliance advice.