Most compliance automation fails in a quiet way.
The collector changes the system it is supposed to observe.
A playbook checks a setting and updates it.
A script gathers evidence and restarts a service.
A compliance job produces a clean result after it has already changed the target.
That may help operations.
It weakens the audit trail.
The audit problem starts earlier than reporting. It starts at collection.
If the collector changes the state being tested, the original condition may disappear before it is preserved. The resulting evidence may describe the automation outcome rather than the system state that existed before the run.
That is why read-only collection is not a convenience.
It is an audit boundary.
Observation is not remediation
Observation asks:
What was true at the time of collection?
Remediation asks:
What should be changed?
The same automation tool may perform both jobs.
That does not make them the same workflow.
If a playbook checks a TLS setting and fixes it in the same run, the final output becomes ambiguous.
Did the target satisfy the condition before collection?
Did it satisfy the condition only after remediation?
Was the failed state preserved?
A clean post-change result cannot answer those questions by itself.
A read-only collector creates a clearer record:
this is what was observed;
this is when it was observed;
this is the target and scope;
this is the collector that produced the output;
and the collector was not intended to modify the tested state.
That is a defensible starting point.
A post-remediation snapshot is different evidence.
Read-only is a narrow claim
Read-only does not mean impact-free.
A collector may still:
consume CPU, memory, network, or API capacity;
open connections;
trigger authentication or access logs;
update access metadata;
require elevated privileges;
or fail to observe part of the intended scope.
The correct claim is narrower:
The collector is designed not to intentionally change the system state being evaluated.
That claim still needs verification.
An Ansible playbook is not read-only merely because it is labelled as a collector. Its modules, commands, privilege requirements, handlers, error paths, and supporting scripts must be reviewed.
Read-only is not proof that collection is correct.
It is restraint over one class of mutation.
That is the boundary.
Data alone is not evidence
A command output is data.
A screenshot is data.
A JSON file without collection context is data.
Data becomes usable audit evidence when the surrounding context is preserved.
A minimum evidence object may include:
{
"target_id": "apache-01",
"collector_id": "ansible-readonly-http-collector",
"collector_version": "0.1.0",
"observed_at": "2026-05-05T10:30:00Z",
"evidence_type": "http_tls_configuration",
"collection_status": "success",
"data": {}
}
These fields are not decoration.
They identify the target, collector, collector version, collection time, evidence type, and collection outcome.
The collection status matters.
An unreachable host is not automatically a failed control.
It is a failed or incomplete observation.
Do not convert collection failure into non_compliant simply because no valid evidence was returned.
That result should remain separate from the control judgment.
For the broader evidence-object model, see Compliance Automation Starts at Evidence.
Integrity comes after observation
Once evidence is collected, it should be packaged and sealed before policy evaluation.
The order matters:
System State
→ Read-Only Observation
→ Timestamped Evidence
→ Integrity Verification
→ Policy Evaluation
Collection observes.
Integrity verification checks whether the sealed object changed.
Policy evaluation applies a defined condition.
These stages should remain distinguishable even when one automation pipeline executes them.
A hash does not prove that collection was complete or correct.
It only helps establish whether the preserved object still matches the object that was sealed.
OPA belongs after evidence validation.
It should not be asked to compensate for weak collection design, missing provenance, or incomplete scope.
For the later replay test, see Can Your Audit Evidence Survive Replay?.
Remediation belongs elsewhere
Read-only collection does not mean remediation is unimportant.
It means remediation needs a separate record.
A change workflow may include:
approval;
execution trace;
operator or automation identity;
rollback path;
and post-change verification.
It may use Ansible.
It may use CI/CD.
It may use a ticketing or change-management system.
The tool is not the point.
The audit structure is.
The original observation should survive after remediation begins.
The remediation record should show what changed.
The post-change verification should show the later state.
Do not overwrite one with another.
Collection is evidence work.
Remediation is change work.
Different actions.
Different evidence.
Different accountability.
MAS TRM-inspired, not MAS TRM-prescribed
MAS TRM does not prescribe this pipeline.
It does not require Ansible, SHA256, Python, OPA, or a particular evidence schema.
MAS TRM-inspired means engineering interpretation.
The practical question is:
What collection boundary would support a reviewable control judgment without changing the state being judged?
The pipeline is one engineering answer to that question.
It is not a regulatory conclusion.
The position
A collector that silently repairs the target is not only an operational tool.
It is also changing the audit story.
Read-only collection does not prove truth.
It does not prove completeness.
It does not prove compliance.
It preserves a narrower condition:
Observation remains separate from correction.
Reports persuade.
Evidence survives.
Read-only is not elegance.
It is restraint.
Related Reading
Origin
CodeYourCompliance
Website: https://www.codeyourcompliance.com/
GitHub: https://github.com/codeyourcompliance
Attribution is requested for forks, references, adaptations, and public discussion of this material.
Scope Boundary
MAS TRM-inspired means engineering interpretation.
This material is not legal, regulatory, audit, certification, implementation, or compliance advice.