Compliance Automation Starts at Evidence
Why MAS TRM-Inspired Engineering Starts With Evidence, Not Narratives
Most audit packs are built after the fact.
That is the weakness.
The screenshot is taken after the audit request arrives. The log export is prepared after the system has moved on. The control owner writes how the process is supposed to work.
The report becomes coherent.
Coherence is not proof.
A clean audit pack can still be built on weak evidence.
That is the problem compliance automation must solve first.
The report is too late
A report is downstream.
It cannot rescue stale evidence. It cannot repair a missing timestamp. It cannot prove that a configuration remained unchanged after collection.
Most automation starts at the wrong layer.
It generates summaries.
It fills templates.
It writes control narratives.
That saves labour.
It does not harden evidence.
Evidence needs provenance
Data is not evidence until it can be traced.
An evidence object should tell us what was observed, when it was observed, where it came from, how it was collected, whether it changed after collection, and which control expectation it supports.
Without that, the audit trail is soft.
Soft evidence creates soft conclusions.
Collection is not correction
The collector should not fix the system.
If collection changes the target, the failed state may disappear before it is recorded. Operations may like that. Audit should not.
Read-only collection is not a tooling preference.
It is restraint.
Pull the configuration. Timestamp it. Seal it. Evaluate it. Remediate later.
Observation and remediation are different jobs.
Integrity comes before judgment
A hash does not prove compliance.
It proves whether the evidence changed after collection.
That is a narrow claim. It is also a useful one.
If integrity verification fails, the audit path should stop. OPA should not evaluate evidence that has already failed its own trust boundary.
Bad evidence should not produce a clean result.
OPA is not the system
OPA is a policy evaluator.
Not a collector.
Not a repair tool.
Not an audit writer.
Its job is narrow: take verified evidence and decide whether the observed state violates a defined control condition.
That narrowness is the point.
Policy should stay deterministic. Narrative can come later.
TLS shows the boundary
Take an Apache HTTPS service.
The weak audit asks whether SSL is enabled.
The stronger audit asks when the certificate was observed, when it expires, which signature algorithm was used, whether the evidence was sealed, and whether that sealed evidence was verified before policy evaluation.
The first question checks a claim.
The second checks proof.
A certificate expiring within 48 hours is not a cosmetic issue. It is a control weakness.
The audit narrative should stay tied to evidence:
Based on verified TLS evidence collected at a specific time, the service was operating with a certificate approaching expiry within the defined threshold. This weakens assurance over secure communications and does not align with MAS TRM-inspired expectations for maintaining effective cryptographic controls.
No legal conclusion.
No remediation theatre.
Just evidence, expectation, and judgment.
MAS TRM-inspired means engineering interpretation
MAS TRM is the context here, not legal advice.
The engineering task is not to rewrite regulatory language into softer prose. It is to turn control expectations into evidence structures.
A control cannot remain a paragraph forever.
It needs a schema.
It needs a collector.
It needs a timestamp.
It needs an integrity check.
It needs a policy rule.
It needs an audit narrative.
That is where the machine boundary starts.
The position
Compliance automation is not report automation.
Report automation makes audit packs faster.
Evidence automation makes control claims harder to fake, harder to mutate, and easier to replay.
That is the useful distinction.
Reports persuade.
Evidence survives.
Further reading
This article is part of the CodeYourCompliance evidence automation series.
Week 1: Compliance Is Not Documentation. It Is Evidence That Can Be Replayed.
Public technical work: CodeYourCompliance on GitHub
CodeYourCompliance explores MAS TRM-inspired compliance automation, replayable evidence, read-only collection, timestamped evidence, integrity verification, policy-as-code, and audit narratives.
MAS TRM-inspired means engineering interpretation. It is not legal, regulatory, audit, or certification advice.