Compliance Condition Evaluation

Compliance condition evaluation is the defined, repeatable procedure that converts a subject, a set of applicable requirements, and a current record into a compliance condition.

It is an act, performed at a specific moment, not a standing state. Nothing is evaluated in advance and held for later reuse; the act runs whenever a condition is needed and consumes the freshest inputs available at that instant.

The output of the act is the condition described in route 3. This route is concerned only with the act that produces it — the discipline that makes the output trustworthy rather than a guess dressed up as a finding.

• A resolvable subject — exactly one registered QR identity, unambiguously identified.
• A determined set of applicable requirements — governed upstream, not authored by the evaluation act.
• The identity's current record — registration state, certification state, jurisdiction assignment, expiry position, flags, and relevant history.
• An evaluation time — the instant the act runs, which is stamped onto the resulting condition.

If any of these four is missing or unresolvable, the act cannot complete as a definite pass or fail. It either halts before comparison — an unresolved subject — or completes with an exception recorded against the specific requirement that could not be checked.

Evaluation is deliberately mechanical, in a fixed order, so that identical inputs always yield an identical finding and so that a reviewer can retrace the act step by step.

1. 1Resolve the subjectConfirm the scan or request maps to exactly one registered identity before any comparison begins.
2. 2Resolve applicabilityDetermine which governed requirements apply, given jurisdiction, issuer, object type and certification scope, before reading requirement detail.
3. 3Read the current recordPull the identity's present facts from the operational record at evaluation time — never a cached or assumed value.
4. 4Compare requirement by requirementEvaluate each applicable requirement individually, so the finding can name exactly what was and was not satisfied.
5. 5Compose the conditionAssemble result, basis, time and consequential permissions into the single finding described in route 3.
6. 6Publish and retainMake the condition available to consumers and write the evaluation record to the operational store.

Applicability is resolved before comparison, not folded into it, because an error in applicability invalidates every comparison performed afterward. Getting the wrong requirements in scope is a different and more serious failure than mis-evaluating the right ones.

The record read in step three must reflect the present, not a prior scan. Requirements are amended, certifications lapse, flags are raised, corrections are accepted — often between one scan and the next on the same identity.

• ✓Each operational scan triggers a full evaluation act rather than replaying a stored verdict.
• ✓The record read is the current operational record at evaluation time, not a snapshot from an earlier act.
• ✓Time-bound requirements are checked against the evaluation instant, so expiry takes effect without a separate sweep.
• ✓A prior condition is evidence of a past act, never a substitute for running the act again.

Freshness is what keeps the condition in route 3 moment-accurate. Without it, the act would produce a historical record dressed up as a live finding.

Sometimes an applicable requirement cannot be checked — the governing rule is ambiguous, the record lacks the fact the rule depends on, or a required upstream determination has not been made.

An unresolved rule produces an exception, never a guess in either direction. Guessing is a worse outcome than an honest exception, because it hides the gap instead of surfacing it for review.

Completing the act is not the end of it. The act itself — not only its output condition — is retained, because a later dispute may turn on how the finding was reached rather than only on what it concluded.

• The applicable requirements considered, including any later found to have been resolved incorrectly.
• The record facts read, as they stood at evaluation time.
• The comparison result per requirement, not only the composed overall condition.
• The evaluation timestamp, so later acts can be sequenced against it.
• Any exception raised, with the specific unresolved requirement or fact named.

This retained record is what an auditor reads when a condition is challenged. It answers not just 'what was found' but 'how was it found,' which is the harder question to answer honestly after the fact.

Evaluation is the validation layer's operational act — the mechanism, not the finding — and it is where the doctrine's separation of layers is enforced in practice.

Where the evaluation record and QRCodex.us disagree after the fact, Codex governs and the evaluation record is corrected — the act is re-run against the corrected record, not overridden by hand.