Compliance Condition

A compliance condition is the evaluated result of comparing a registered QR identity's current record against the requirements that apply to it.

Two inputs produce it. The first is the set of applicable requirements — governed upstream, never invented by the validation layer. The second is the identity's current record: registration and certification state, issuer and company association, jurisdiction assignment, expiry and renewal position, outstanding flags, and relevant history.

Evaluation compares the two. The result is a condition that says, in effect: measured against these requirements, using this record, at this moment, the identity stands here. Because both inputs can change, the condition is inherently time-bound and is always evaluated fresh rather than assumed from a previous scan.

Most confusion about compliance conditions comes from collapsing them into neighbouring concepts. Each neighbour has its own route; the boundaries below are the short version.

QRCompliance.us validates. It states the condition. It does not enforce, certify, register or write requirements.

A condition that is only a colour or a single word cannot be audited. To be operationally useful, a condition has to carry enough structure to explain itself long after the scan that produced it.

• Subject — the registered QR identity the finding concerns, unambiguously.
• Requirements applied — which applicable requirements were in scope for this evaluation.
• Result — whether those requirements were satisfied, and where they were not.
• Basis — the record facts the result rests on, so the finding can be reconstructed.
• Time — when the evaluation occurred, because conditions expire as facts change.
• Consequential permissions — what the condition allows or withholds downstream.

The basis element is what separates a validation system from an opinion. Anyone reviewing the record later must be able to see not only that the identity failed, but which requirement it failed and what fact caused the failure.

1. 1Identify the subjectResolve the scan or request to exactly one registered identity. An unresolvable subject produces no condition; it produces a resolution failure, which is a different finding.
2. 2Determine applicable requirementsRequirements apply by jurisdiction, issuer, object type, certification scope and other governed factors. Applicability is itself a determination, and getting it wrong invalidates everything after it.
3. 3Read the current recordPull the identity's present facts from the operational record. Cached or stale facts are not acceptable inputs for a live condition.
4. 4CompareEvaluate each applicable requirement against the record. Requirements are evaluated individually so that the finding can name what failed rather than reporting a single opaque verdict.
5. 5Compose the conditionAssemble the result, basis, time and consequential permissions into one coherent finding.
6. 6Publish and retainMake the condition available to routing, monitoring and authorization consumers, and retain it as evidence in the operational record.

Evaluation is deliberately mechanical. Where a requirement cannot be evaluated because the governing source does not resolve it, the correct outcome is an exception raised for review — not an assumption in either direction.

Conditions fall into recognisable families. The families below describe the shape of the finding; the specific published labels belong to the compliance status route.

Note that 'exception' is a first-class outcome. Systems that force every evaluation into pass or fail either approve things they should not or block things they should not; naming the unresolved case is more honest and more operationally useful than guessing.

Because so much depends on it, the condition has to be produced by one layer and consumed by the rest. Multiple layers each forming their own private view of readiness is exactly the drift the architecture is arranged to prevent.

The condition is the validation layer's contribution to the chain — the thing QRCompliance.us produces that nothing else produces.

Where an evaluated condition appears to contradict QRCodex.us, Codex governs. The condition and this article are corrected; Codex is not.

A condition is true as of its evaluation and no later. Requirements are amended, certifications lapse, jurisdictions are reassigned, flags are raised, corrections are accepted. A remembered condition is a claim about the past presented as a claim about the present.

• ✓Every operational scan produces a fresh evaluation rather than reusing a stored verdict.
• ✓Stored conditions are retained as evidence of what was found at a specific time, not as a shortcut for the next scan.
• ✓A change of condition is itself an event, so the transition — not only the current value — is part of the history.
• ✓Time-bound requirements are checked against evaluation time, which is why expiry needs no separate sweep to take effect.

This is also why the condition and the compliance status are kept distinct. The status is a durable published label suited to human reading; the condition is a moment-accurate finding suited to machine consumption.