An Integration Is Not an Evidence Contract
Moving compliance data is not the same as preserving audit meaning
A compliance platform connects to a source system.
Authentication succeeds.
Configuration data appears in the dashboard.
The control status turns green.
Then the reviewer asks:
Which source produced this value?
Which collector version retrieved it?
When was it observed?
Was the full target scope reached?
Was the data changed during normalization?
Which policy evaluated it?
The integration moved the data.
It did not preserve the answers.
That is the boundary.
Integration = transport.
Evidence contract = audit meaning.
What an Integration Proves
A working integration may prove that:
credentials were accepted
an endpoint was reachable
a payload was returned
field mapping completed
data reached the destination
That is useful operational evidence.
It does not automatically prove that the transported data is valid audit evidence.
The integration may still omit:
source context
expected collection scope
failed targets
collector identity and version
collection timestamp
transformation history
integrity status
evidence freshness
applicable policy version
Compliance evidence automation is not data movement.
It means collecting evidence from source systems, preserving provenance, validating integrity, evaluating policy, and producing a reviewable evidence package.
Missing Data Must Survive the Integration
Suppose a collector is expected to inspect 100 systems.
It reaches 94.
The integration writes 94 successful records into the compliance platform.
The dashboard reports that all received records passed.
Technically, the integration worked.
The evidence package is incomplete.
The correct state is:
expected targets: 100
observed targets: 94
failed collection: 6
It is not:
evaluated environment: compliant
The six missing systems did not fail the control.
They did not pass it either.
They were not observed.
missing evidence != control failure
missing evidence != control pass
missing evidence = unresolved evidence state
If that distinction disappears during transport, the evidence has already lost part of its value.
What an Evidence Contract Preserves
An evidence contract defines the minimum structure that must survive collection, transport, normalization, evaluation, and reporting.
evidence_contract:
source_system:
collector:
collector_version:
collection_method:
timestamp_utc:
evidence_type:
evidence_layer:
integrity_hash:
validation_status:
policy_input_ref:Each field answers a different audit question.
source_systemidentifies where the evidence originated.
collectorandcollector_versionidentify what process observed the source.
collection_methoddistinguishes read-only observation from collection that may have changed the assessed system.
timestamp_utcrecords when the state was observed.
evidence_typedefines what kind of object was collected.
evidence_layerseparates raw evidence, normalized facts, derived facts, policy results, and audit narratives.
integrity_hashsupports detection of post-collection mutation.
validation_statuspreserves whether the evidence is valid, stale, missing, tampered, unknown, or not machine-verifiable.
policy_input_reflinks the evidence to the rule evaluation that consumed it.
Without these fields, the destination may contain data.
It does not yet contain a replayable evidence object.
One Green Status Is Not Enough
A common implementation error is using one status field for the entire pipeline:
{
"status": "success"
}What succeeded?
The API request?
The collection?
The schema validation?
The integrity check?
The policy evaluation?
The control?
These outcomes should remain separate.
transport_status: success
collection_status: partial
schema_status: valid
integrity_status: verified
freshness_status: stale
policy_status: not_evaluated
control_status: unknownA single green status is easy to display.
It is difficult to audit.
Normalization Changes Meaning
Integrations often rename fields, convert timestamps, flatten objects, infer Boolean values, and discard unsupported data.
These transformations may be necessary.
They are not neutral.
Suppose the source returns:
{
"certificate_not_after": "2026-08-01T00:00:00Z"
}The integration writes:
{
"certificate_valid": true
}The second value is not raw evidence.
It is a derived fact.
The system should preserve the source value, transformation rule, evaluation time, and derived result.
Otherwise the integration replaces evidence with an unexplained conclusion.
OPA Cannot Repair Weak Evidence
OPA can evaluate a defined input against a defined policy.
It cannot determine whether the input was collected from the correct source, whether the target scope was complete, or whether the evidence was modified before evaluation.
A reproducible rule result can still be based on weak evidence.
The policy engine is not the point.
The audit problem starts earlier.
The evidence contract defines what the evaluator is allowed to treat as policy input.
Different Failures Need Different Outcomes
The pipeline should distinguish
transport failure
collection failure
invalid evidence
policy evaluation failure
control failure
An API timeout is not automatically non-compliance.
The defensible chain is:
API timeout
-> collection incomplete
-> evidence missing
-> control not evaluated
-> review or escalation required
Control failure should be recorded only when valid evidence was evaluated and the required condition was not met.
Failure states must survive the integration.
Technical companion
An evidence contract boundary note and two synthetic integration examples are available in the CodeYourCompliance evidence-validation-pipeline repository.
Evidence contract boundary:
Integration without an evidence contract:
Integration with an evidence contract:
These examples do not implement a complete integration governance or evidence integrity model.
They show one boundary:
Successful transport does not establish evidence validity.
Boundary
This material is for evidence structuring, integration design review, and technical review preparation.
It does not provide legal, regulatory, audit, certification, compliance, procurement, or implementation advice.
The goal is not to prove MAS TRM compliance.
The goal is to make the transport-versus-evidence boundary visible before synchronized data becomes accepted audit evidence.
Origin
CodeYourCompliance
Website: https://www.codeyourcompliance.com/
GitHub: https://github.com/codeyourcompliance
Attribution is requested for forks, references, adaptations, and discussions.
Related reading
Can Your Audit Evidence Survive Replay?
What a MAS TRM Checklist Cannot Prove