Suppose an evidence package contains a TLS certificate expiry date, a timestamp and a valid integrity hash.
Six months later, someone reviews the assessment and asks how that expiry date was collected.
Was it read directly from the certificate file? Parsed from command output? Returned by an application API?
If the evidence package does not say, the value may still be intact, but part of its history is missing.
The collector is not just transport between a system and an evidence file. It is part of the chain that produced the observation.
The same field can have different origins
Take a field such as:
certificate_not_after
One collector might read a certificate file directly. Another might call openssl and parse stdout. Another might query an application endpoint.
The final value could be identical in all three cases.
That does not make the collection paths equivalent.
Each method depends on a different source and different interpretation logic. If only the normalized field is retained, those differences disappear.
This becomes more important when results change.
If yesterday’s collector reported one value and today’s collector reports another, the first question is not necessarily whether the target changed.
The collection path may have changed instead.
Record the collector with the observation
The current CodeYourCompliance evidence pattern records collector metadata with the observation:
{
"collector": {
"name": "ansible-readonly-tls-collector",
"version": "0.1.0",
"mode": "read_only",
"method": "remote_command_and_file_read",
"changed_target_system": false
}
}The collector name identifies what produced the observation.
The version identifies which implementation was running.
The method records how the state was obtained.
The read-only fields record the intended collection boundary and whether collection changed the target.
The public Collector Provenance Contract extends this with fields such as parser version and source reference.
None of these fields proves that the collector was correct.
They make the production path inspectable.
Read-only does not solve provenance
I have previously treated read-only collection as an audit boundary.
That boundary still matters.
A collector that repairs a system while collecting evidence mixes observation with remediation. Once that happens, it becomes harder to tell whether the recorded state existed before the collector touched the target.
But a collector can be read-only and still produce misleading evidence.
A parser can be wrong.
A configuration path can change.
A missing value can become false when it should remain unknown.
None of those problems requires a write operation.
Two questions therefore remain separate:
Did collection change the target?
How was the observation produced?
The first is about collection restraint.
The second is about provenance.
Collector changes can look like system changes
The public collector provenance example makes this problem explicit.
It contains two synthetic evidence objects for the same service and the same synthetic target-state identifier.
The first uses collector version 0.1.0, reads the configured certificate file and records:
not_after = 2026-09-30T00:00:00Z
The second uses collector version 0.2.0, performs a runtime TLS handshake and records:
not_after = 2026-10-15T00:00:00Z
The target-state identifier is deliberately held constant by the scenario.
The collector version, collection method, parser version and source reference change.
The example does not establish which observation is correct.
It establishes a narrower boundary:
observation difference
+ collector difference
!= automatic target drift
Before a difference is classified as system drift, the collection path needs to remain visible.
This is also why retaining only the final PASS or FAIL is weak. As discussed in Invalid Evidence Is Not a Failed Control, a result only has meaning if the pipeline preserves how that result was reached.
Normalization has the same problem
Raw collection is often only the first step.
A command returns text. A parser extracts values. A normalization layer converts them into stable fields. A policy engine evaluates those fields.
The useful trace is closer to:
control result
→ normalized fact
→ collected observation
→ collector + parser
→ source reference
→ source system
Not every implementation detail belongs in the final report.
But the evidence package should retain enough metadata to identify which collection and transformation path produced the evaluated fact.
Otherwise the policy side is visible while the collection side remains opaque.
Provenance is not proof of correctness
There is another boundary worth keeping clear.
Recording collector identity, version and method does not make the collector trustworthy.
A known collector can contain a bug.
A read_only attribute can be wrong.
A documented source can still be unsuitable for the control being evaluated.
Collector metadata provides a trail to inspect.
It does not validate that trail.
Structured provenance improves traceability. It does not turn implementation claims into facts.
MAS TRM-inspired means engineering interpretation
This is not a claim that MAS TRM requires Ansible, collector version fields, parser metadata or this evidence model.
The engineering interpretation is narrower.
If system state is being turned into evidence for later control assessment, the collection path should not disappear once the normalized value has been produced.
A reviewer should be able to determine what collected the observation, how it was collected, what source was used and which implementation version was involved.
If that information is missing, part of the evidence history is missing too.
Public reference artifacts
The collector provenance boundary described here is implemented as a public engineering artifact in the codeyourcompliance/evidence-validation-pipeline repository.
Main references:
The contract defines the provenance fields needed to keep collector identity, version, method, parser and source attached to an observation.
The synthetic example shows why an observation difference should not automatically be classified as target-state drift when the collector also changed.
The repository does not yet cryptographically bind collector implementation digests to evidence objects. It also does not implement automated collector-version equivalence testing.
Those remain separate implementation steps.
Origin and scope
CodeYourCompliance
Website:
GitHub: https://github.com/codeyourcompliance
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.