A control requires two pieces of evidence.
The first is present. Its schema is valid, integrity is verified, freshness is acceptable, and the required provenance is available.
The second is missing.
A pipeline that checks only the evidence it received may still continue to control evaluation. Every object in front of it looks valid, but the proof set is incomplete.
Nothing is wrong with the first evidence object. There is simply not enough evidence to support the declared control claim.
That is a different problem from invalid evidence.
Admissibility applies to an evidence object
The evidence-admissibility gate answers whether an individual object can be used.
For example:
schema = valid
integrity = verified
freshness = fresh
provenance = present
Those checks say something about the quality of that object.
They do not establish that every evidence requirement for the control has been satisfied.
A control can therefore reach this state:
present evidence = admissible
required evidence set = incomplete
control decision = blocked
control status = unknown
The missing evidence should remain missing. It should not be converted into either a pass or a failure.
This is the boundary introduced in the latest CodeYourCompliance artifact: object-level admissibility and evidence-set sufficiency are separate checks.
A simple TLS example
The public Control-to-Evidence Mapping Example uses a synthetic TLS control.
The declared control requires two evidence types:
tls_certificate_state
tls_runtime_protocol_state
In the complete scenario, both requirements are modeled as satisfied.
The resulting state is:
evidence_set_status = complete
policy_evaluation_allowed = true
control_status = not_evaluated
The example deliberately stops before control evaluation. A complete evidence set means the downstream policy is allowed to run. It does not mean the control has passed.
The incomplete scenario contains certificate-state evidence but no runtime protocol-state evidence:
evidence_set_status = incomplete
policy_evaluation_allowed = false
control_status = unknown
The certificate evidence remains usable. The absent protocol evidence does not become a failed control condition.
The examples are synthetic. They do not execute an admissibility gate, sufficiency gate, downstream control policy, or OPA. The recorded states are modeled scenario assertions used to make the boundary inspectable.
The control needs an explicit evidence map
The Control-to-Evidence Mapping Contract records which evidence requirements belong to a control before policy evaluation starts.
A minimal structure includes:
control_evidence_mapping:
mapping_id:
mapping_version:
control_id:
control_version:
control_claim:
evaluation_rule:
evidence_requirements:
- requirement_id:
requirement_version:
required:
evidence_type:
evidence_layer:
minimum_objects:
scope_ref:
admissibility_required:
The useful part is the relationship between the control claim and its required proof inputs.
For each requirement, the assessment should be able to show what evidence type was expected, which scope it applied to, whether admissibility was required, and whether the requirement was actually satisfied.
Without that mapping, a pipeline can easily confuse:
everything received was valid
with:
everything required was received
Those statements are not equivalent.
Missing evidence should stay unresolved
Missing evidence is easy to mishandle because a binary control model wants a binary answer.
Consider an API timeout while collecting one required evidence type.
The timeout does not establish that the control condition failed. It establishes that the required observation was not obtained.
The state should remain explicit:
required evidence missing
-> evidence set incomplete
-> control evaluation blocked
-> control status unknown
This keeps collection failure separate from control failure.
The same applies when a source is unreachable, an expected object is absent, or the declared scope was only partially observed. Those conditions may require recollection or review, but they are not themselves proof that the target violated the control.
The mapping is part of replay history
The evidence map can change over time.
Suppose mapping version 0.1.0 requires certificate-state evidence only.
A later version adds runtime protocol-state evidence.
If an old assessment is replayed using the new mapping, it is being evaluated against a different proof requirement.
The historical path therefore includes more than evidence and policy:
control claim
-> evidence requirement map
-> admissible evidence set
-> policy input
-> policy evaluation
-> control result
Preserving the historical policy while discarding the historical evidence map still changes the question being replayed.
This is similar to policy versioning, but it occurs earlier in the pipeline. The evidence map determines what must exist before the policy is allowed to run.
Sufficiency still does not prove control correctness
A complete evidence set only proves completeness against the declared mapping.
The mapping itself may still be wrong.
It may omit an important evidence type. The declared scope may be too narrow. A requirement may point to an inappropriate source. A technically valid evidence object may not be the right proof for the claim being assessed.
The mapping therefore answers a limited question:
Did the declared evidence requirements get satisfied?
It does not establish that those were the correct requirements.
That remains a control-design and review problem.
Where this sits in the pipeline
With this addition, the current evidence path becomes:
source system
-> collector
-> raw observation
-> transformation
-> normalized fact
-> evidence admissibility
-> evidence sufficiency
-> policy input
-> policy evaluation
-> control result
Previous artifacts dealt with whether evidence survives collection, transformation and evaluation with enough provenance to be replayed.
This artifact adds a different check before policy execution: whether the declared proof set is actually complete.
A valid evidence object can still be insufficient for the claim being made.
MAS TRM-inspired means engineering interpretation
This is not a claim that MAS TRM prescribes this mapping schema, the TLS example, an evidence-sufficiency gate, or OPA.
The engineering interpretation is narrower.
Before producing a control conclusion, the evidence package should preserve which proof inputs were required, which were present, which were admissible, and which remained missing.
Otherwise a valid piece of evidence can be used to support a conclusion that required more proof than the pipeline collected.
Public reference artifacts
The implementation references are available in the public CodeYourCompliance evidence-validation-pipeline repository:
The current artifact models evidence sufficiency through a contract and synthetic examples.
It does not yet implement automatic evidence-set assembly, repo-wide evidence-requirement schema enforcement, control-catalog version governance, or cryptographic binding of a mapping artifact to an assessment result.
Origin and scope
CodeYourCompliance
Website: Compliance Evidence Automation | CodeYourCompliance
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.